TL;DR: M&A integration concentrates non-human identity risk because service accounts, tokens, and machine credentials outlive ownership boundaries and often remain overprivileged, according to Token Security; the article cites 46% of organisations experiencing NHI-related breaches and 91% of former employee tokens staying active. The governance problem is not just discovery, but proving who can revoke, rotate, and inherit each identity before the combined environment becomes one attack surface.
At a glance
What this is: This is an M&A-focused analysis of non-human identity risk, arguing that orphaned accounts, stale secrets, and excessive permissions become harder to govern when two identity ecosystems are merged.
Why it matters: It matters because merger integration is a lifecycle event, and NHI, autonomous, and human identity programmes all fail when ownership, revocation, and privilege boundaries are unclear across the combined estate.
By the numbers:
- 46% of organizations have experienced breaches related to non-human identities.
- NHIs outnumber human identities by 25x to 50x in modern enterprises.
👉 Read Token Security's analysis of non-human identity risk in M&A due diligence
Context
M&A identity due diligence starts with a simple question: which non-human identities will survive the transaction, and which ones should not? In merged environments, service accounts, API keys, automation scripts, and machine-to-machine integrations often keep working long after the business case for them has changed, which turns integration into an identity governance problem as much as a technology one.
The article is useful because it shifts the discussion away from pure integration mechanics and toward ownership, revocation, and privilege inheritance. That is the right frame for NHI programmes, because post-merger environments routinely expose shadow accounts, stale secrets, and hidden entitlements that traditional IAM reviews miss.
Key questions
Q: How should security teams handle non-human identities during M&A integration?
A: They should treat every NHI as a lifecycle object that needs ownership, scope validation, and revocation authority before systems are merged. The safest path is to inventory credentials, identify the business process behind each one, and remove or rotate anything that cannot be traced to an active use case.
Q: Why do orphaned service accounts create so much risk after an acquisition?
A: Orphaned service accounts are dangerous because they often keep working after the original owner has left or the original environment has changed. In a merger, that persistence turns old access into live access, especially when the account still reaches production systems, cloud resources, or connected SaaS platforms.
Q: What do teams get wrong about least privilege in merged environments?
A: They often review permissions identity by identity and miss the combined access graph. In merged estates, the real risk is transitive reach, where two separately acceptable identities create a toxic combination that unlocks data, admin paths, or build systems neither side intended to expose.
Q: Who is accountable for revoking machine credentials after an acquisition closes?
A: Accountability should sit with the integration team and the system owners who inherit the environment, not with a vague central review process. If no one is explicitly named to revoke, rotate, or transfer the credential, the identity will usually survive by default and become part of the attack surface.
Technical breakdown
Why M&A creates NHI sprawl faster than teams can map it
In an acquisition, two identity estates collide before either side has a complete inventory of machine identities, secrets, or ownership metadata. The technical problem is not just volume. NHIs are embedded in code, CI/CD, SaaS integrations, cloud roles, and automation paths, so a merger can surface identities that were never intended to be portable. Once systems are connected, dormant credentials can become live trust paths. Without attribution, teams cannot tell whether an identity is still required, who can revoke it, or whether it belongs to a business process that will be retired.
Practical implication: build a pre-integration NHI inventory that separates active production identities from legacy and orphaned credentials.
How orphaned tokens and secret drift become post-merger access paths
Orphaned accounts persist when the human or system owner disappears but the credential remains valid. Secret drift happens when credentials are copied into multiple systems, stored outside vaults, or left unchanged across environment changes. In M&A, those two conditions reinforce each other: the merged estate creates more places for tokens to live and more ambiguity about who should rotate or revoke them. That is why lifecycle controls matter more than point-in-time access checks. A credential that is still accepted by a downstream platform is still an access path, even if no one can trace its current business owner.
Practical implication: tie every token and service account to an accountable owner before integration, then revoke or rotate anything that cannot be attributed.
Why excessive permissions become toxic combinations after consolidation
Permission mapping is hard in a single enterprise and becomes far harder when two cloud and SaaS estates are combined. The risk is not only overprivileged NHIs in isolation, but also toxic combinations that emerge when access from one side of the merger intersects with hidden trust on the other. Least privilege is therefore a graph problem, not a simple role review. If teams cannot see transitive access across environments, they cannot evaluate whether a workload can reach data, admin functions, or build systems that were never intended to be linked.
Practical implication: run transitive privilege analysis across both estates before cutover, not after the systems are already interconnected.
Threat narrative
Attacker objective: The attacker aims to exploit merger-driven identity confusion to gain durable access to data, infrastructure, or privileged workflows.
- Entry occurs when an attacker finds a stale machine credential, orphaned token, or untracked service account that still works across the merged environment.
- Escalation follows when that identity already carries broad permissions or can reach connected systems that were never re-reviewed during integration.
- Impact comes from data access, lateral movement, or administrative control that persists because ownership and revocation were never fully reconciled.
Breaches seen in the wild
- Google Firebase misconfiguration breach — Firebase misconfigurations exposed 19.8M secrets across developer instances.
- Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
M&A is an identity lifecycle event, not just an integration project. The security failure in mergers is usually not discovery alone, but the assumption that access can be inherited and cleaned up later. That assumption breaks because NHIs outlive ownership changes, and the combined estate immediately multiplies revocation complexity. Practitioners should treat merger planning as lifecycle governance from day one.
Orphaned machine credentials are the most durable hidden risk in post-merger estates. A token that remains active after a human owner leaves is the simplest form of governance failure, and mergers make that failure harder to see. The article correctly points to former employee tokens and stale accounts because they show how accountability can disappear while access remains. The implication is that ownership drift, not just credential exposure, becomes the control gap to watch.
Ephemeral integration does not mean ephemeral trust. M&A teams often connect environments quickly and assume access can be reviewed after the fact, but machine identities do not wait for that process. Once a service account or API key is trusted by a downstream platform, it can carry privilege across the combined estate regardless of whether the business relationship has changed. That is why the post-merger identity blast radius must be measured before connectivity is widened.
Least privilege becomes a graph problem when two identity estates merge. Excess privilege is no longer just a role-design issue once transitive access, shadow workloads, and inherited trust paths intersect. The practical problem is not whether a single identity is privileged, but whether its reach creates a toxic combination with the other estate. Security teams should re-evaluate access topology, not just entitlement lists.
Machine-first identity governance is now part of M&A due diligence. Traditional human IAM controls do not cover the operational reality of NHIs that live in code, pipelines, and integrations. That makes attribution, behavior analysis, and lifecycle control the right governance lens for merger work. Teams that cannot map machine identity ownership before integration are accepting avoidable breach exposure.
From our research:
- 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches, according to The 2025 State of NHIs and Secrets in Cybersecurity.
- Only 5.7% of organisations have full visibility into their service accounts, which explains why merger integration so often starts with incomplete ownership data.
- Pair that with Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs for a lifecycle model that covers provisioning, rotation, and offboarding.
What this signals
Identity blast radius: M&A programmes should now measure how far a machine credential can move before integration completes, because the merger often widens trust faster than governance can catch up. If your teams cannot see where a token is used, inherited access will outpace remediation and the combined environment will normalise hidden privilege.
The practical signal is that access review cadence alone is too slow for merger work. Security teams need pre-close mapping, post-close revocation queues, and a clear record of which identities are still tied to active business processes versus historical dependency chains.
If your programme already struggles with service account visibility, the merger will expose it quickly. The right response is to treat NHI discovery, ownership attribution, and entitlement cleanup as a dedicated workstream rather than a side task in integration.
For practitioners
- Inventory every NHI before systems are connected Map service accounts, API keys, tokens, certificates, automation scripts, and CI/CD identities in both organisations before any broad trust is established. Prioritise identities with production access, third-party dependencies, and no clear owner.
- Reconcile ownership and revocation authority early Require a named business or technical owner for each machine identity and define who can rotate, revoke, or transfer it after the transaction closes. If no accountable owner exists, treat the credential as disposable.
- Run transitive access analysis across the combined estate Look for hidden reach between SaaS, cloud, build systems, and data platforms that only becomes visible when two identity graphs are merged. Focus on toxic combinations, not just single high-privilege accounts.
- Retire or rotate credentials that cannot be attributed Do not allow legacy tokens, orphaned secrets, or unexplained service accounts to survive cutover. If the credential cannot be traced to an active business process, rotate it or remove it before integration proceeds.
Key takeaways
- M&A creates a governance problem because machine identities keep working after ownership and business purpose have changed.
- The evidence is clear enough to plan around: orphaned tokens, hidden permissions, and incomplete visibility are the conditions that let merger-driven identity risk persist.
- The control that matters most is lifecycle authority, because attribution, revocation, and transitive access review must happen before the combined estate becomes one attack surface.
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 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Covers discovery and inventory gaps for NHIs in merged estates. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access review is central to post-merger entitlement cleanup. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero trust segmentation limits blast radius when merged identities inherit unexpected reach. |
Inventory all NHIs before integration and remove any identity with no clear owner or purpose.
Key terms
- Non-Human Identity: A non-human identity is any machine or workload credential used by software, infrastructure, or automation rather than a person. It includes service accounts, API keys, tokens, certificates, and AI-driven executors that can authenticate and access resources on their own.
- Identity Blast Radius: Identity blast radius is the amount of damage an identity can cause if it is misused, stolen, or left active too long. In practice, it is shaped by privilege scope, trust relationships, and how many systems a single credential can reach before anyone notices.
- Orphaned Credential: An orphaned credential is a token, key, or account that still works but no longer has a clearly accountable owner. These credentials are high risk because they often survive organisational change, integrations, and offboarding events, leaving active access with no clear governance path.
What's in the full article
Token Security's full blog covers the operational detail this post intentionally leaves for the source:
- The article's five risk categories for NHI due diligence across merger and acquisition workflows
- Practical questions integration teams should ask about ownership, privileged access, and shadow identities
- The vendor's machine-first identity security framing for attribution, behaviour analysis, and autonomous risk scoring
- Case-study context on Google's acquisition of Wiz and the NHI sprawl that can sit inside mature engineering organisations
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on 2026-05-29.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org