A standing administrative account — one with elevated privileges active at all times, whether or not anyone is actively doing admin work — is a persistent, high-value target. If it's compromised, the attacker inherits full admin rights immediately, with no additional step required. Privileged Identity Management (PIM) and related practices exist to shrink that exposure window without making legitimate administrative work harder than it needs to be.
The problem with standing privileged access
Most compromise scenarios don't start with an attacker directly targeting an admin account — they start with any account, then look for a path to privilege. If every admin account is always privileged, that path is trivially short: compromise the account, inherit the privilege, no further steps needed. If admin accounts are privileged only when actively needed and explicitly activated, an attacker who compromises the account outside of an active elevation window gets a standard, unprivileged account instead.
This is the same principle as least-privilege access, applied to time
Least-privilege access limits what an account can do to only what's necessary. Just-in-time privileged access limits when that elevated capability is active to only when it's actually being used — the same underlying principle (minimize standing exposure) applied along a different dimension.
Just-in-time privileged access (PIM)
Microsoft Entra Privileged Identity Management is the platform-specific implementation of this principle for Entra ID: eligible administrators request activation of a privileged role for a limited time window, optionally requiring approval, justification, and MFA re-authentication at the moment of activation, rather than holding the role permanently.
| Property | Standing Access | Just-in-Time (PIM) |
|---|---|---|
| Privilege active | Always | Only during an approved, time-boxed activation window |
| Compromise impact if account is breached outside active use | Full privileged access immediately available | Attacker inherits a standard account; privilege must still be separately activated |
| Audit trail | Privilege use is not distinguishable from privilege existence | Every activation is logged with justification, approver (if required), and duration |
| Operational friction | None — always available | A brief activation step when privileged work is actually needed |
Break-glass accounts
A break-glass (emergency access) account is a credential specifically reserved for regaining administrative access if normal authentication paths fail — most commonly, if a Conditional Access policy misconfiguration locks out standard administrative accounts (see Microsoft Entra Conditional Access: A Practical Guide).
Break-glass accounts occupy an intentional exception to several practices covered elsewhere in this cluster: they are typically excluded from Conditional Access policies (so a policy error can't lock them out too) and may not use the organization's standard MFA method (to avoid a single MFA provider outage becoming a total lockout). This exception is only safe because of compensating controls:
- Strong, unique, fully random credentials — not memorized, generated and stored per the Password Manager Guide's service-account guidance.
- Physical or otherwise segregated storage of the credential, not general IT staff access.
- Active monitoring and alerting on any sign-in activity — break-glass accounts should show essentially zero activity outside genuine emergencies.
- Periodic testing of the account (verifying it still works) without leaving it in routine use.
Excluded from policy does not mean weakly protected
Break-glass accounts are the one place standing, unrestricted access is intentionally accepted — which makes their own protection (credential strength, storage, monitoring) more important, not less, than a standard admin account's.
Privileged access workstations (PAWs)
A privileged access workstation is a dedicated device used only for administrative tasks — no general email, web browsing, or day-to-day productivity work — specifically to reduce the chance that an admin's elevated session is compromised via a malware infection or phishing attempt that occurred during unrelated everyday use. This is a stronger control than most small organizations implement fully, but the underlying principle scales down: at minimum, avoid performing privileged administrative work from the same session or device used for general email and web browsing, even without a fully dedicated separate machine.
Service accounts and privileged access
Service accounts (non-human, application-to-application credentials) deserve the same standing-privilege scrutiny as human admin accounts, and often receive less. A service account with permanent, broad privileges that was provisioned once and never reviewed is a common, under-examined source of privilege exposure — see the Password Manager Guide's service-account section for credential handling, and treat the scope of a service account's privilege with the same "does this actually need to be standing and this broad" question applied to human admin roles.
Practical recommendations
- Move standing administrative role assignments to PIM-eligible, time-boxed activation wherever the platform supports it.
- Require justification and, for the highest-privilege roles, approval on activation, creating both friction against casual overuse and a genuine audit trail.
- Maintain exactly the number of break-glass accounts needed for redundancy (commonly two), documented, monitored, and periodically tested.
- Require phishing-resistant MFA specifically for privileged role activation, distinct from the standard MFA method used for general sign-in.
- Review standing (non-PIM) privileged role assignments periodically, treating any that remain as an exception requiring justification, not a default state.
- Extend the same scrutiny to service accounts — audit standing privilege scope, not just human admin accounts.
Common mistakes
- No break-glass account at all, or break-glass credentials stored insecurely (in a shared document, in a general password manager vault accessible to too many people).
- PIM activation with no justification requirement, which removes the audit-trail benefit even though the time-boxing benefit remains.
- Treating PIM as a one-time project rather than an ongoing practice — new administrative roles created after the initial rollout often quietly default back to standing access unless PIM adoption is part of the standard provisioning process.
- Ignoring service account privilege scope while focusing exclusively on human administrative accounts.
- Using the organization's standard MFA method for break-glass accounts, creating a single point of failure if that MFA provider has an outage during an actual emergency.
FAQ
Does every organization need Privileged Identity Management, or is it only for large enterprises? The underlying principle (minimize standing privileged access) benefits organizations of any size. Full PIM tooling requires a specific Entra ID license tier, but smaller organizations can approximate the same outcome manually — reviewing and minimizing standing admin role assignments on a defined schedule — even without the automated activation workflow.
How many break-glass accounts should we have? Commonly two, providing redundancy without unnecessary additional attack surface. Both should be documented, monitored for any activity, and periodically tested to confirm they still function.
Should service accounts ever have standing privileged access? Sometimes it's unavoidable for a given integration, but the scope should be minimized and reviewed — a service account with tenant-wide administrative privilege for a task that only needs access to one specific resource is a common, avoidable over-grant.
What's the difference between a privileged access workstation and just using a separate admin account on the same computer? A separate admin account limits what credentials are exposed to everyday risk; a separate admin workstation limits what the entire device and session is exposed to. A compromised everyday browsing session can potentially capture credentials or tokens even for a "separate" admin account used on the same machine — the workstation-level separation addresses that gap.
Related reading
- Microsoft Entra Conditional Access: A Practical Guide
- Multi-Factor Authentication: Methods and Best Practices
- Password Manager Guide
- CIS Controls Overview — access control management as a CIS Controls IG1 safeguard
- Download: Privileged Access Governance Guide