They extend the old trust boundary into the new organisation. If a credential still works after ownership changes, the acquirer inherits access it may not understand, monitor, or need. That creates a long-lived path for misuse, especially where privileged access and legacy integrations were never reconciled.
Why stale tokens and service accounts become more dangerous after a merger
Merger activity widens the trust graph before it is fully understood. Tokens and service accounts that were acceptable in the old company can suddenly keep working across newly connected systems, even when nobody has reviewed their ownership, scope, or expiry. That gap is what turns ordinary technical debt into inherited access risk.
Staleness matters because these credentials often bypass human review paths. If an account is still valid, it can keep reaching production, internal APIs, or admin tools long after the business rationale has changed. In a merger, that creates a hidden bridge between environments that were never designed to trust each other.
After integration, the highest risk is not simply that a credential exists, but that it continues to function with assumptions from the pre-merger world. A service account tied to a legacy application may still hold privileged access, hard-coded trust, or broad network reach, while the new owner lacks the context to judge whether it should still be active.
How stale credentials extend the old trust boundary
Stale tokens and service accounts extend the original identity boundary into the merged organisation because they preserve access without preserving understanding. The acquirer inherits whatever the credential can reach, but may not inherit the history that explains why it exists, who owns it, or whether it is still needed. NHIMG’s Ultimate Guide section on Non-Human Identities is a useful reference point for how service accounts, tokens, and workload identities fit into the broader identity picture.
That matters most where legacy integrations were built for convenience. Tokens often outlive the systems that created them, and service accounts often accumulate permissions because they were never challenged by lifecycle controls. In a merger, those old shortcuts become cross-company access paths unless they are discovered, mapped, and intentionally re-approved.
Visibility is the key failure point. A merged environment can contain duplicated accounts, overlapping privilege models, and credentials stored in multiple places, which makes it easy to miss the ones that still authenticate successfully. NHIMG’s Service Account Security Guide and Guide to the Secret Sprawl Challenge both reinforce why inventory and secret hygiene become decisive during integration.
What practitioners should expect in the first integration window
The first integration window usually exposes three problems at once: unknown ownership, excessive privilege, and long-lived credentials that still work. A token or service account that was harmless inside a smaller estate can become materially risky once it connects to a larger set of data, admin consoles, or partner links. NHIMG’s NHI Ownership and Accountability Guide is directly relevant here because ownership is what turns an orphaned credential into a governable one.
Staleness also makes incident response harder. If a credential is discovered after the merger, teams may not know whether it belongs to a critical workflow, a dormant integration, or a forgotten test path. That uncertainty delays rotation decisions and can cause either overreaction, by breaking business services, or underreaction, by leaving a valid access path in place.
For technical teams, the practical challenge is that stale non-human credentials are often “quietly live.” They do not trigger obvious login behaviour, they may not be associated with a named person, and they can sit outside normal joiner-mover-leaver processes. NHIMG’s Guide to NHI Rotation Challenges and Cloud Workload Identity Guide are useful for understanding why static or long-lived credentials are especially problematic during change.
Why stale access creates merger-era security exposure
In a merger, stale credentials are attractive to attackers because they often survive the changes that invalidate other trust assumptions. If a service account or token was never decommissioned, it can provide a low-friction path back into systems that defenders assume are already under new governance. The risk is amplified when those credentials have access to internal APIs, administrative functions, or sensitive data stores.
Legacy access also increases blast radius. One forgotten credential can expose multiple applications if it was reused, embedded in automation, or granted broad rights to avoid operational friction. NHIMG’s Cloudflare Thanksgiving breach 2023 shows how unrotated service credentials can remain exploitable after a major security event, and Okta support system breach 2023 illustrates how a service account can become the path to session compromise when trust assumptions are weak.
During post-merger consolidation, the main concern is not just compromise of one account, but persistence through forgotten paths. If a credential is still accepted by a production system, it can be used until it is revoked, rotated, or constrained. That is why merger cleanup should treat stale non-human access as an active exposure, not a housekeeping task.
Risk and Threat Considerations
Stale tokens and service accounts create a durable attack path because they often survive organisational change, credential inventory drift, and policy harmonisation delays. If the acquirer does not quickly reconcile ownership and scope, an attacker or insider can use inherited access to move laterally, reach privileged systems, or access data that should no longer be reachable.
Failure mechanism: A credential remains valid after the merger, but its owner, purpose, and permitted boundary are no longer clear, so the merged estate keeps trusting an access path that no one is actively governing.
Impact: The organisation can inherit hidden privilege, create unintended cross-environment access, and leave a long-lived foothold that persists until discovery and rotation catch up.
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 |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Stale merger credentials are orphaned identities that were never fully retired. |
| NHI-05 — Overprivileged NHI | Legacy service accounts often retain more access than the merged estate now needs. | |
| NHI-07 — Long-Lived Secrets | Stale tokens and service accounts remain dangerous because their secrets outlive the original ownership model. | |
| Recommendation — Revoke or re-home inherited non-human identities before the new trust boundary is accepted. Review inherited service-account permissions and remove unnecessary privilege immediately. Shorten credential lifetime and replace standing secrets with rotated, time-bounded access. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Merger cleanup requires controlling creation, storage, rotation, and revocation of authenticators. |
| AC-2 — Account Management | Inherited service accounts must be tracked, owned, reviewed, and removed when no longer needed. | |
| Recommendation — Inventory authenticators and enforce rotation or revocation for any credential that is no longer justified. Reconcile account ownership and disable accounts that lack a current business owner or purpose. | ||
Practitioner Guidance
What to prioritise: Start with credentials that can reach production, administrative tooling, shared platforms, or regulated data. Those are the ones most likely to turn a post-merger oversight into a material breach path.
What to verify: For each stale token or service account, confirm owner, business purpose, last use, privilege scope, and whether the credential is still required after integration. If any of those cannot be established, treat the access path as high risk until proven otherwise.
Decision rule: If a legacy credential still authenticates to a live system, rotate or revoke it before you assume the merged architecture has been fully reconciled. Waiting for evidence of abuse is the wrong threshold when the access path itself is already uncertain.
Practitioner takeaway: Merger risk is driven less by the existence of old credentials than by how long they keep working after ownership, monitoring, and intent have changed.
Related resources from NHI Mgmt Group
- When do service accounts become a higher risk than ordinary user accounts?
- How should teams reduce the risk of orphaned service accounts and stale tokens?
- Why do tokens and service accounts in GitHub increase identity risk?
- Why do orphaned service accounts and tokens create so much risk after offboarding?