Who is accountable when forgotten access and stale privileges create exposure?

Why This Matters for Security Teams

Forgotten access and stale privileges are not just hygiene issues. They create a governance gap where no one is clearly accountable for who can still act, why that access still exists, or when it should be removed. In NHI-heavy environments, that gap is amplified because service accounts, API keys, and automation tokens often outlive the teams that created them.

NHI Management Group research shows that only 5.7% of organisations have full visibility into their service accounts in the Ultimate Guide to NHIs, which means stale access is frequently hidden until an incident forces discovery. OWASP’s Non-Human Identity Top 10 treats excess privilege and weak lifecycle control as core risk drivers, not edge cases. The operational lesson is simple: if ownership is vague, revocation becomes optional, and exposure persists by default.

In practice, many security teams encounter stale privileges only after a breach review or application outage has already exposed the gap.

How It Works in Practice

Accountability should be assigned at two layers: the business owner of the entitlement, who approves why access exists, and the operational owner, who executes review, rotation, and revocation. That split matters because ownership without execution leads to shelfware controls, while execution without business ownership leads to over-revocation and downtime. Current guidance suggests documenting both roles in the entitlement record so review, recertification, and offboarding are never ambiguous.

For NHIs, this means the entitlement should be tied to a workload, a service, or a pipeline, not to a person who may have left the team months ago. The most effective programs pair inventory with lifecycle enforcement, using the principles described in the Ultimate Guide to NHIs — Key Challenges and Risks and implementation guidance from the OWASP Non-Human Identity Top 10. In mature environments, the control set usually includes:

• Named entitlement owners with authority to approve continued access
• Operational owners responsible for rotation and revocation SLAs
• Periodic access recertification with evidence of business need
• Automated detection of dormant, orphaned, or duplicated privileges
• Clear offboarding paths for applications, integrations, and API consumers

For auditability, teams increasingly map this work to governance frameworks such as NIST Cybersecurity Framework 2.0, because it forces explicit ownership rather than informal stewardship. These controls tend to break down when access is embedded in code, scripts, or CI/CD pipelines because no single team can prove who owns the secret at runtime.

Common Variations and Edge Cases

Tighter entitlement governance often increases operational overhead, requiring organisations to balance faster delivery against stronger review and revocation discipline. That tradeoff becomes visible in environments with shared platform accounts, cross-functional DevOps teams, or legacy systems that cannot support clean ownership metadata.

There is no universal standard for this yet, but best practice is evolving toward treating orphaned access as a lifecycle defect rather than a one-time misconfiguration. In practice, teams should expect edge cases such as shared break-glass accounts, vendor-managed integrations, and inherited permissions from mergers or platform migrations. The right response is not to exempt them permanently, but to assign temporary owners, define expiry, and require compensating controls.

NHIMG’s research shows why this matters: 71% of NHIs are not rotated within recommended time frames, and 91.6% of secrets remain valid five days after notification in the Ultimate Guide to NHIs. That persistence is exactly where accountability fails, because revocation ownership is unclear or too slow to act. Teams that need broader incident context can use the 52 NHI Breaches Analysis to see how stale privileges repeatedly show up as root-cause material.

Where automation spans many systems and approval chains, accountability must be enforced by policy, not memory.

Related resources from NHI Mgmt Group

• When do NHI access reviews create more value than a one-time cleanup?
• When does JIT access create more risk than it reduces?
• Why do stale entitlements create so much identity risk?
• Why do non-human identities create more audit risk than human accounts?