Introduction to Privileged Access Management



Privileged Access Management (PAM) plays a crucial role in modern cybersecurity. Organizations can significantly enhance their security posture and protect valuable assets by addressing the issues and risks associated with privileged accounts. Implementing a combination of robust policies, technologies, and best practices will help organizations manage the risks effectively while ensuring the availability, integrity, and confidentiality of their systems and data.

This article introduces the concepts of managing privileged access and will touch on non-human accounts, including those that are both interactive and non-interactive. It will show that not all privileged access accounts should be treated in the same way. It will explore the scenarios in which PAM solutions can help organizations gain control of privileged access. Different use cases for PAM solutions are explained and illustrated with architecture diagrams.

Critically, even when implementing PAM systems, practitioners cannot neglect the human factor (which requires policy, training, and controls). This article concludes with best practices for implementation, adoption considerations, and core guiding principles.

Keywords: PAM, Privileged Access Managament, Non-human accounts

How to Cite: Koot, A. (2024) “Introduction to Privileged Access Management”, IDPro Body of Knowledge. 1(13). doi:


Introduction to Privileged Access Management

© 2024 IDPro, André Koot (SonicBee)

To comment on this article, please visit our GitHub repository and submit an issue .

Introduction to Privileged Access

Privileged Access Management (PAM) plays a crucial role in modern cybersecurity. All organizations (at least those with technical infrastructure) maintain accounts with some form of super-user permissions, e.g., the Administrator account on a laptop. Organizations enhance their security posture and protect valuable assets from inside and outside threats by addressing the issues and risks associated with privileged accounts. This requires a combination of robust policies, technologies, and best practices that help organizations manage the risks while ensuring the confidentiality, integrity, and availability (the “CIA Triad”) of systems and data.


Access The permissions, privileges, and abilities granted to users, account types, system processes, applications, or any other entities within a computing environment.
Privileged Access Users or accounts with high-risk permissions, such as those that grant them access to (critical) systems, sensitive data, and configuration settings
Privileged Access Management A mechanism for managing temporary access for accounts with high-risk permissions. PAM often involves check-out and check-in of a credential generated for a single use. 1
Privileged Account Management Focuses on special control for risky high-level access. Privileged Account Management (PAM) is a mechanism for getting those special accounts under control. 2
Role Based Access Control (RBAC) The use of roles at runtime: a way to govern who gets access to what through the use of business roles and application roles
Joiner/Mover/Leaver The joiner/mover/leaver lifecycle of an employee identity considers three stages in the life cycle: joining the organization, moving within the organization, and leaving the organization.
Least Privilege The principle that a security architecture should be designed so that each entity is granted the minimum system resources and authorizations that the entity needs to perform its function. 3
Identity Governance and Administration A discipline that focuses on identity life cycle management and access control from an administrative perspective. 4

Acronyms in Use

CIA: Confidentiality, Integrity, and Availability The “triad” that forms the basis of information security.
RPA: Robotic Process Automation Autonomous IT solution to automate manual tasks. This autonomy is in contrast to a user-initiated macro.
ICS: Industrial Control Systems Implemented to separate IT environments from Operational Technology environments (e.g., in industrial process industries)
SCADA: Supervisory Control and Data Acquisition An architecture framework to secure ICS environments

Privileged Accounts

Privileged accounts, often called ‘super-user’ or ‘administrator’ accounts, possess elevated permissions granting access to (critical) systems, sensitive data, and configuration settings. With this level of access, these accounts define the behavior of the component they belong to. ‘Administrator’ is the built-in account needed to configure a Windows component, such as the directory, the filesystem, and the networking capabilities. Similarly, ‘root’ is the super-user account on UNIX and Linux systems and many infrastructure components. In database management systems, there are ‘SA’ (system admin), ‘DBO/DBA’ (database owner/admin), ‘root,’ or ‘postgres.’ These accounts function on behalf of a component itself (rather than a user). Anyone who knows the password can log in and effectively be the component: they can change the component's behavior and thus make or break the system. These super accounts are almighty.

Managing access to privileged accounts should be one of the most common early initiatives in an organization’s identity & access management (IAM) journey. Why? The simple answer is that the organization should manage access where risk is highest. For more detail, look no further than the #1 item in the 2021 OWASP top 10 list of Web Application Security Risks: Broken Access Control ( OWASP link ). 5 Without effective privileged access management (PAM), all three legs of the information security CIA triad can be compromised, sometimes with catastrophic results. This is why, although they vary by country, emerging regulatory frameworks specifically call for controls on privileged access. For example, here is one clause in which the European NIS2 Directive specifically refers to PAM as an essential part of ‘cyber hygiene:’

