Who should be accountable when a SaaS application is retired but access remains?

Why This Matters for Security Teams

A retired SaaS application can still expose active trust paths if tokens, API keys, SSO assignments, service accounts, or webhook integrations remain in place. That is why accountability cannot stop at the contract end date. The application owner is responsible for closure, but IAM, security, and procurement each have a verification role because retirement is only real when access is actually removed. NHI lifecycle failures are well documented in the Ultimate Guide to NHIs, and the risk pattern is consistent across incidents in the 52 NHI Breaches Analysis.

This matters because retained access often survives in places that asset inventories do not automatically reconcile: shared inboxes, CI/CD secrets, OAuth grants, backup accounts, and downstream partner integrations. The common failure is assuming procurement closeout equals technical shutdown. It does not. Security teams need a lifecycle control that proves access removal, not just a paperwork milestone. In practice, many security teams encounter leftover access only after a post-retirement incident or audit finding, rather than through intentional decommissioning review.

How It Works in Practice

Accountability should be assigned to the application owner because that role controls business disposition, dependency identification, and formal retirement sign-off. However, the owner cannot complete the job alone. IAM should confirm that all identities tied to the app are disabled or deleted, security should verify credential revocation and exception handling, and procurement should ensure the vendor relationship is not used as a proxy for technical closure. Current guidance suggests treating retirement as a control workflow, not a single ticket.

A practical closure process usually includes:

• Inventory every human and non-human access path, including SSO, service accounts, API keys, and machine-to-machine tokens.
• Rotate or revoke secrets before shutdown, then confirm no replacement credentials were issued downstream.
• Check integrations, webhooks, and scheduled jobs that may still call the service.
• Validate logs for residual authentication attempts after the retirement date.
• Require a second-party review from IAM or security before the asset is marked closed.

This aligns with the logic in the OWASP Non-Human Identity Top 10, because the major risk is not only stale accounts but unmanaged machine access that outlives the application itself. The same pattern appears in the Salesloft OAuth token breach, where trust persisted through tokens rather than the original application boundary. These controls tend to break down when SaaS retirement is handled by procurement alone because technical dependencies are rarely visible in the contract record.

Common Variations and Edge Cases

Tighter retirement control often increases operational overhead, requiring organisations to balance faster decommissioning against stronger verification. That tradeoff is real, especially in environments with hundreds of SaaS tools, multiple subsidiaries, or shadow IT. Best practice is evolving, but there is no universal standard for this yet: some organisations use a mandatory closure attestation, while others require automated evidence from IAM and secret scanners before final sign-off.

Edge cases usually involve shared infrastructure or delegated administration. For example, a SaaS may be retired for one department while still feeding reports, archives, or API calls for another. In those cases, the application owner still owns closure, but the dependency owner must prove migration or replacement first. The same issue applies when a vendor says an account is deleted but OAuth grants remain active in an adjacent tenant. That is why lifecycle checks should include identity, secret, and dependency validation across both business and technical owners.

For teams aligning controls, the important point is simple: retirement is not complete until the last access path is removed and verified. If that verification never happens, accountability remains with the application owner, but the organisation as a whole inherits the exposure.

Related resources from NHI Mgmt Group

• What is the difference between rotating a secret and revoking access?
• Who is accountable when vendor access remains active after a banking engagement ends?
• Who should be accountable when an access review is completed but risky access remains?
• Who is accountable when access remains active after a mass exodus?