PAM Privileged Access Management.

Why privileged accounts are a separate problem

Every identity programme starts with ordinary users: who they are, what they can open, how they prove it. Privileged Access Management deals with the accounts that sit above that layer. Domain administrators, root and local admin accounts, database owners, hypervisor consoles, cloud root identities, service accounts that run unattended, and the break-glass accounts kept for emergencies. These identities can change configuration, read or destroy data, disable logging, and create new accounts. The blast radius of a single compromised admin credential is the whole environment, which is why PAM is treated as a discipline of its own rather than a feature of general IAM.

The defining move of PAM is to stop treating privileged credentials as something a person simply knows. Instead the secret lives in a vault, access is requested and approved, the session is brokered through a controlled gateway, and everything the privileged user does is recorded. The human often never sees the password at all. That separation between the operator and the secret is what makes privileged activity auditable and revocable.

What a PAM programme actually controls

In practice a mature PAM deployment combines several mechanisms that map directly onto what auditors expect to see:

• Credential vaulting: privileged passwords, SSH keys, and API secrets are stored centrally, rotated automatically, and never embedded in scripts or config files.
• Session brokering and recording: administrators connect through a proxy that injects the credential, so the session can be monitored, recorded, and terminated without the operator ever holding the secret.
• Just-in-time elevation: rights are granted for a defined task and a defined window, then revoked, rather than left standing on the account permanently.
• Break-glass procedures: emergency accounts are sealed, alarmed, and reviewed after every use, so they exist for genuine outages without becoming a quiet backdoor.
• Discovery and accountability: the tool finds privileged and service accounts across the estate and ties every privileged action back to a named human.

Where PAM sits in IAM and the regulatory picture

PAM is a subset of identity and access management, narrowed to the accounts that carry the most risk, and it is the sharp end of the principle of least privilege. General IAM asks whether a person should have access at all. PAM assumes the access is legitimate but insists it be temporary, brokered, logged, and reversible. Attackers understand this hierarchy: after an initial foothold through phishing or an exposed service, the next objective is to escalate to a privileged account, because that is what turns a single host into control of the domain.

Supervisors know it too. Under the NIS 2 Directive, access control and the handling of privileged accounts fall squarely within the cybersecurity risk-management measures that essential and important entities must implement. The Digital Operational Resilience Act (DORA) sets comparable expectations for the financial sector, where strong authentication and tight control of privileged access are part of the ICT risk-management framework. ISO/IEC 27001 Annex A addresses privileged access rights and the management of secret authentication information as named controls. In an audit, privileged access is consistently one of the areas examined hardest, because weak control here undermines every other safeguard.

Common failure modes

PAM programmes fail in predictable ways. Service accounts with non-expiring passwords hardcoded into automation. Shared admin accounts where nobody can say who acted. Standing local administrator rights on every workstation. Vault adoption that covers the interactive admins but leaves machine identities untouched. The discipline is only as good as its coverage, so the practical work is continuous discovery and the steady removal of standing privilege rather than a single rollout.