Privilege is anything that can change the rules for everyone else
A privileged identity can create or change other identities, read data it does not own, change security settings, or turn off the controls that would detect misuse. It is not only named administrators. Most organisations find far more privileged credentials than they expected when they first run a discovery exercise.
Global Administrators, domain admins, cloud subscription owners, DBAs.
Run applications, backups and scheduled tasks, often with broad rights and old passwords.
Break-glass accounts kept for when everything else fails.
API keys, client secrets, certificates, SSH keys and connection strings.
Service principals and managed identities with application permissions.
Administrator access on laptops and servers, a common foothold for attackers.
Admin roles inside HR, finance, CRM and collaboration platforms.
CI/CD service connections that can deploy to production.
Most serious breaches run through privileged credentials
Attackers rarely start with admin rights. They start with an ordinary user, then hunt for credentials that let them climb. Each step on the path below is a place where a PAM control can stop them.
Eight capabilities make up a PAM programme
No organisation switches all of these on at once. They are listed roughly in the order most programmes adopt them.
Find every privileged account, secret and group membership, including the forgotten ones.
Store credentials in an encrypted vault so people check them out instead of knowing them.
Change passwords and keys automatically, on a schedule and after every use.
Connect admins to targets through a proxy so the credential never reaches their device.
Capture what happened in each privileged session for investigation and evidence.
Grant privilege only when requested and approved, for a fixed window. See Lab 07.
Remove local admin from users and elevate specific applications instead.
Give applications and pipelines short-lived secrets from a secrets manager, not config files.
Where Microsoft-native tools fit
| Capability | Microsoft-native option | Dedicated PAM platforms add |
|---|---|---|
| Just-in-time roles | Microsoft Entra Privileged Identity Management for Entra roles, Azure roles and groups | JIT for non-Microsoft systems, Linux, databases and network devices |
| Local admin passwords | Windows LAPS, backed up to Entra ID or Active Directory | Discovery and rotation across mixed estates |
| Application secrets | Azure Key Vault and managed identities | Secrets brokering for many clouds and on-premises apps |
| Session brokering | Azure Bastion for RDP and SSH to Azure virtual machines | Full session recording, keystroke logging and approval workflows |
| Threat detection | Defender for Identity and Entra ID Protection (Lab 10) | Behaviour analytics on privileged sessions |
Examples of dedicated PAM and secrets platforms include CyberArk, Delinea, BeyondTrust and HashiCorp Vault. They are named here as examples of the category, not as recommendations.
The administrator never sees the password
In a mature setup the admin authenticates strongly, requests access with a reason, and is connected through a proxy that injects the credential. When the session ends, the password is rotated, so even a recorded or stolen value is already useless.
Keep the most powerful credentials on the cleanest devices
The classic Active Directory tier model split assets into Tier 0 (identity systems), Tier 1 (servers and applications) and Tier 2 (user devices). Microsoft now describes the same idea as the enterprise access model, with a control plane, a management plane and a data and workload plane. The rule is the same in both: a credential from a higher tier must never be used on, or exposed to, a device in a lower tier.
A device is only as trustworthy as the least trusted thing that controls it. A Global Administrator who signs in from a laptop used for email and browsing has effectively made that laptop part of the control plane.
Seven rules that remove most privileged risk
- Separate admin accountsAdmins use a dedicated privileged account, with no mailbox and no web browsing, alongside their everyday one.
- Cloud-only adminsPrivileged Entra roles go to cloud-only accounts, not accounts synchronised from Active Directory, so an on-premises compromise cannot reach them.
- Privileged access workstationsTier 0 and Tier 1 work happens from hardened, dedicated devices.
- No standing privilegeMake admins eligible and activate just in time (Lab 07).
- Managed service identitiesPrefer group managed service accounts and managed identities, which rotate their own secrets, over accounts with static passwords.
- No interactive logon for servicesService accounts should be denied interactive and remote desktop sign-in.
- Two monitored break-glass accountsCloud-only, excluded from Conditional Access, protected with a phishing-resistant method, stored securely, and alerting on every use (Labs 03 and 04).
PAM, PIM, PASM and PEDM
These are often used interchangeably. They overlap, but they are not the same thing.
The overall discipline and the umbrella for the capabilities on this page.
Managing which identities hold privileged roles, and when. In Microsoft's world it is the Entra feature for just-in-time role activation.
Vaulting shared privileged credentials and brokering and recording the sessions that use them.
Granting specific elevated rights on endpoints and servers instead of full admin.
The IDAM and PIM Foundations guide goes deeper on just-in-time roles in Microsoft Entra.
Start small, then layer on
Know and protect
- Inventory privileged roles and accounts
- Phishing-resistant MFA for admins
- Separate, cloud-only admin accounts
- Two break-glass accounts
Control
- Just-in-time activation for all admin roles
- Vault and rotate shared and service credentials
- Windows LAPS everywhere
- Quarterly access reviews of privileged roles
Isolate and detect
- Tiering and privileged access workstations
- Brokered, recorded sessions
- Secrets management for workloads
- Alerting on privileged activity