Privileged access management: admin accounts, just-in-time access and break-glass
In short: Privileged accounts can change or destroy everything, so attackers target them first. Privileged access management removes standing admin rights, vaults and rotates credentials, records admin sessions and keeps a tested emergency route. The aim is fewer admins, for less time, with more oversight.
Why privileged access is different
A privileged account can change configuration, read any data or create other accounts. Examples include cloud global administrators, root accounts, domain admins, database owners and the service accounts behind backup or deployment tools. Once attackers have one of these, they can disable logging, delete backups and spread freely. That is why ransomware groups hunt for admin credentials early in an intrusion.
Privileged access management (PAM) is the set of controls that reduce how many privileged accounts exist, how long their power is available and how closely it is watched.
Core controls
| Control | What it does | Example |
|---|---|---|
| Separate admin accounts | Admin rights never used for email or browsing | adm-jsmith alongside jsmith |
| Credential vault | Stores shared and service passwords, rotates them automatically | Server local admin passwords checked out per task |
| Just-in-time (JIT) access | Rights granted only when needed, then expire | Microsoft Entra Privileged Identity Management, temporary AWS role sessions |
| Session recording | Captures keystrokes or video of admin sessions | Bastion or PAM proxy for SSH and RDP |
| Privileged access workstation (PAW) | Hardened device used only for admin work | No email, locked-down browser |
Just-in-time access
With standing access, an admin holds their rights 24 hours a day, so a stolen password is immediately powerful. With just-in-time access, the admin is merely eligible for the role. When they need it, they request activation with a reason and a time limit, perhaps with approval and an MFA prompt. After a few hours the role drops away automatically. Combined with just-enough administration (scoping the role to only the resources involved), this shrinks the window for misuse dramatically.
In AWS, the equivalent is to avoid long-lived IAM user keys for admins and instead assume roles that issue temporary credentials, ideally through AWS IAM Identity Center. The root user should have strong MFA and be used only for the few tasks that require it.
Break-glass accounts
A break-glass (emergency access) account lets you recover when normal sign-in fails, for example if the identity provider or MFA service is down or a conditional access policy locks everyone out. Good practice:
- Keep two such accounts, cloud-only and excluded from policies that could lock them out, but still protected by strong authentication such as FIDO2 keys stored securely.
- Store credentials offline in a safe, split between trusted people where practical.
- Alert on any sign-in by these accounts.
- Test them on a schedule so you know they work when needed.
Tip: count your permanent global admins. A small organisation rarely needs more than a handful; everything else should be eligible-only or a narrower role.
Common mistakes
- Admins reading email with the same account that manages the tenant.
- Service account passwords that never change and are known by former staff.
- Break-glass accounts that nobody has tested or that have no alerting.
- Session recordings that are captured but never reviewed or protected from tampering.
Practice
What is the difference between standing and just-in-time privileged access?
Why should break-glass account sign-ins trigger an alert?
Why use a separate admin account instead of giving admin rights to an everyday account?
Key takeaways
- Privileged accounts are prime targets because they control everything else.
- Use separate admin accounts, vaulting and automatic rotation.
- Just-in-time access removes standing rights and limits the attack window.
- Record and review privileged sessions.
- Keep tested, monitored break-glass accounts for emergencies.
Original content written by Mohamed Fayas for FM TecHub. © 2026 FM TecHub. You're welcome to share a link to this page; please don't copy the text elsewhere without permission.