The break is that delegated access keeps working even after the business relationship changes. A token can still reach SaaS data long after the original vendor context has disappeared, so inherited permissions become an attack path unless they are explicitly inventoried, rotated, or revoked.
What inheritance breaks in OAuth after an acquisition
Inherited OAuth access breaks the assumption that a valid token still implies a valid business relationship. After an acquisition, a token may continue to authorize SaaS access for users, apps, or integrations that were approved under the old company boundary, even though the original ownership, controls, and trust assumptions have changed.
That is why acquisition events are an access-governance problem as much as a legal or operational one. Delegated access can persist silently across tenant, vendor, and account boundaries, so the question is not whether the token still works, but whether it should still work under the new ownership model.
Tools such as RFC 6749: The OAuth 2.0 Authorization Framework define the underlying delegation model, but the control failure appears when that delegation is not revalidated after a change in control. In practice, a token that was once legitimate can become a standing access path if it is not tied to an updated inventory, audience, or revocation decision.
Why the post-acquisition trust boundary changes the meaning of a token
An oauth token is not just a technical artifact, it is a standing delegation to access a protected resource. When two organisations combine, the original scope, approver, and operational owner may no longer be the same, so the inherited token can outlive the relationship that justified it. That is especially true for SaaS-to-SaaS integrations, where the connection may be buried in an app registration or admin grant rather than a visible user account.
Once the trust boundary changes, old tokens may still reach data, APIs, and workflows that were never intended to survive the transaction. If the post-close review does not identify those grants, the token becomes a hidden continuation of the old organisation’s access model rather than a controlled part of the new one. SaaS-to-SaaS and OAuth App Governance Guide is useful here because it frames consent, scopes, and revocation as an ongoing governance task, not a one-time setup.
Where tokens are long-lived or refreshable, the risk is amplified because the access can survive the transaction long after account migration or vendor consolidation. That means acquisition due diligence has to include token discovery, ownership mapping, and a decision on whether the integration is being formally reissued or deliberately retired.
What must be inventoried, rotated, or revoked first
The first control is an inventory of every inherited OAuth grant, refresh token, connected app, and service-to-service integration that crosses the acquisition boundary. Without that list, teams cannot tell which access paths are business-critical, which are duplicate, and which are pure legacy exposure. OAuth 2.0 and OpenID Connect Guide for Identity Teams helps explain the token and grant types that need to be found before any cleanup can be trusted.
Rotation matters when the integration is still needed but the old credential chain is no longer trustworthy. Revocation matters when the integration is no longer approved, no longer monitored, or no longer needed after the acquisition. In many cases, the right answer is to replace inherited grants with fresh consent, tighter scopes, and a new owner rather than trying to preserve the old token set indefinitely.
A practical signal is whether the token can still access production SaaS data without a current owner who can explain why it exists. If nobody can justify the grant, it should be treated as residual access, not as a benign leftover from the deal process.
Risk and Threat Considerations
Inherited OAuth tokens create a delayed compromise path because they often remain valid after the business context that created them has disappeared. That turns acquisition clean-up into an exposure window for unauthorized access, data exfiltration, and attacker reuse if a legacy integration, vendor account, or refresh token is overlooked.
Failure mechanism: the token keeps working because the resource server still trusts the original delegation, even though the trust boundary, ownership, or approval chain has changed. An attacker who finds that token, or a careless admin who leaves it active, can use the inherited access as a low-friction entry point into SaaS systems and connected data.
Impact: the new organisation inherits invisible access paths, which can lead to data exposure, persistent footholds, and delayed detection after the acquisition closes. In the worst case, a token becomes a standing bridge from the legacy environment into current business systems.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and OWASP Non-Human Identity Top 10 address 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 | Inherited OAuth tokens are credentials that need lifecycle control after ownership changes. |
| AC-2 — Account Management | Post-acquisition OAuth grants require ownership review and removal of stale access paths. | |
| AC-6 — Least Privilege | Acquisition clean-up should reduce inherited OAuth scopes to only what is still required. | |
| Recommendation — Inventory, rotate, and revoke inherited tokens under credential lifecycle control. Review and remove inherited access that no longer has an approved business owner. Reduce inherited token scopes to the minimum access needed after the transaction. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Stale OAuth tokens can continue authenticating to SaaS APIs after the trust context changes. |
| Recommendation — Reassess token validity and revoke any authentication path that survived the acquisition. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | An acquisition is an offboarding moment for legacy vendor and tenant access paths. |
| NHI-07 — Long-Lived Secrets | Inherited OAuth tokens become dangerous when they persist beyond the original business relationship. | |
| Recommendation — Retire inherited identities and tokens that no longer belong in the new organisation. Replace long-lived inherited tokens with short-lived or reissued credentials. | ||
Practitioner Guidance
What to prioritise: start with SaaS applications, refresh tokens, and app-to-app grants that can still reach production data after close. Those are usually the highest-value inherited paths because they preserve access even when user accounts have changed.
What to verify: confirm who owns each grant now, what data it can reach, and whether the integration is still required under the new operating model. If the owner cannot name the business purpose and current approver, treat the access as suspect.
What good looks like: every inherited token is either reissued under the new control model, reduced to the minimum required scope, or revoked with a documented business justification for any exception. The acceptable state is a deliberate post-acquisition access map, not inherited continuity by default.
Practitioner takeaway: acquisition does not make old delegation safe, it makes stale delegation easier to miss, so token reassessment should be part of the control transfer, not a cleanup task left for later.
Related resources from NHI Mgmt Group
- What breaks when inherited systems keep their original access model after an acquisition?
- What breaks when inherited systems keep their old access model after an acquisition?
- What breaks when movers keep inherited access after a role change?
- Who is accountable when inherited NHI credentials remain active after a merger or acquisition?