The control that breaks is the assumption that revoking the application relationship automatically removes access. A live token can continue to read data, search for secrets and move laterally through the connected platform until it is explicitly revoked. That is why third-party grants need lifecycle ownership, expiry review and emergency revocation paths, not just approval at onboarding.
When trust ends but the token still works
The break is not usually the token itself, it is the control assumption around it. If a SaaS integration is decommissioned in the relationship sense but the grant, refresh token, or access token remains active, the connected system may still accept requests as if the partner were trusted. That means access can continue until expiry, explicit revocation, or sender-constrained validation stops it.
That distinction matters because third-party SaaS integrations often rely on delegated access that outlives the business relationship. A valid token can still authorize reads, exports, searches, and downstream actions even after the vendor, app owner, or security team considers the integration “offboarded.”
In practice, the failure is a lifecycle failure, not just an authentication failure. The platform is still honoring a credential that no longer matches the intended trust state, so the control gap sits between relationship governance and session revocation.
Why valid tokens become a cross-platform exposure path
A live token can be more dangerous than a simple login because it is already authenticated and often scoped broadly enough to operate quietly across a connected platform. If the token can enumerate data, query secrets, or call business APIs, the attacker or careless third party inherits that access without needing to reauthenticate.
This is why token scope, audience restriction, and revocation behavior matter as much as initial consent. A token that is valid in the wrong hands can still traverse the trust chain, and the blast radius is set by what the token can reach, not by who originally approved the integration.
The practical lesson is that “trusted integration” and “active credential” are separate states. If teams manage only the contract or app listing and ignore the token lifecycle, they leave a residual access path open after the relationship has already failed.
NHIMG’s SaaS-to-SaaS and OAuth App Governance Guide covers consent, scopes, token risk, and revocation runbooks for exactly this class of exposure.
Third-Party, B2B and Contractor Access Guide is useful here because the access problem is often broader than a single app, it is a third-party access relationship that needs ownership, expiry, and review.
Slack GitHub breach 2022 shows how stolen tokens can remain effective long enough to reach private assets after the original trust relationship is compromised.
What breaks operationally in the trust model
What breaks is the assumption that access ends automatically when the business relationship ends. In many environments, consent, refresh capability, cached sessions, and API tokens are governed separately, so removing the app or vendor from a catalog does not necessarily remove the ability to act.
The operational consequence is delayed containment. Security teams may believe they have terminated a supplier path, while the integration still has a valid credential and enough privilege to continue reading data or invoking actions. That creates a gap between governance intent and technical enforcement.
It also complicates incident response. If a token has been copied or retained by a third party, the question is not only whether the partnership is over, but whether every credential path tied to that partnership has been invalidated across all environments and replicas.
The token’s remaining lifetime becomes the residual risk window. If that lifetime is long, the control failure persists even after every human has agreed the relationship should be closed.
RFC 9700: Best Current Practice for OAuth 2.0 Security is relevant because it addresses token theft, sender-constrained tokens, and safer OAuth deployment patterns.
RFC 9449: OAuth 2.0 Demonstrating Proof of Possession (DPoP) helps reduce replay risk when a token is stolen but not bound to proof of possession.
RFC 8707: Resource Indicators for OAuth 2.0 supports audience restriction so a token cannot be reused as broadly if it leaks or outlives its intended trust boundary.
Risk and Threat Considerations
Valid third-party tokens create a residual access channel after trust has failed, which means compromise can continue even when the relationship is formally ended. The main risk is silent persistence: an attacker, ex-employee, or careless integration can keep using a credential the business believes is no longer active.
Failure mechanism: Revocation is not tied tightly enough to the integration lifecycle, so existing tokens, refresh paths, or delegated grants remain accepted after offboarding or trust loss.
Impact: The token can continue to read data, search for secrets, or move laterally through connected systems until it is explicitly revoked, increasing exposure window and containment cost.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Tokens and refresh credentials must be issued, tracked, rotated, and revoked. |
| AC-2 — Account Management | Third-party grants need lifecycle ownership, expiry, and prompt removal when no longer needed. | |
| AC-6 — Least Privilege | A still-valid token is dangerous when it can read broadly or act laterally across systems. | |
| Recommendation — Manage token lifecycle, rotation, and revocation so third-party access ends when trust ends. Review and remove dormant third-party accounts and grants as part of offboarding. Limit integration scopes to the minimum access needed and segment sensitive actions. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | The question is about access that persists after a third-party relationship should have ended. |
| NHI-02 — Secret Leakage | A valid token is identity-bearing material that can be abused if it remains usable. | |
| NHI-07 — Long-Lived Secrets | Residual token lifetime is the core reason trust loss does not immediately stop access. | |
| Recommendation — Build explicit offboarding and emergency revocation for third-party tokens and grants. Treat exposed or retained tokens as active secrets and revoke them immediately. Shorten token lifetime and eliminate unnecessary long-lived credentials. | ||
Practitioner Guidance
What to verify: Confirm that the deprovisioning path reaches every credential type the integration can use, including refresh tokens, long-lived access tokens, cached sessions, and any fallback API keys. If you cannot prove revocation, treat the relationship as still active.
Decision rule: If the integration can still authenticate after trust is withdrawn, prioritize token revocation and blast-radius reduction before debating whether the relationship was officially terminated correctly.
What good looks like: Third-party grants have an owner, an expiry date, a review cadence, and an emergency revocation path that security can execute without waiting on the vendor or application team.
Practitioner takeaway: Offboarding is incomplete until technical access dies with the relationship; if the token survives, so does the trust boundary violation.