The Standing Privilege Problem
In most organisations, privileged access works like this: an administrator is granted Domain Admin rights when they join the team. They use those rights when they need them — which might be a few hours per week. The rest of the time, those Domain Admin rights sit on the account doing nothing. But they are still there. If that account is compromised — by phishing, credential theft, or session hijacking — the attacker immediately has Domain Admin access. The entire attack timeline from initial compromise to full domain control can be measured in minutes.
This is the standing privilege problem. The duration of elevated access vastly exceeds the duration it is actually needed. Every minute a privileged account is not actively using its rights is a window in which a credential compromise translates to a full privilege compromise.
The Blast Radius of Standing Privilege
Standing privilege determines breach blast radius. An attacker who compromises a standard user account can access what that user can access. An attacker who compromises a Domain Admin account can access everything. The difference in remediation cost, regulatory notification requirements, and reputational impact between these two scenarios is enormous. Standing privilege is what transforms a credential compromise into a catastrophic breach.
The persistence of standing privilege means that the attacker does not need to act immediately. They can maintain quiet access for days or weeks while they understand the environment, identify high-value targets, and plan their actions. If the credential is rotated (for example, during a routine password change), the attacker simply re-executes the initial compromise — because the underlying vulnerability that allowed credential theft is still present. The access is persistent because the privilege is persistent.
What Zero Standing Privilege Means in Practice
Zero Standing Privilege (ZSP) is the principle that privileged accounts should not permanently hold elevated permissions. Instead, elevation is requested when needed, granted for a defined time period with a defined scope, and automatically revoked when the time period expires. The baseline state of all accounts — including those belonging to senior administrators — is standard user access.
In a ZSP implementation:
- An administrator needs to deploy a configuration change. They submit a request for elevation to Server Operator rights on the target server group, for two hours, for the stated purpose.
- The request triggers approval — from a peer, a manager, or an automated policy check (e.g., linked to a change management ticket).
- Elevation is granted. The administrator's account temporarily receives the requested permissions.
- Two hours later, the permissions are automatically revoked. The administrator's account returns to standard user.
- All steps — request, approval, grant, use, revocation — are logged for audit.
If the administrator's account is compromised during the window when elevation is active, the attacker has limited access for a limited time. If compromised when no elevation is active, the attacker has standard user access — a very different incident. ZSP does not prevent compromise; it contains its impact.
Just-in-Time vs Just-Enough Access
ZSP is implemented through two complementary concepts. Just-in-Time (JIT) access controls the time dimension — elevation is temporary and expires automatically. Just-Enough Access (JEA) controls the scope dimension — elevation is scoped to the minimum permissions needed for the specific task, not to a catch-all administrative role. Combined, JIT + JEA means an administrator requesting access to restart a service gets "restart this specific service on this specific server for one hour" — not "Domain Admin for eight hours."
Implementation: Microsoft Entra ID PIM
For organisations using Microsoft 365 and Azure, Entra Privileged Identity Management (PIM) is the primary JIT implementation tool for cloud and hybrid environments. PIM is included in Microsoft Entra ID P2 (previously Azure AD Premium P2), which is part of Microsoft 365 E5 or purchasable as an add-on.
What PIM Controls
PIM enables JIT elevation for Entra ID directory roles (Global Administrator, Security Administrator, Privileged Role Administrator, and all others), Azure resource roles (Owner, Contributor, and custom roles), and Microsoft 365 workload-specific roles (Exchange Administrator, SharePoint Administrator, etc.). It does not natively control on-premises Active Directory roles — that requires a PAM solution or Active Directory shadow groups managed by PIM-triggered automation.
PIM Eligible vs Active Assignments
PIM distinguishes between eligible and active role assignments. An eligible assignment means the user is authorised to request elevation but does not hold the role permanently. An active assignment means they hold it continuously. The ZSP target state is: all privileged roles configured as eligible assignments, with no permanent active assignments for individuals (except for emergency break-glass accounts, see below). When an administrator needs to use their Global Admin rights, they activate the eligible assignment in PIM — providing a reason, triggering approval if required, and receiving a time-limited active assignment.
PIM Configuration Recommendations
- Require MFA on activation for all privileged roles — even if MFA is already required for the account, PIM should enforce step-up authentication at the point of elevation
- Set maximum activation duration appropriate to the role: 1–2 hours for Global Admin, 4–8 hours for resource roles
- Require justification (free-text or linked change ticket) on all activations — this creates the audit trail DORA supervisors will request
- Configure approval for the most sensitive roles (Global Admin, Privileged Role Administrator) — peer or manager approval adds a second factor that attacker-controlled accounts cannot satisfy
- Enable access reviews for eligible assignments — quarterly reviews confirm that the set of people eligible for elevated roles remains appropriate
Implementation: On-Premises and PAM Vault Approaches
For on-premises Active Directory environments, Entra PIM does not directly control AD security groups. JIT elevation for on-premises requires either:
Microsoft Identity Manager (MIM) PAM
Microsoft Identity Manager's PAM capability (now in extended support) provides JIT access to Active Directory security groups. Users request elevation into a shadow privileged group; MIM grants time-limited group membership; AD security group membership expires automatically. This is the Microsoft-native approach for on-premises JIT, but MIM requires significant infrastructure and is complex to maintain.
Third-Party PAM Vaults
Purpose-built PAM solutions (CyberArk, BeyondTrust, Delinea, Wallix, and others) provide JIT elevation for on-premises infrastructure with richer workflow capabilities than MIM. The typical approach is credential vaulting — the PAM vault holds privileged account passwords (including local admin accounts on every server), rotates them automatically after each use, and issues them on request for defined sessions. The account password is never known to the human administrator; they connect through the PAM vault session. When the session ends, the password rotates.
Privileged Access Workstations (PAWs)
PAWs are hardened workstations used exclusively for administrative tasks. They are network-isolated, have no internet access, do not permit email or general browsing, and are only used to connect to privileged systems. PAWs are a complementary control to JIT access — even with ZSP, if an administrator's primary workstation is compromised and they elevate from it, the attacker benefits from the elevation window. A PAW eliminates the workstation as an attack vector during the elevation period.
Break-Glass Accounts and Emergency Access
ZSP requires a clear exception process for emergencies where the normal approval and activation workflow cannot be followed — a security incident, a critical system outage, or a scenario where the identity platform itself is unavailable.
Break-glass accounts are emergency access accounts with permanent active privilege assignments, specifically for these scenarios. They are not used for routine administration. They are subject to stringent controls:
- Stored credentials split across two or more physical security containers, requiring two authorised individuals to access
- Any use of break-glass accounts generates immediate alerts to security leadership
- Passwords rotated immediately after use
- All break-glass sessions recorded and reviewed post-incident
- Regular testing to confirm accounts are functional (quarterly at minimum)
- Excluded from Conditional Access policies that might block access during an incident
The existence of break-glass accounts is not a failure of ZSP — it is a designed and controlled exception. The risk is bounded because use is monitored, credentials are split, and accounts are not used routinely. Untested break-glass accounts that do not work when needed represent a greater operational risk than a well-managed exception process.
Regulatory Drivers for ZSP
DORA Article 9
DORA Article 9(4)(c) requires ICT security policies covering "identity management and authentication controls including privileged access management." The European Banking Authority's (EBA) technical standards for DORA implementation reference JIT access and time-limited privilege elevation as indicators of mature privileged access management. Financial entities in scope of DORA are expected to demonstrate that standing Domain Admin and Global Admin assignments have been eliminated — or that a remediation programme is underway with a defined timeline.
NIS2 Article 21
NIS2 Article 21(2)(j) requires access control policies and asset management covering "the use of privileged access." The ENISA implementation guidance describes JIT privileged access management as a recommended control for essential service operators. For organisations in sectors covered by NIS2, the absence of JIT controls for privileged accounts is likely to be cited as a gap in supervisory assessments.
NCSC CAF
CAF Indicator of Good Practice B2.b explicitly references "privileged access workstations," "just-in-time access," and "time-limited privileged credentials" as indicators of good practice for privileged account management. CNI operators assessed against CAF are expected to demonstrate progress toward these practices. CAF is a maturity-based framework — organisations are not expected to achieve all indicators immediately — but ZSP is clearly in scope as the target state for mature privileged access management.
Assess Your Standing Privilege Exposure
IdentityFirstMRI identifies all accounts with permanent privileged role assignments — Domain Admin, Global Admin, Privileged Role Administrator, and custom elevated groups — and quantifies the standing privilege exposure across your environment. The assessment provides the baseline needed to scope a ZSP implementation programme and demonstrates posture to auditors and regulators.
See IdentityFirstMRI Assessment