…Cyber hygiene policies comprising a common baseline set of practices, including software and hardware updates, password changes, the management of new installs, the limitation of administrator-level access accounts, and the backing-up of data, enable a proactive framework of preparedness and overall safety and security in the event of incidents or cyber threats 6

Regulation is not the only reason to start a PAM program. Even if an organization isn’t subject to these compliance controls, managing access to privileged accounts is in its best interests. Figure 1 demonstrates what can happen when unauthorized users gain access to admin accounts.

Screen shots of two twitter posts, nominally from Joe Biden and Barack Obama but posted as a result of hacked Twitter admin accounts.

Figure 1: In 2020, the admin accounts of Twitter Operations Management software were leaked to a Slack channel and accessed by an unauthorized person, leading to fraudulent activity. 7

Threats of Privileged Access

As demonstrated by the example in Figure 1, organizations that do not constrain the proliferation of – and access to - privileged accounts face several issues. Those issues include:

A Typology of Privileged Access Accounts

Understanding the different types and characteristics of privileged accounts is essential to management and risk mitigation.

Human Privileged Accounts

Generally, human-privileged accounts are governed by the human resource practices in an organization. The CEO, for example, often has more privileges in systems than interns. Because the CEO’s user accounts have more power – and because the CEO is often easily identifiable – their privileged accounts are at a greater risk of attack. Fortunately, executives seldom have root access to Linux servers and are rarely assigned as admins to Windows Server management. However, their access and associated risks should be managed thoughtfully. Role-Based and Policy-Based Access Control can help control the amount of access that such users have.

Another type of access would be individual/nominative accounts – those with root access, global admin rights, or other highly privileged group membership. Managers should consider these accounts high-risk. The usage of these authorizations may not be anonymous, but they should never be assigned for an indefinite amount of time. Just-in-Time (JIT) provisioning or dynamic access controls offer further controls to prevent long-standing high-risk authorizations.

Privileged access may also refer to operations involving sensitive data, e.g., the amount or type of personally identifiable information (PII) or company financial data that an individual user has access to. In some scenarios, privileged access may extend to which customers’ data. For instance, a healthcare organization treating a ‘VIP’ may consider their data more sensitive. While policy and regulation treat them as equal, the collateral damage in the event of a data breach may be more significant, and, therefore, an organization may put more access controls in place.

The key risks applicable to human accounts are two-fold:

  1. Legitimate users (employees, contractors, etc.) gain more access than they should and, thus, put the organization at greater risk of insider threat or data loss.

  2. Bad actors gain access to legitimate users’ accounts through one of many attack vectors, like password spray attacks, phishing campaigns, or consent hacking.

Of course, these risks often work hand-in-hand since bad actors that gain access to the highly-privileged accounts of legitimate users can inflict greater damage.

Best practices for managing this type of account include:

These controls depend on solid governance and access management processes. For more information on Workforce Identity and Access Management (also called Identity Governance and Administration, or IGA) solutions that support Joiner-Mover-Leaver workflows and Role Based Access Control, see An Overview of the Digital Identity Lifecycle. 8 These solutions can, however, not ideal for the management of non-human privileged accounts since the managing process is not a joiner-mover-leaver process.

Non-Human Privileged Accounts

Non-Human Accounts require different management processes and risk mitigation strategies because they are not human (as suggested by the name). These non-human accounts are not managed via a joiner-mover-leaver processes. Instead, events in their lifecycle - which resemble those of human accounts - are triggered by a change management process.

A diagram of a digital identity lifecycle for non-human accounts. The boxes include Create then Provision then Authenticate then Manage / Maintain then Deprovision Access.

Figure 2: Lifecycle of Non-Human Accounts

Figure 2 articulates the following lifecycle for non-human accounts:

  1. Create: A non-human account is created as the result of a change request, either in a development process or brought in through a procurement process (rather than an HR process that triggers a human account). The account can belong to a server, a network component, or an RPA.

  2. Provision: The component is activated, gets an identity and an account, and is given the least privileged authorizations required to perform the configured tasks. A secret is configured to make it possible to identify and authenticate the component at runtime.

  3. Authenticate: Once activated, the component needs to be identified by a governing body (like the network) and authenticated, whether by a configured password, a certificate, or a token.

  4. Manage/Maintain: During the lifecycle, the component's functionality can change, and any changes to required authorizations will be managed through the change management process.

  5. Deprovision Access: When the component is decommissioned, access is removed to prevent abuse (practitioners often forget this step).

