Who is accountable when cloud access expires on paper but persists in practice?

Accountability sits with the team that owns policy enforcement across the cloud control plane, not only the team that approves access. If expiry is handled in tickets, directory sync, or manual follow-up, the organisation has not actually governed revocation. Frameworks such as NIST CSF and ZTA expect effective control, not paperwork.

Why This Matters for Security Teams

When cloud access expires on paper but remains usable in practice, the issue is not just missed cleanup. It means the organisation has lost control of revocation across identity stores, cloud-native permissions, and automation paths. That creates a mismatch between policy intent and actual enforcement, which is exactly where privilege creep, dormant access, and audit failure emerge. The operational question is who can prove revocation happened, not who approved the original grant.

For cloud and NHI programs, this is a lifecycle problem, not a ticketing problem. The NHI Lifecycle Management Guide and the OWASP Non-Human Identity Top 10 both point to the same failure mode: access that is time-bounded in policy but not actually time-bounded in enforcement. In the 2024 Non-Human Identity Security Report, NHIMG research found that 59.8% of organisations see value in dynamic ephemeral credentials, which reflects how often static expiry workflows fail in practice. In practice, many security teams discover expired access still active only after an incident review or audit sampling, rather than through intentional revocation testing.

How It Works in Practice

Accountability follows the control owner who can actually stop access in the cloud control plane. If a platform team, IAM team, or app owner only approves access but cannot ensure revocation in AWS, Azure, GCP, SaaS, or automation tooling, then accountability is split and usually broken. The practical standard is effective control, not administrative intent. That aligns with NIST Cybersecurity Framework expectations for access control and the trust principles in NIST SP 800-207 Zero Trust Architecture.

In mature environments, the accountable team owns three things:

• the authoritative source for entitlement expiry, whether that is HR, a workflow engine, or policy-as-code
• the enforcement point that removes permissions, disables tokens, or revokes sessions in the target platform
• evidence that revocation completed, including logs, alerts, and exception handling

For NHI and agentic workloads, this is even stricter. Static credentials and delayed cleanup are poor fits for autonomous systems that can continue using a token long after a ticket is closed. Guidance from the Ultimate Guide to NHIs — Static vs Dynamic Secrets and the Guide to the Secret Sprawl Challenge shows why short-lived, dynamically issued secrets are preferred when revocation must be dependable. In the 2024 report, 88.5% of organisations said their non-human IAM practices lag human IAM, which is a strong signal that expiry semantics are still too manual. These controls tend to break down when revocation depends on directory sync or human follow-up because the cloud permission often outlives the approval record.

Common Variations and Edge Cases

Tighter revocation control often increases operational overhead, requiring organisations to balance enforcement confidence against workflow complexity. That tradeoff becomes visible in hybrid clouds, cross-account access, and service-to-service automation where a single approval may map to several independent permission planes.

There is no universal standard for this yet, but current guidance suggests the accountable party should be the team that owns the revocation mechanism end to end, not the committee that reviewed the request. In practice, that may mean platform engineering for cloud roles, IAM for federated identity, or application owners for embedded service credentials. The hardest cases are break-glass access, long-lived API keys, and delegated admin paths because they often bypass ordinary expiry logic. For those cases, the best practice is evolving toward just-in-time access, short TTLs, and runtime checks rather than calendar-based cleanup. The Top 10 NHI Issues is useful here because secret sprawl and unmanaged renewal are recurring drivers of expired-but-active access.

Where agents or automation are involved, accountability should also include the team that defines the policy decision point, because access may need to be re-evaluated at request time instead of relying on a one-time grant. That is especially important when workload identities, ephemeral tokens, or delegated tool access are involved. The guidance is clear on the direction, but the implementation details still vary by cloud and vendor. Best practice is to verify revocation in the target system, not just in the ticketing system.

Related resources from NHI Mgmt Group

• Who is accountable when unauthorized access persists in a cloud environment?
• Who is accountable when sustained infrastructure attacks disrupt access and availability?
• Who should be accountable when a compromised mailbox leads to fraud or access loss?
• How should security teams prioritise NHI remediation in cloud environments?