How to control administrator, break-glass, and sensitive operational access with just-in-time privilege, approval, logging, and review.
Privileged access is access that can materially change system security, availability, data integrity, or evidence. It includes administrator roles, key-management rights, production deployment authority, identity administration, audit-log control, database owner rights, and emergency break-glass access.
The point of privileged access management is not to make administrators miserable. The point is to ensure that powerful access is justified, time-bounded when possible, individually attributable, strongly authenticated, and visible afterward.
| Control | What it reduces |
|---|---|
| Dedicated admin accounts | Accidental use of privileged rights during normal work |
| MFA or phishing-resistant authentication | Account takeover risk for powerful identities |
| Just-in-time elevation | Standing privilege and long exposure windows |
| Approval workflow | Unauthorized or unnecessary privileged sessions |
| Session logging or command recording | Loss of accountability during sensitive actions |
| Privilege separation | One actor controlling too many incompatible steps |
| Break-glass controls | Inability to respond when normal identity systems fail |
| Access review | Privilege drift after role changes or incidents |
The strongest design usually combines several controls. MFA alone does not justify permanent global administrator rights.
flowchart LR
A["Admin requests elevation"] --> B["Policy checks role, risk, and reason"]
B --> C["Approval or automated eligibility"]
C --> D["Temporary privileged session"]
D --> E["Action logged and reviewed"]
E --> F["Privilege expires"]
This pattern narrows time while preserving accountability. It is especially strong for maintenance windows, incident response, production deployments, and sensitive data access.
Break-glass accounts or procedures exist for emergencies: identity-provider outage, federation misconfiguration, lost administrator access, or severe operational incident. They should be:
A break-glass account that becomes a daily shared admin login is no longer emergency control. It is unmanaged standing privilege.
Every platform has a highest-risk authority: cloud root user, tenant global administrator, domain administrator, cluster-admin, database owner, or organization owner. Strong answers typically:
When an exam option uses the highest-privilege account for routine work, treat it with suspicion.
Privileged actions must be attributable. Useful evidence includes:
Shared administrator accounts, generic service accounts, and copied credentials weaken evidence even when they appear convenient.
| Trap | Corrective rule |
|---|---|
| “All admins need permanent broad access.” | Use eligibility, JIT elevation, scoped roles, and emergency fallback. |
| “MFA is enough for global admin.” | MFA is one control; privilege scope, time, logging, and review still matter. |
| “Shared admin accounts simplify operations.” | They break accountability and deprovisioning. |
| “Break-glass should be easy for everyone.” | It should be available under emergency procedure, not casual access. |
| “Disable logging during incident response.” | Incidents increase the need for evidence. |
A security team wants database administrators to perform emergency maintenance without keeping permanent owner rights active all month. The organization also needs evidence of who used elevated access. Which design is strongest?
A. A shared database owner account stored in a password manager
B. Permanent owner rights for every database administrator
C. Just-in-time privileged access with individual identities, approval or eligibility policy, MFA, expiration, and audit logging
D. A public maintenance account with a rotating password
Best answer: C. It narrows standing privilege, preserves individual accountability, and produces usable evidence.