Mainframe Blog

Why Privileged Access Management Is a Must-Have for Mainframe Security

3 minute read
David Lea

The mainframe has been around a while. Mainframe security came a little later, but to put it into context, IBM® RACF® (Resource Access Control Facility) was introduced in 1976. What else happened in 1976? Jimmy Carter won the U.S. presidential election, Concorde took its first commercial flight, and VHS video tapes were launched to compete against Sony’s Betamax. So, what does RACF, which pre-dates most high-end tech companies, have to do with a security risk? The short answer is potential technical debt. Technical debt—accrued by delaying necessary work in the name of expediency—is part of working in IT, but when it comes to security, it can lead to vulnerabilities. Without due process, housekeeping, and continual service improvement there is the potential for decades worth of mismanagement in privileged access being given to users.

What is privileged access management (PAM) and why should it be part of your security strategy?

PAM is also termed “elevated access” and “breakglass,” among other names. PAM does exactly what it says—it manages privileged access. Applying PAM to your enterprise means removing all permanent access to anything considered privileged and instead implementing a process around granting privileged access to users on a temporary basis. This can be as simple as an email approval from a manager and an administrator manually giving and revoking access; users requesting access through a web portal which triggers a managerial approval request; or having your ITSM call a piece of software that grants and removes access. PAM should be part of your security strategy because it implements a least-privileged approach and works toward zero trust, resulting in fewer accidental changes due to permanent privileged access being removed and providing an audited approval trail of privileged access usage.

Defining privileged access in your organization

The National Institute of Standards and Technology (NIST) defines a privileged user as “A user that is authorized (and therefore, trusted) to perform security-relevant functions that ordinary users are not authorized to perform.” Would it therefore be fair to assume that any access that is classified as a security-relevant function should be controlled via PAM and the job is done? Maybe, but mainframe controls are very granular, so we can therefore go a bit further.

First, each role needs to be approached differently. For example, your database administrator cannot have the same criteria as the security engineer. A good rule of thumb is that any access that can risk the integrity of business data or any access that can risk business operational continuity should be considered privileged. One thing to keep in mind when segregating privileged and non-privileged access is that a lot of breaches and outages happen entirely accidentally by non-malicious employees who simply have privileged access, which makes mistakes catastrophic.


There are two notable parts to implementing PAM in the enterprise. One is very obviously the technical, but not to be overlooked is the political. You are going to be changing the way potentially thousands of people work and may have done so for decades. There can be pushback around the idea of lack of trust and productivity. Ultimately, the message is simple: Follow best practices and PAM should not be a hindrance. As for the technical part, the roles identified with a lot of privileged access make the most sense to bring under PAM first. The organization must decide how they will action PAM requests, whether manually or through a software-based solution. Before any access is moved under PAM, it is imperative that comprehensive training is done to roll out on the sandpit system and pre-production it before going live.

Periodic reviews and access reduction

Once PAM has been implemented and is live for a suitable period, it is time to begin regular reviews. If anyone has not elevated their ID using PAM for a period deemed appropriate by the site, then they should no longer have the right to request it as it is evidently not required by them. The access given when the user selects privileged access should also be reviewed—if the sysprog’s privileged group is not using certain access over a set period, then it can be deemed not used and removed. Caution should be exercised here, as there can be caveats.

Joiners, movers, and leavers

Using privileged access is part of many roles on the mainframe, and one often-overlooked aspect is implementing it into the joiners, movers, and leavers (JML) process of the organization. If a role requires privileged access, anything that is required in order to request it should be actioned at the point of user creation and again when the user changes roles or leaves an organization.


To conclude, PAM should be part of your least-privileged strategy while you constantly work towards zero trust. As access becomes much harder to abuse, it is a very quick and effective way to flush out malicious behavior because PAM can help identify it by quickly checking whether the events are being actioned while elevated and cross-refencing the approval to understand the work being carried out. A PAM solution can also help keep a system compliant while simplifying the audit process around access controls.

Learn seven ways to take an enterprise approach to securing the mainframe in the white paper, Top 7 Security Priorities for Mainframe Leaders.

Access the 2023 Mainframe Report

The results of the 18th annual BMC Mainframe Survey are in, and the state of the mainframe remains strong. Overall perception of the mainframe is positive, as is the outlook for future growth on the platform, with workloads growing and investment in new technologies and processes increasing.

These postings are my own and do not necessarily represent BMC's position, strategies, or opinion.

See an error or have a suggestion? Please let us know by emailing

Business, Faster than Humanly Possible

BMC works with 86% of the Forbes Global 50 and customers and partners around the world to create their future. With our history of innovation, industry-leading automation, operations, and service management solutions, combined with unmatched flexibility, we help organizations free up time and space to become an Autonomous Digital Enterprise that conquers the opportunities ahead.
Learn more about BMC ›

About the author

David Lea

David Lea is the Senior Product Owner for BMC AMI Security. Having spent seven years in mainframe security consulting he transitioned into his current role and is focused on converting technical knowledge into product enhancements. An advocate for Agile, David is passionate about all things mainframe security and works closely with customers driving modernization into the BMC AMI security portfolio.