Privileged Access Management (PAM): JIT, Vaults & Break-Glass

Privileged Access Management

Privileged access management (PAM) limits who can make high-impact changes and controls how those permissions are used. It covers human administrators, automation and service accounts, emergency ("break-glass") accounts, administrative devices, and the credentials and keys that can control other systems.

Privileged credentials are attackers' primary target: once an attacker holds domain admin, a cloud owner role, or a CI/CD deployment token, most other defenses stop mattering. Good PAM reduces how many privileged identities exist, how long privilege is available, how well it's protected, and how visible its use is.

TL;DR

Inventory effective privilege, not just groups with "admin" in the name.
Separate everyday accounts from administrative identities, and protect admin devices.
Prefer just-in-time (JIT) elevation with narrow roles over standing admin rights.
Use phishing-resistant MFA for every privileged action.
Vault shared and machine credentials, rotate them, and record high-risk sessions.
Keep tested break-glass access that works when normal identity systems fail.

Quick Example

A just-in-time elevation record for a routine but sensitive task:

An Azure AD / Entra ID PIM–style policy expressed as configuration:

Core Concepts

What Counts as Privileged

Privilege is about impact. Beyond domain and cloud admins, privileged identities include backup operators (can read everything), application consent administrators, CI/CD pipeline credentials, Kubernetes cluster-admin bindings, database owners, key management roles, and helpdesk staff who can reset MFA. Inventory effective capabilities, including nested group memberships and cloud role assignments.

Standing vs Just-in-Time Access

Standing privilege is always available and always exploitable. Just-in-time access grants a role only when needed, for a limited time, with justification and sometimes approval. JIT reduces exposure but doesn't make a broad role safe — a two-hour activation of global admin is still global admin. Combine JIT with narrow roles.

Administrative Separation

Separate admin accounts — never administer from the account used for email and browsing.
Privileged access workstations (PAWs) — hardened devices used only for administration.
Tiering — identities that manage domain controllers or identity providers shouldn't log into ordinary servers or workstations, preventing credential theft from spreading.

Vaults and Session Management

A PAM vault (CyberArk, Delinea, BeyondTrust, HashiCorp Vault, cloud secret managers) stores shared and service credentials, checks them out with approval, rotates them after use, and can broker sessions without revealing passwords. Session recording captures high-risk sessions for audit. A vault controls credential handling; it doesn't reduce what the credential can do once used.

Break-Glass Accounts

Emergency accounts restore access when federation, MFA infrastructure, or the PAM system itself is unavailable. They should be few, excluded from dependencies that may fail, protected with strong offline credentials (like hardware keys stored securely), monitored on every use, and tested regularly.

Non-Human Identities

Service accounts, API keys, deployment tokens, and workload identities often hold more privilege than humans and are rarely reviewed. Give each an owner, purpose, narrow scope, and short-lived credentials (workload identity federation, OIDC) instead of long-lived secrets. See Secrets Management.

Best Practices

Minimize the Number of Privileged Identities

Every standing admin is attack surface. Remove unused assignments and consolidate to the fewest people who genuinely need each role.

Require Phishing-Resistant MFA

Use FIDO2 security keys or passkeys for all privileged activation. SMS and push approvals are vulnerable to phishing and fatigue attacks. See MFA.

Design Narrow, Task-Based Roles

Map administrative tasks to the smallest workable roles. "Reset passwords for the sales OU" beats "User Administrator."

Monitor and Alert on Privileged Activity

Alert on new role assignments, break-glass use, privileged sign-ins from unusual locations, and changes to security controls. Review privileged activity regularly.

Rehearse Loss of the Control Plane

Test break-glass procedures without depending on the systems that might be down, then rotate credentials after the exercise.

Verify Revocation

Confirm that role expiry or removal actually ends active sessions and cached tokens on each platform; some sessions outlive the role.

Common Mistakes

Shared Permanent Admin Accounts

Shared credentials destroy accountability and are rarely rotated. Use named identities with scoped elevation.

Admin Rights on Daily Accounts

Reading email and browsing the web with a privileged account turns every phishing link into a potential full compromise.

Forgotten Service Accounts

Service accounts created years ago with domain admin rights are a favorite attacker target.

Break-Glass as a Daily Shortcut

Emergency accounts used for convenience lose their monitoring value and become standing privilege.

Assuming a Vault Solves PAM

A vault without role design, MFA, device security, and review only moves the problem.

Comparison

FAQ

What is privileged access management?

PAM is the set of controls that secure, limit, and monitor accounts and credentials with elevated permissions — administrators, service accounts, and emergency accounts — to reduce the risk of misuse or compromise.

What is just-in-time access?

A model where privileged roles are granted only when needed, for a limited time, with justification and often approval, instead of being permanently assigned.

Is a password vault enough for PAM?

No. Vaults handle credential storage and rotation, but PAM also requires role design, strong authentication, protected admin devices, emergency access, and monitoring.

Can workload identities be privileged?

Yes. Deployment tokens and service accounts often control critical infrastructure. Treat their permissions and lifecycle with the same discipline as human admins.

How many break-glass accounts should we have?

Typically two, stored and protected separately, excluded from conditional access dependencies that may fail, and monitored with alerts on every sign-in.