Should organisations treat acquisition-driven token sprawl as a governance issue?

Why acquisition-driven token sprawl becomes a governance problem

When a company acquires another business, it often inherits OAuth grants, API tokens, service accounts, app passwords, and other delegated access paths that were created under a different operating model. The governance problem is not the token itself, but the lack of clear ownership, expiry, inventory, and offboarding across the combined estate.

That is why token sprawl should be treated as an identity governance issue, not just a cleanup exercise. If the organisation cannot say who approved each connection, what it can reach, and when it should be removed, the acquisition has expanded access faster than the control model can absorb it.

This is also where the Ultimate Guide to NHIs is useful, because acquired tokens usually sit inside broader non-human identity and lifecycle problems, including ownership, visibility, rotation, and offboarding.

What makes token sprawl hard to control after an acquisition

Acquisitions usually introduce multiple identity stacks, legacy SaaS integrations, and locally managed automations that were never designed for merger-scale oversight. Tokens may be embedded in scripts, stored in app configuration, shared across teams, or left active long after the original business purpose ended.

The control gap is often caused by incomplete dependency mapping. If the receiving organisation only inventories formal employees and major applications, it will miss the long tail of connected tools, bot accounts, and machine-issued credentials that keep processes running quietly in the background.

Acquired environments also tend to blur accountability. In practice, that means no one can answer basic questions quickly: which token belongs to which business process, which app owner can revoke it, and whether the token still has production access. Those unanswered questions turn simple technical debt into governance debt.

Secrets Management Guide and Guide to the Secret Sprawl Challenge both support this point: token sprawl is usually part of a wider secrets-management problem, where centralised visibility and rotation matter more than one-off discovery.

What a governance model should do instead

A workable model treats acquisition onboarding as a continuous control process. The first step is inventory, but the real objective is ownership assignment, access classification, and retirement discipline for every inherited connection that can authenticate or delegate access.

Practically, that means connecting M&A due diligence to post-close control operations. Tokens should be grouped by business function, risk level, and destination system, then reviewed for least privilege, expiry, and replacement path. If a token cannot be attributed to an owner or use case, it should be quarantined or rotated quickly, not left in place because it is “probably needed”.

Top 10 NHI Issues and Guide to NHI Rotation Challenges are especially relevant here because acquired token estates fail when inventory, ownership, rotation, and offboarding are handled as separate projects instead of one governance loop.

OWASP Non-Human Identity Top 10 reinforces the same operating model: lifecycle control, secret handling, privilege reduction, and third-party exposure all need to be governed together once inherited access is in production.

Practitioner Guidance

What to prioritise: Start with connected applications and tokens that can reach production systems, customer data, or privileged internal APIs. Those are the credentials that can create the largest blast radius if they are stale, overbroad, or undocumented.

What to verify: For each inherited token, verify owner, purpose, last use, privilege scope, expiry, and revocation path. If any of those are unknown, treat the token as a governance exception rather than a routine asset.

Decision rule: If the organisation cannot reissue or rotate the token without breaking a critical business process, it has discovered an unmanaged dependency and should remediate that dependency before expanding the acquisition further.

Practitioner takeaway: Acquisition token sprawl becomes governable only when the organisation manages it as lifecycle-controlled access, not as a one-time integration checklist.

Related resources from NHI Mgmt Group

• Should organisations treat ransomware, supplier compromise, and token abuse as one governance issue?
• What makes agentic AI an NHI governance issue?
• When should organisations treat an NHI as a high-priority risk?
• Should organisations prioritise external exposure or internal credential governance first?