Who is accountable when automated access expires too slowly or not at all?

Why This Matters for Security Teams

When automated access expires too slowly or never expires, the issue is not just hygiene. It is a direct failure of identity lifecycle control, revocation ownership, and auditability. Long-lived secrets, tokens, and service account entitlements create a standing path into production systems even after the original task is complete. NHI Mgmt Group notes that only 20% of organisations have formal processes for offboarding and revoking API keys, and even fewer can rotate them reliably, which is why expiry failures often persist unnoticed.

The accountability question matters because revocation is a multi-team control. IAM may define policy, PAM may broker privileged access, and platform teams may own the workload or secret store. If those boundaries are unclear, nobody is responsible when a token remains valid past its intended TTL. That is exactly the gap highlighted in the NHI Lifecycle Management Guide and reinforced by the OWASP Non-Human Identity Top 10. In practice, many security teams discover expiry failures only after a stale credential is used in an incident, rather than through intentional lifecycle testing.

How It Works in Practice

Accountability should follow control ownership, not incident blame. The team that owns the identity lifecycle must define who issues the access, who enforces expiry, who monitors revocation, and who handles exceptions. For NHI environments, that usually means an IAM or identity engineering team owns policy, a PAM or secrets platform team owns privileged issuance and rotation, and the application or platform owner owns the workload that consumes the credential. Without that split, expiry becomes everybody’s concern and nobody’s task.

Current guidance suggests making expiry enforceable at the point of issuance, not just reviewed later. That means short TTLs, automated revocation hooks, and logs that show when access was granted, extended, or removed. For autonomous systems and service accounts, the better pattern is dynamic credentials issued just in time, then revoked automatically when the task ends. The Ultimate Guide to NHIs — Static vs Dynamic Secrets explains why static credentials become hard to govern once they are embedded in pipelines or distributed across tools. NIST’s Zero Trust Architecture also supports continuous verification rather than permanent trust.

• Define one named owner for revocation decisions and one for technical enforcement.
• Require TTLs, rotation thresholds, and exception expiry dates in policy.
• Log issuance, renewal, revocation, and failed revocation attempts in a single audit trail.
• Test expiry paths the same way teams test recovery paths.

For reference, the challenge is not theoretical: NHI Mgmt Group reports that 91.6% of secrets remain valid five days after the targeted organisation is notified, which shows how often revocation fails in practice. These controls tend to break down in distributed CI/CD environments because secret sprawl makes it hard to tell which system actually has the authority to revoke the credential.

Common Variations and Edge Cases

Tighter expiry enforcement often increases operational overhead, requiring organisations to balance faster revocation against pipeline fragility and support burden. That tradeoff is especially visible where legacy applications cannot tolerate frequent token refresh, where third-party integrations cache credentials, or where emergency break-glass access must remain available for a limited window.

There is no universal standard for exception handling yet, but best practice is evolving toward explicit owner approval, time-boxed exemptions, and automatic revalidation. The Top 10 NHI Issues and the Ultimate Guide to NHIs — Key Challenges and Risks both point to the same operational reality: if exceptions are not tracked as first-class records, they become permanent access. That risk is even higher when secrets are stored outside managed vaults or copied into code and configuration.

Accountability becomes shared only in the sense that multiple teams contribute evidence, but one owner must still be able to answer who approved the access, who should have revoked it, and why the expiry did not happen. In highly federated environments, this answer often breaks down when identity and platform responsibilities are split across separate organisations or when the service account is reused across multiple applications.

Related resources from NHI Mgmt Group

• Who is accountable when cloud access expires on paper but persists in practice?
• Who is accountable when automated governance misses a toxic access combination?
• Who is accountable when automated access changes fail an audit or create privilege drift?
• Who is accountable when sustained infrastructure attacks disrupt access and availability?