There are two forms of non-human privileged accounts: those that humans interact with and those they do not. While the main focus of this article is interactive non-human accounts, it is crucial to consider the PAM implications of those that do not interact.

Non-Human, Non-Interactive Privileged Accounts

Some privileged accounts are non-interactive, meaning that humans generally do not log into them to perform business activities. These are the accounts of components like middleware services, such as databases or web servers. These services access resources after a login with a secret kept in a config file using tokens or secrets. These accounts act as placeholders in the system log that register resource usage.

For example, in accounting software, an application may need to register transactions in a relational database. To do this registration, the application looks up the password of the configured service account and logs in to the database. This results in each transaction being logged against and owned by that application. The application must, of course, ensure that the account of every actor is registered as the initiator of their transactions.

Other examples include accounts used for automation, such as batch accounts, macros, or RPAs. The organization’s Technology team documents a change request with the process requirements for each automated task and then creates the appropriate script or configuration to execute the steps. The process itself needs to have the requisite authorization to run. Or, in other words, achieve the minimal required authorizations according to the ‘least privilege’ principle.

In these scenarios, the change requester or requirements owner should be considered the accountable party for the script, macro, or RPA.

Best practices for managing this type of account include:

To learn more about managing these types of privileged accounts, see Non-human Account Management in the BoK. 9

Interactive Non-Human Privileged Accounts

Interactive non-human accounts - the main focus for the remainder of this article - are also called system accounts: these are the built-in component accounts, such as ‘admin’ or ‘root.’ These can also be accounts that are built-in into applications, such as the super-user of an application. A person who needs to use the power of this account will log in to the component with this account name and the password provided by the developer or the vendor. In the session that results, the person is the component.

The existence of these almighty accounts creates severe risks of unauthorized access by individuals capable of breaking or exploiting the component: they can be tremendously damaging to an organization’s security posture if practitioners do not contain and strictly control their usage. As stated, someone who logs in with the component account is the component. And that means that the component itself is the actor, performing all the tasks. Without additional measures, the actual human being may not be known or identifiable.

This type of account should only be used in specific circumstances and for a particular purpose, like during an incident or to deliver a change. This practice is a fundamental security principle. A common control is to raise a ticket in a service management solution when access to this type of account is required. A PAM solution can then check that the ticket is valid. Connecting a PAM solution to the service management solution is best practice.

Best practices for managing this type of account include:

Addressing the Challenges of Privileged Accounts

As established, there is a strong business driver to implement PAM. However, not every organization needs a costly solution. As long as an organization can cope with manual procedures for managing internal privileged accounts, that may be the best fit. A manual process might be something akin to the “envelope procedure,” in which the password to shared admin accounts is stored in a sealed envelope (yes, a physical envelope) that is kept inside a vault (yes, a physical vault). When an emergency arises, this envelope can be opened. This opening should be treated as a security incident resulting in password rotation and a new physical envelope.

This type of process is appropriate when only a handful of people manage the system. Even where it may be effective, beware of risks: if one of these admins is absent or leaves the organization, there will be a lot of work to mitigate the risk of any shared accounts.

Privileged Access Management Solutions

Several conditions drive a need for automation and more formal solutions:

Readers may also be interested in reading the Body of Knowledge article “ The Business Case for IAM .” 10

With a need for automated PAM processes, organizations can implement a PAM solution. These solutions provide several means for managing Privileged Accounts. These can include different approaches to privilege management and secrets management, and they support a variety of operational use cases.

Privilege Management

Secret Management

Secrets management aims to securely store, distribute, and control access to sensitive information, such as passwords, encryption keys, API tokens, and certificates. PAM solutions often offer:

