Privileged Access Management: Vaults, JIT and Tiering
How PAM works: discovering privileged accounts, vaulting and rotating credentials, brokered sessions, just-in-time elevation, the tiered admin model, and machine secrets that never see a human.
Most intrusions are a story about privilege. The attacker arrives with none, gets some, and the difference between an incident that ends at one workstation and one that ends with the entire directory encrypted is how much privilege was lying around and how easy it was to pick up.
Privileged access management is the set of controls that makes privilege scarce, temporary and observed. Fewer accounts hold it, they hold it for less time, the credential lives somewhere the endpoint cannot reach, and everything done with it is recorded.
This guide covers the components in the order they are usually deployed, the tiering model that makes them coherent, and the machine-identity half that most programs address last and should not.
Scope: Least Privilege Explained owns the principle, Active Directory Security Basics owns the directory, Insider Threats Guide owns the human risk, and the credential attacks are covered in Pass the Hash, Kerberoasting and DCSync. This page owns the controls.
What counts as privileged
Wider than the obvious list, and the unobvious entries are where the risk sits.
- Directory and identity. Domain administrators, enterprise administrators, the identity provider's global administrators, anyone who can reset a privileged password or edit a conditional access policy.
- Infrastructure. Root and local administrator on servers, hypervisor administrators, backup administrators (who can read every file in the organisation by design), storage administrators.
- Cloud. Account root users, organisation management accounts, roles with policy-editing rights. The ability to grant yourself a permission is equivalent to holding every permission.
- Data. Database administrators, and any application role that can read a whole customer table.
- Network. Switch, router, firewall and VPN administrators.
- Pipelines. CI/CD systems that deploy to production, which usually hold credentials for everything they deploy to.
- Service accounts. The largest group and the least governed. Non-interactive accounts running services, scheduled tasks, integrations and scripts, frequently with more rights than they need and a password set in 2019.
That last category is why discovery comes first.
1. Discovery
You cannot govern accounts you have not enumerated, and the count is always higher than expected. What to look for:
- Members of privileged directory groups, including nested membership, which is where surprises hide.
- Accounts with privileged rights granted directly rather than through a group.
- Local administrator group membership on every machine.
- Service accounts and their logon rights, plus which machines they authenticate to.
- Accounts with delegated rights in the directory, which frequently amount to privilege without appearing in any privileged group.
- Cloud identities with policy-editing or role-assignment permissions.
- Accounts excluded from conditional access or MFA policies. Every exclusion list is a target list.
The output is an inventory with an owner per account and a justification per entitlement. Anything with no owner is either retired or adopted, and no third option should be available.
2. Vaulting and rotation
The vault stores privileged credentials and hands them out under control.
The mechanics: an administrator authenticates to the vault with their own identity and MFA, requests a credential, and the vault checks the entitlement, releases access, and rotates the credential after use. The password itself is long, random and unknown to anyone.
Rotation matters because it bounds the lifetime of a stolen credential. A password captured from memory on a compromised host is worthless once rotated, so the window of usefulness shrinks from "until someone changes it" to "until the session ends".
Brokered sessions are the stronger form. Rather than releasing the password to the administrator, the vault establishes the session itself through a proxy and gives the administrator a screen. The credential never touches the workstation, so malware on that workstation has nothing to harvest. This is the single control that most reduces the value of compromising an administrator's endpoint.
Session recording attaches to that. Keystrokes, commands and video of privileged sessions, retained and searchable. It deters casual misuse, and after an incident it answers what was actually done rather than what was intended. Scope it to privileged sessions, state it in policy, and tell people it is happening.
Local administrator passwords are the highest-value application of rotation in a Windows estate. A single shared local administrator password across thousands of machines is a master key: one compromised endpoint yields a credential that authenticates to all of them. Windows LAPS sets a unique random password per machine, stores it in Active Directory or Entra ID with access control on who can read it, and rotates it on a schedule. It is built into current Windows versions and it removes an entire lateral movement path.
3. Just-in-time elevation
Vaulting protects the credential. Just-in-time removes the standing entitlement.
The account holds no privileged role in its normal state. To do privileged work, the administrator requests activation, gives a reason and, for the most sensitive roles, waits for an approval. The role is granted for a fixed window, an hour or four, and expires automatically.
What this changes:
- The window of usefulness. An attacker who compromises the account outside an activation window gets an ordinary user.
- The audit trail. Every elevation has a time, a reason and an approver, produced as a by-product of doing the work rather than as a compliance exercise.
- The count of standing administrators, which becomes a metric you can drive toward zero. "How many permanent domain administrators exist" is the single best one-number summary of an estate's privileged risk.
The exception is break-glass. Every environment needs two accounts that work when the identity provider, the MFA service or the PAM system is broken. They are excluded from conditional access by design, their credentials are long, split between custodians and stored offline, and any authentication by them raises an immediate alert. Test them on a schedule, because an untested break-glass account is a break-glass account that will not work.
4. Tiering
Tiering is the model that makes the other controls coherent, and it follows from one fact: authenticating to a machine leaves credential material on that machine, and whoever controls that machine can take it.
The consequence is a rule about where identities are allowed to be used.
| Tier | Contents | Rule |
|---|---|---|
| Tier 0 | Domain controllers, identity provider, PKI, anything that can grant tier 0 | Tier 0 identities authenticate only to tier 0 systems |
| Tier 1 | Servers, applications, databases | Tier 1 identities administer tier 1, never authenticate to tier 2 |
| Tier 2 | User workstations and devices | Tier 2 support identities stay in tier 2 |
A domain administrator who logs into a helpdesk workstation to fix a printer has placed tier 0 credential material on a tier 2 machine. Anyone who compromises that workstation, through a phishing document or a browser exploit, harvests it and owns the directory. This is the mechanism behind a large share of "attacker went from one laptop to domain admin in two hours" incident reports.
Privileged access workstations implement the rule physically. Administration of tier 0 happens from a dedicated hardened device with no email, no browsing and no general-purpose software, so the paths that compromise ordinary workstations do not exist on it. It is inconvenient and it is the most effective single control in this guide.
Microsoft's current formulation, the Enterprise Access Model, extends the same reasoning to cloud control planes, which are tier 0 whether or not they run on a domain controller.
5. Machine identity
Human administrators are the smaller half. Service accounts, API keys, CI/CD credentials and integration secrets outnumber them, authenticate constantly, and rarely rotate.
The failure patterns are consistent: a static secret in a configuration file or environment variable, the same secret across environments, a service account whose password has not changed in years, and permissions granted once for a task and never removed.
The controls that work:
- A secrets manager as the source, with applications fetching at runtime rather than holding a copy. Rotation then becomes a property of the platform.
- Short-lived credentials over static ones. Workload identity federation lets a workload exchange a platform-signed token for temporary cloud credentials, which removes the static key entirely. This is the single largest reduction available in cloud credential risk.
- Group managed service accounts in Active Directory, where the directory generates and rotates the password automatically and no human ever knows it.
- Scoped permissions per workload, rather than one shared integration account used by nine systems because that is what existed when the tenth was built.
- An owner and a review date per credential, so the secret for the system that was decommissioned in 2023 gets removed.
Least Privilege Explained covers the scoping principle, and the cloud specifics are in Cloud Misconfigurations.
6. Review and monitoring
Entitlements decay toward more. People change roles and keep old access, projects end and their access persists, and emergency grants become permanent.
- Access reviews on a schedule and on role change, performed by the manager who knows what the person does rather than by security.
- Automatic revocation on role change, which is the control that actually fixes accumulation, since reviews catch it late.
- Alerting on privileged group changes. Any addition to a tier 0 group is either a change you know about or an incident.
- Alerting on elevation outside expected hours and on break-glass use.
- Metrics that mean something: the number of standing privileged accounts, the percentage of privileged sessions that were brokered, the median duration of an elevation, and the count of service accounts with credentials older than the rotation policy.
What PAM does not solve
An administrator doing something harmful within an approved elevation is authorized. Recording captures it and nothing prevents it, which is why sensitive operations get dual control rather than better authentication.
The PAM platform becomes the highest-value target in the estate, because it holds the credentials to everything. It needs the strictest access rules, its own tier 0 treatment, and monitoring that would notice if it were tampered with.
And a compromised endpoint during an active brokered session still has an active session on it. Brokering removes the credential from the endpoint; it does not remove the access that exists while the session is open.
The verdict
The controls stack in a specific order, and the order matters more than the product: discover the accounts, remove standing privilege, rotate what remains, broker the sessions so credentials stay out of endpoints, and tier the identities so that compromising a workstation cannot reach the directory.
For an estate starting from nothing, two changes give the most reduction for the least work: rotate local administrator passwords per machine, and stop tier 0 identities from ever authenticating to workstations. Both close paths that appear in incident report after incident report, and neither requires buying anything.