The application owner is accountable for ensuring revocation works immediately across every provider type. A disconnect action must stop access at once, whether the credential is an OAuth token or an API key. If revocation depends on expiry that never comes, the organisation has an unmanaged access path and a governance failure.
Why This Matters for Security Teams
Disconnected integrations are not a user-experience nuisance. They are an access-control problem. When a user clicks disconnect, the organisation is expected to terminate the integration’s effective access across every provider, tenant, and downstream token type. That includes OAuth grants, refresh tokens, service credentials, and API keys. If any of those survive, the integration still has an unmanaged path into production systems.
This is why NHI governance has to treat revocation as a lifecycle control, not a courtesy feature. NHIMG’s Ultimate Guide to NHIs notes that only 20% of organisations have formal processes for offboarding and revoking API keys, which helps explain why disconnect actions are so often incomplete. OWASP’s Non-Human Identity Top 10 also treats weak lifecycle control as a core failure mode, not an edge case.
For security teams, the important point is accountability. The application owner must ensure that revocation actually reaches every issuer and every consumer of the credential, because delegation does not transfer responsibility. In practice, many teams discover this only after a disconnected app is still reading data or calling APIs days later.
How It Works in Practice
Accountability sits with the application owner because they control the integration design, the provider configuration, and the revocation workflow. A proper disconnect should trigger immediate invalidation of active access, not merely removal from a UI list. In a well-governed model, the system should revoke OAuth grants, destroy refresh tokens, expire session-bound access, and disable API keys or certificates tied to the integration.
That requires more than a single API call. Teams usually need a revocation chain that covers both the connected application and the identity provider. NIST’s SP 800-53 Rev. 5 Security and Privacy Controls supports this kind of lifecycle rigor through access termination and privilege management controls, while NHIMG’s Klue OAuth Supply Chain Breach illustrates how third-party grants can remain dangerous long after the original connection looked “removed.”
- Track each credential type separately, because OAuth tokens, API keys, and certificates fail in different ways.
- Revoke at the source, not only in the app’s database or admin console.
- Verify that refresh tokens, cached access tokens, and delegated scopes are all invalidated.
- Log the disconnect event, the revocation result, and any orphaned permissions left behind.
- Test the revocation path routinely, because a control that is not exercised often fails when needed most.
The operational standard is simple: disconnect means no usable access remains. Anything short of that is residual privilege, and residual privilege belongs to the application owner. These controls tend to break down in multi-tenant SaaS environments where the integration vendor, the customer admin, and the identity provider all maintain separate revocation state.
Common Variations and Edge Cases
Tighter revocation control often increases integration complexity, requiring organisations to balance immediate shutdown against uptime, user support, and vendor limitations. That tradeoff is real, but current guidance suggests it should never justify indefinite access. In some platforms, a disconnect can only prevent future refreshes rather than instantly kill already-issued access tokens, so the owner must add compensating controls such as very short token lifetimes or explicit vendor-side revocation APIs.
There is no universal standard for this yet across every SaaS and API provider, which is why the ownership model matters more than the implementation detail. If an integration uses a long-lived API key, the revocation obligation is even stricter because expiry may not exist at all. If the connection spans multiple systems, one provider may confirm revocation while another continues to honor the same credential. NHIMG’s Ultimate Guide to NHIs and Key Challenges and Risks is useful here because it frames lifecycle gaps as governance failures, not just technical debt.
The practical rule is that the application owner must prove end-to-end revocation, especially when the integration uses delegated access, third-party brokers, or shadow IT tooling. If the owner cannot verify that a disconnected integration is actually inert, the organisation still has an active identity path.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 | Covers revocation and lifecycle gaps for non-human identities. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions must be removed when a connection is terminated. |
| NIST SP 800-63 | Credential lifecycle and revocation are central to identity assurance. | |
| NIST Zero Trust (SP 800-207) | SC.L2-1 | Zero Trust requires continuous re-evaluation and no implicit standing access. |
| NIST AI RMF | Governance should assign accountability for autonomous or delegated access paths. |
Verify every disconnect path fully revokes NHI access and test it against each credential type.
Related resources from NHI Mgmt Group
- Who is accountable when an application keeps access after a user leaves the directory?
- Who is accountable when a third-party integration keeps an NHI active after the business need ends?
- Who is accountable when user access remains active after offboarding?
- Who is accountable when a third party keeps access after the work ends?