Secret Management for CI and CD Secret Management for APIs
Environment Variables: CI/CD systems like Jenkins, Travis CI, or CircleCI allow developers to store sensitive information as environment variables. These secrets are encrypted and can be accessed during the pipeline execution, ensuring that they are never exposed directly in code or logs. API Keys and Tokens: When accessing external APIs, developers often require API keys or tokens. Secrets management ensures that these keys are stored securely and are only accessible by authorized services or applications. It also enables the rotation of keys to mitigate security risks.
Secrets Vault: Many organizations use dedicated secrets management tools like HashiCorp Vault or AWS Secrets Manager. These tools centralize the storage of secrets, enforce access controls, and often provide features like secret rotation and auditing. CI/CD pipelines can authenticate and retrieve secrets from these vaults as needed. OAuth and JWT: For more robust API access control, OAuth tokens and JSON Web Tokens (JWTs) are used. Secrets management ensures that the keys used to sign and verify these tokens are kept secure and rotated as necessary.
Temporary Credentials: For cloud-based services, CI/CD pipelines can request temporary access credentials from the cloud provider’s IAM (Identity and Access Management) services. This limits exposure and ensures that access credentials are short-lived. Role-Based Access Control (RBAC): Secrets management can enforce RBAC for APIs, ensuring that only authorized users or applications have access to specific endpoints or resources.
Logging and Monitoring: API access should be closely monitored, and logs should be audited to detect any suspicious or unauthorized access attempts.

PAM Use Cases and Architectural Choices

The following section explores a variety of architectures incorporating PAM.

PAM as a Stepping Stone

A diagram showing a PAM system at the center of an architecture that includes ITSM, Directory, SOC/SIEM, Recording, and Target System.

Figure 3: PAM as a Stepping Stone Architecture

Traditionally, PAM systems are installed in a data center, close to the components they manage. PAM systems can also be implemented as a SaaS solution (see the cloud discussion section at the end of this section).

PAM in IT / OT environments

In organizations employing Operational Technology (OT) components, the IT and OT domains are separated by default. This separation may be via airgap firewalls, Industrial Control Systems (ICS), or SCADA implementations. Some organizations add IT capabilities to OT to share control center capabilities and to provide remote access and monitoring. Traditionally, the separation is done through SCADA or ICS systems. A modern and more affordable solution is to use a ‘PAM-PAM’ connection that secures access. Only through an IT-PAM system does an operator get access to an OT-PAM system, where OT tasks can be performed:

A diagram showing a PAM-to-PAM architecture in an IT/OT environment. It starts with a Directory and LDAP account, then goes through the IT PAM system to the Admin account, to the OT PAM system and finally the target system.

Figure 4: PAM-PAM Architecture in an IT/OT Environment

External Service Provider

Many companies outsource parts of their operations management. The component owner is accountable for granting access if a third-party manages company resources. In this case, privileged access must also be assigned to third-party operators. In addition, when using external services, the company must ensure that the service provider uses a PAM solution.

A PAM system in a third-party access model with the internal pam system being fed by the third party PAM system.

Figure 5: PAM in 3rd-Party Access

Remote access

As described above, PAM solutions can offer business users and (external) developers remote access capability. This way, legacy remote access services and VPNs can be decommissioned, resulting in lower costs and reduced technical debt.

A diagram for PAM in a remote access scenario where the PAM account touches a PAM web portal, which is the front half to the PAM System, then goes on to the target system.

Figure 6: PAM for Remote Access

Implementing PAM

Good Implementation Practices

Automated Discovery and Component Onboarding

Components that need to be managed through a PAM system must be onboarded first, meaning that the privileged accounts and passwords must be brought into the PAM system. Onboarding components can be done manually, but PAM systems can automate the discovery of components in the network to start the actual onboarding.

Session Control

Authentication and logging controls happen by default when a session starts from a PAM system. Implementors can also add risk-based session controls, such as:

Beware that recording and playing back sessions should be considered a privacy and security issue. Ensure workers (counsels/unions) agree and that playback calls for 4-eyes control. 11

Break-the-Glass Procedures

PAM systems act as authentication services. If the service is not available, the operator cannot get access to the component that needs to be managed. While redundancy is an essential control, break-the-glass procedures enable access to the password vault under emergency conditions.

PAM in the Cloud

Developments in PAM mirror the developments in most IT domains: where PAM systems used to be self-hosted, on-prem systems, nowadays, both SaaS and MSP options are becoming available, as well as hybrid solutions.

Third-Party Contracts

When outsourcing operations or using services provided by third parties, an organization must ensure that PAM requirements and rules apply to the third party. To protect the supply chain in this way, organizations should build this requirement into third-party contracts as well as procurement and vendor management processes.

