Why do layoffs and M&A increase orphaned NHI risk?

Why layoffs and M&A create orphaned NHI conditions

Layoffs and mergers or acquisitions break the human context around machine identities. The people who knew why a service account, API key, token, or certificate existed may leave, and ownership records often lag behind the organisational chart. That leaves active secrets and permissions in place with no clear business owner to review, rotate, or retire them.

In practice, the risk is not only that an identity is forgotten. It is that the inherited access still works, so the environment keeps trusting something nobody can confidently explain. That is why orphaned nhi are often found during post-deal clean-up, when teams discover integrations, automation, and shared credentials that were never fully documented.

After restructuring, the default failure mode is continuity without accountability. A machine identity can keep authenticating even when the original application owner, platform team, or vendor relationship changes, so the technical control plane and the business ownership plane drift apart.

What actually changes after a workforce reduction or acquisition

Layoffs remove subject-matter knowledge from the organisation, and M&A frequently splits it across two inventories, two directory structures, and two operating models. The most important detail is not the headcount event itself, but the metadata loss: who requested the identity, what system depends on it, what rotation cadence it follows, and who is allowed to approve changes. NHIMG’s NHI Ownership and Accountability Guide is useful here because ownership is the control that keeps machine identities from becoming permanently ambiguous.

That ambiguity is amplified when identities were already weakly governed. Shared service accounts, hardcoded credentials, and legacy integrations are hard to reconstruct after organisational change, especially if the original approver or engineer has exited. The more implicit the dependency, the easier it is for the secret to survive the reorganisation untouched.

Post-transaction environment separation also matters. A credential may still work across business units, clouds, or tenants even after the teams that understood its purpose have been reassigned. Service Account Security Guide and Human vs Non-Human Identity both help frame this as an ownership and lifecycle problem, not just a credential inventory problem.

Why the hidden-access problem gets worse, not better

Orphaned NHIs are dangerous because they preserve access while removing accountability. If a secret remains active, it can continue to authenticate, authorize actions, or reach downstream systems even when nobody is actively watching it. That creates hidden access, and hidden access is exactly what slows incident response and decommissioning.

When an organisation cannot prove why an identity exists, it also cannot confidently decide whether to rotate, scope down, or remove it. That uncertainty leads to delay, and delay increases exposure. NHIMG’s Top 10 NHI Issues and Ultimate Guide to NHIs, Key Challenges and Risks both cover the same practical pattern: ownership gaps, stale credentials, and excessive permissions tend to cluster together after governance disruption.

The clean-up problem is especially severe when the credential has broad reach or is embedded in automation. A secret that is technically valid but operationally mysterious often survives because nobody wants to break a production dependency they cannot yet map. That is why mergers, divestitures, and layoffs usually expose more orphaned NHIs than steady-state operations do.

Risk and Threat Considerations

Orphaned NHIs create a prolonged trust gap. The organisation may believe an account is inactive or harmless, while the secret remains usable for authentication, lateral movement, or unauthorized automation. The longer this state persists, the more likely it is that an attacker, former employee, or overlooked integration will reuse it.

Failure mechanism: The reorganisation removes the person or team that understood the identity, but the credential, token, or certificate is still valid and still has the same permissions. Inventory records, ticket history, and ownership references become incomplete or stale, so cleanup stalls.

Impact: Hidden access survives longer than intended, rotation becomes harder to prioritise, and the blast radius of compromise increases because nobody can reliably prove whether the identity is still needed or already abused.

Practitioner Guidance

What to prioritise: Treat post-layoff and post-deal NHI review as a high-risk access reconciliation exercise, not a documentation tidy-up. Start with credentials that can reach production, automation paths, and identities with no named business owner.

What to verify: For each candidate orphan, confirm three things before you trust it: current system dependency, accountable owner, and expiry or rotation path. If any one of those is missing, the identity should be treated as unresolved rather than assumed safe.

What good looks like: Every active machine identity has a current owner, a documented purpose, and a removal or renewal decision attached to it. In a transaction or downsizing event, that evidence should survive staff changes and org-chart changes without relying on tribal knowledge.

Practitioner takeaway: The core control is continuity of ownership, because the technical risk comes from secrets that outlive the people who can justify them.

Related resources from NHI Mgmt Group

• Why do Salesforce integrations increase NHI risk?
• Why do leaked secrets remain such a persistent NHI risk?
• What makes idle secrets such a serious NHI risk?
• What is the main NHI risk in ServiceNow integrations?