Who is accountable when SaaS access is not revoked on time?

Why This Matters for Security Teams

When SaaS access is not revoked on time, the issue is rarely just a missed ticket. It usually means ownership, approval, and deprovisioning were split across teams without a single accountable operator. That creates stale entitlements, weak audit evidence, and a larger blast radius if an account is later abused. The operational pattern is familiar in NHI lifecycle work, where revocation failure is one of the most common control gaps in NHI Lifecycle Management Guide.

This matters because delayed revocation is not a low-priority hygiene issue. It is an access control failure that can become a breach-enabling condition, especially when service accounts, delegated admin roles, or API-driven SaaS integrations are involved. OWASP’s OWASP Non-Human Identity Top 10 treats lifecycle control as a core security requirement, not an administrative preference. NHI Mgmt Group research shows only 20% of organizations have formal processes for offboarding and revoking API keys, which helps explain why this problem persists. In practice, many security teams discover the accountability gap only after access has already lingered long enough to matter.

How It Works in Practice

Accountability for overdue revocation should follow the control path, not just the approval path. Identity operations typically owns execution, the application or SaaS owner owns entitlement design and technical deprovisioning requirements, and the business manager owns the decision to end access. For NHIs and SaaS-integrated automation, that split becomes even more important because access may be granted through OAuth apps, SCIM provisioning, admin consoles, or direct token issuance. If the owner cannot name the revocation trigger, the revocation SLA, and the fallback approver, the process is not operationally complete.

Best practice is evolving toward explicit lifecycle ownership, because static role assignments alone do not prove who must act when access expires. The practical control set includes:

• named entitlement owners for every SaaS app and privileged role
• time-bound approvals with a required end date
• automated deprovisioning where the SaaS platform supports it
• manual exception handling when the app has no API or SCIM path
• audit logging that shows who requested, approved, executed, and verified removal

This is also where NHI governance and human access governance converge. If a service account retains access after a contractor leaves, or if an integration token is left active after a project closes, the accountable party is the one responsible for the revocation path, not only the original approver. The Top 10 NHI Issues guide and Ultimate Guide to NHIs both emphasise lifecycle ownership because stale access often survives normal ticket closure. These controls tend to break down when SaaS ownership is shared across security, IT, and business units because no single team can prove it owns the final revocation step.

Common Variations and Edge Cases

Tighter revocation controls often increase operational overhead, requiring organisations to balance speed of access changes against verification and evidence requirements. That tradeoff becomes sharper in high-change environments where employees move roles often, vendors need temporary access, or SaaS applications lack reliable provisioning APIs. Current guidance suggests that if automation cannot complete the removal, the accountable owner must be explicitly reassigned to a human operator for follow-up.

There is no universal standard for this yet, but most mature programs separate three cases. First, where the entitlement owner is clearly documented, that owner is accountable for timely removal. Second, where a manager approved access but the application team controls the technical path, accountability is shared and must be documented in the runbook. Third, where no owner exists, the control failure is itself a governance defect that should escalate to identity leadership.

For SaaS access tied to secrets, tokens, or delegated admin sessions, the revocation path may also require rotating or invalidating credentials, not just disabling a user record. NHI Mgmt Group’s Static vs Dynamic Secrets guidance is useful here because stale credentials can outlive the access decision that created them. The policy lesson is simple: if no one can name the revocation owner before the request is approved, accountability was never established in the first place.

Related resources from NHI Mgmt Group

• When do NHI access reviews create more value than a one-time cleanup?
• How can teams keep payment access accountable as crypto products grow?
• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities that have persistent access?