Who is accountable when eligible admin access is left active without approval or time limits?

Why This Matters for Security Teams

Eligible admin access that stays active without approval or a time limit is not a minor process gap. It is a standing privilege problem that weakens accountability, obscures ownership, and makes review meaningless. The control owner must be able to explain why the elevation exists, who can activate it, and what conditions terminate it. NIST’s Security and Privacy Controls and the OWASP Non-Human Identity Top 10 both reinforce that access must be bounded, reviewable, and tied to explicit governance.

For NHI environments, the risk is amplified because admin eligibility often applies to service accounts, API keys, workload identities, and automation paths that do not behave like human users. If activation can occur without approval, TTL, or recorded purpose, then privileged access is effectively permanent even when policy says otherwise. NHIMG’s Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which is why “eligible” without activation discipline still creates broad exposure. In practice, many security teams encounter the abuse of active admin paths only after an incident review reveals there was no one clearly accountable for the activation decision.

How It Works in Practice

Accountability should follow the control path, not just the identity record. Identity owners typically manage lifecycle and attribution, infrastructure owners manage the systems that enforce elevation, and security owners define the policy that makes activation acceptable. The control owner must be able to answer three questions at any time: who can activate, under what conditions, and how long the privilege can remain active.

In a mature process, eligible admin access is converted into just-in-time activation. The request is evaluated at runtime, approved against context, and issued as a short-lived privilege window. That can be enforced with privileged access management, policy-as-code, and workload identity patterns that support cryptographic proof of the actor or workload. For NHI and agentic workloads, current guidance suggests using OWASP NHI principles alongside runtime policy checks, because static role assignment cannot explain why a task needed elevation at a specific moment.

• Define an approval owner for every privileged activation path.
• Set a time-to-live for each elevation and revoke automatically when the task ends.
• Log who approved, who activated, and what business or operational condition justified it.
• Review inactive eligible roles and remove any path that cannot be explained.

NHIMG’s Ultimate Guide to NHIs - Key Challenges and Risks emphasizes that weak visibility and excess privilege are common, which is why governance must verify the full activation workflow rather than assuming the entitlement model is sufficient. These controls tend to break down in highly automated environments where service accounts, CI/CD jobs, and cloud-native admins share the same role names but not the same operational context.

Common Variations and Edge Cases

Tighter activation control often increases operational friction, requiring organisations to balance emergency response speed against the risk of uncontrolled privilege. That tradeoff is real in break-glass accounts, incident response, and legacy platforms that cannot support fine-grained approval workflows.

There is no universal standard for this yet, but best practice is evolving toward separate handling for emergency access, with compensating controls such as stronger logging, post-use review, and narrow expiry windows. The hardest edge case is when “eligible” access is created for convenience but never tied to a named approver or a revocation rule. In those environments, the control owner is still accountable even if the platform team operates the mechanism, because ownership includes proving that standing privilege is not hiding inside an unused activation path.

For NHI-heavy estates, this matters even more when access is delegated to automation or third parties. NHIMG’s research and the broader operational guidance from NIST SP 800-53 Rev. 5 both point to the same conclusion: if no one can explain who may activate the privilege and for how long, then governance has not actually been implemented.

Related resources from NHI Mgmt Group

• When do NHI access reviews create more value than a one-time cleanup?
• Who is accountable when access is left active after a role change or departure?
• Who is accountable when contractor access is left active in a critical environment?
• Who is accountable when external access is left active after a supplier relationship changes?