Addressing Barriers

Adoption & Friction

PAM System adoption depends heavily on user experience. PAM systems often add extra steps to log into the target systems, introducing a new pattern. Like the reason for access, ticket number, MFA, or lack of native integration with remote tools, these changes to established methods may lead to frustration among users. This friction also might lead users to seek backdoors that help them bypass PAM systems.

Current admin account users may regret their loss of almighty powers – and may feel less empowered to manage their components. They may fear being mistrusted by management. It should be noted that these concerns are real: communication is essential in change management, and emphasis on the added functionality of PAM solutions, such as single sign-on and auditability of actions, can help.

PAM System Availability

PAM system availability is one of the biggest concerns for organizations. If the PAM system is unavailable, it prevents recovery since all the privileged accounts required to access IT assets are stored and managed by the PAM system. This risk can be countered by a flawless and tested break-glass procedure, which enables swift access recovery. Unfortunately, these break-glass accounts are often forgotten and can cause more harm than good, so it’s necessary to monitor, test, and securely store the break-glass credentials.

Password Rotation of Hard-Coded Credentials

Almost every service or application requires credentials to communicate with databases or other applications. These credentials are used to prove the application’s identity. Typically, they are privileged and embedded in various locations, such as configuration files, source code, INI files, OS services, and scheduled tasks, which are referred to as dependencies of the credentials. Therefore, when the password is rotated, the new password must also be updated in all dependencies. Many mature Privileged Access Management (PAM) systems can automatically update the new passwords in the dependencies after rotation.


Remember, PAM solutions do not address all risks relating to sensitive data access: practitioners must understand different privileged access scenarios and map them to the appropriate controls. First and foremost, they must consider the differences between human and non-human accounts. PAM solutions are not a panacea and do not address the thorny challenges of managing people or the non-interactive accounts that do not require humans once coded (these are demonstrably not people). Effective policy, governance, change management, and other controls are still very much required.

PAM solutions are best used for interactively used non-human accounts, although their secret management tools often cater to the needs of non-interactively used non-human accounts. Make sure that these use cases are identified correctly before introducing any technology.

Once an organization introduces PAM tools, do not underestimate the impact of culture: it can be a significant change for people. It is essential to bring people along, highlight the benefits of additional functionality, and communicate the necessity of an improved security posture for the organization.

Remember these Core Principles

Author Bio

André Koot has over 25 years of experience in the field of IAM, and he is a principal consultant and co-founder of SonicBee, a Dutch IAM consultancy company (IDPro partner). André is focused on business consultancy and gives IAM training courses aligned with the BoK. He is also a member of the IDPro BoK committee and (co-) authored several articles in the BoK.


The author wishes to thank BoK editor Elizabeth Garber for reviewing and helping with this article. He also wishes to thank other contributors and reviewers:



  1. Carter, M. K., (2022) “Techniques To Approach Least Privilege”, IDPro Body of Knowledge 1(9). doi:

  2. Bago (Editor), E. & Glazer, I., (2021) “Introduction to Identity - Part 1: Admin-time (v2)”, IDPro Body of Knowledge 1(5). doi:

  3. Carter, M. K., (2022) “Techniques To Approach Least Privilege”, IDPro Body of Knowledge 1(9). doi:

  4. Bago (Editor), E. & Glazer, I., (2021) “Introduction to Identity - Part 1: Admin-time (v2)”, IDPro Body of Knowledge 1(5). doi:

  5. OWASP (2021) “OWASP Top 10: 2021,”

  6. European Parliament and the Council of the European (2022) “DIRECTIVE (EU) 2022/2555 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 14 December 2022on measures for a high common level of cybersecurity across the Union, amending Regulation (EU) No 910/2014 and Directive (EU) 2018/1972,” clause 49,

  7. BBC (2020), “Major US Twitter accounts hacked in Bitcoin scam “

  8. Cameron, A. & Grewe, O., (2022) “An Overview of the Digital Identity Lifecycle (v2)”, IDPro Body of Knowledge 1(7). doi:

  9. Williamson, G., Koot, A. & Lee, G., (2022) “Non-human Account Management (v4)”, IDPro Body of Knowledge 1(11). doi:

  10. Koot, A., (2023) “The Business Case for IAM”, IDPro Body of Knowledge 1(12). doi:

  11. And as a side note: storage of recordings could lead to capacity issues.