TL;DR: Layoffs, reorganisations, and mergers leave API keys, service accounts, and automation tokens behind, creating orphaned NHIs that persist with old privileges and little ownership context, according to Entro Security. The governance problem is not headcount change itself but unmanaged machine access that outlives the people who created it.
At a glance
What this is: This post argues that workforce changes expose a standing NHI governance gap, because secrets and service accounts often remain active after their owners depart.
Why it matters: It matters to IAM and NHI practitioners because offboarding, ownership, and access review processes must extend beyond humans to prevent orphaned machine access.
By the numbers:
- 1 out of every 1,000 NHIs in enterprise environments is more than 10 years old.
- 1 out of every 1,000 NHIs in enterprise environments is more than 10 years old, while the median employee tenure is just 3.9 years.
👉 Read Entro Security's post on layoffs, orphaned NHIs, and leftover secrets
Context
Orphaned NHI exposure appears when a machine identity keeps working after the human who created it leaves or changes role. In practice, that means API keys, service accounts, automation tokens, and hardcoded secrets can survive layoffs, restructuring, and mergers long after ownership has disappeared. For IAM teams, the gap is not discovery alone but lifecycle control, because unmanaged secrets often remain valid inside production workflows.
The article ties that problem to organisational change, especially layoffs and M&A, where inherited scripts and identities arrive without clear purpose or ownership. That is a familiar failure mode in NHI governance: the environment changes faster than the offboarding process, and security teams inherit unknown access paths rather than a clean inventory. The starting position described here is typical, not exceptional.
Key questions
Q: How should security teams handle NHIs when employees leave or change roles?
A: Security teams should treat NHI offboarding as part of the employee departure process. That means identifying every secret, service account, and automation token tied to the departing role, confirming the business owner, and revoking or rotating access before the identity is left behind in production.
Q: What is the difference between a human offboarding problem and an NHI offboarding problem?
A: Human offboarding removes a person’s login and device access. NHI offboarding must also remove machine credentials that may be embedded in code, pipelines, cloud services, and integrations. The second problem is broader because the identity can keep working even when no person is actively using it.
Q: When does orphaned NHI access become a material security risk?
A: Orphaned NHI access becomes material when the identity still has valid permissions, can reach production systems, or is tied to sensitive workflows. The risk rises further when no owner can confirm its purpose, because the organisation cannot quickly decide whether to keep, rotate, or remove it.
Q: Why do mergers and acquisitions make NHI governance harder?
A: M&A increases NHI risk because the acquiring organisation inherits identities created under different controls, naming conventions, and ownership models. Security teams often receive access before they receive context, which makes it harder to separate active business automation from stale credentials that should be retired.
Technical breakdown
Why orphaned NHI access persists after offboarding
An orphaned NHI is a non-human identity that still authenticates even though its creator, operator, or business owner is gone. The technical problem is that authentication and ownership are often decoupled. A service account may still have valid credentials, a CI/CD token may still be stored in a pipeline, and a chatbot API key may still be embedded in code or configuration. Unless lifecycle controls tie each secret to an accountable owner and a revocation condition, the identity remains usable long after the original work has ended.
Practical implication: Map every secret and service account to an owner, a business purpose, and a revocation trigger.
Why mergers and acquisitions amplify NHI sprawl
M&A creates identity inheritance at scale. The acquiring organisation does not just receive users and devices, but scripts, automation accounts, legacy integrations, and undocumented secrets created under a different control model. Those identities often lack lineage, which means teams cannot quickly answer who created them, what they access, or whether they are still needed. That makes discovery, attribution, and cleanup the core technical tasks, not a secondary audit exercise. The risk grows because inherited identities are usually the least understood and most over-privileged parts of the environment.
Practical implication: Treat every acquired environment as an NHI inventory problem before it becomes an access review problem.
How NHI ownership and secret rotation reduce blast radius
Rotation limits how long a credential stays useful if it is exposed, while ownership gives security teams a person or process to contact when a secret needs review. The point is not simply to replace one token with another. It is to shorten exposure windows, verify whether an identity is still active, and remove access that no longer serves a business function. Without that combination, teams can have frequent rotation and still retain ungoverned machine access. The control model must connect secret hygiene to lifecycle governance.
Practical implication: Use rotation, inventory, and ownership together so unused NHI access can be removed quickly.
Threat narrative
Attacker objective: The attacker wants durable, low-noise access through machine identities that no one is actively watching.
- Entry occurs when attackers discover old or orphaned API keys, service account tokens, or hardcoded secrets that were left behind after layoffs or M&A.
- Escalation happens when those credentials still map to active production permissions, allowing the attacker to move from one identity to broader system access.
- Impact follows when the attacker uses persistent NHI access to reach data, automation pipelines, or AI workloads without triggering human offboarding controls.
Breaches seen in the wild
- IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.
- 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
Orphaned NHI risk is a lifecycle failure, not a staffing issue. Layoffs, restructures, and acquisitions change who owns the work, but they do not automatically change who can still access systems. That gap exposes the limits of human-centric offboarding. Practitioners should treat every departure as a credential and ownership review event, not just a HR process.
Identity lineage is the control most organisations still lack. The hard part is not finding a token, but knowing which system created it, which workflow depends on it, and who can safely remove it. Without lineage, teams either leave risk in place or break production. The practical conclusion is that lineage must become a first-class requirement for NHI governance.
Acquisition due diligence should include machine identity due diligence. A newly inherited environment can contain thousands of undocumented scripts and service accounts, many of which were created under different standards. Security teams need a repeatable intake process for secrets, permissions, and ownership before access is merged into the core enterprise. Practitioners should budget for cleanup before integration.
Ephemeral human employment does not mean ephemeral machine access. Human tenure is measured in years, but machine identities can persist for a decade or more. That mismatch creates trust debt, where old credentials remain valid because no one is accountable for retiring them. Teams should shift from periodic cleanup to continuous NHI lifecycle management, because the backlog is structural, not occasional.
From our research:
- 1 out of every 1,000 NHIs in enterprise environments is more than 10 years old, according to The State of Non-Human Identity Security.
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, according to The State of Non-Human Identity Security.
- For a broader control baseline, compare this issue with Top 10 NHI Issues to prioritise ownership, rotation, and visibility gaps.
What this signals
Identity lineage is becoming the practical divider between manageable and unmanageable NHI sprawl. When organisations cannot trace a token back to its creator, business purpose, and retirement path, they inherit access they cannot safely explain. That is why identity intake, offboarding, and review workflows need to move together, not as separate governance projects.
The scale of the confidence problem is still acute. Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, which means most programmes are still operating with partial visibility and uneven ownership. For practitioners, the signal is to prioritise inventory quality before policy expansion, because controls cannot govern what they cannot see.
For practitioners
- Implement owner-linked offboarding for every NHI Require each API key, service account, and automation token to have a named operational owner, a business purpose, and a retirement condition. When a person leaves or a team changes, the associated machine identities should enter the same offboarding workflow as their human counterpart.
- Inventory inherited identities during M&A intake Create a mandatory identity inventory step before integrating an acquired environment. Include secrets, scripts, pipeline accounts, and embedded credentials, then classify them by business criticality, active use, and revocation risk.
- Shorten credential exposure with enforced rotation Set rotation rules for all secrets that authenticate non-human access, especially those embedded in CI/CD and automation. Rotation should be tied to access review so stale credentials are not replaced without ownership validation.
- Track lineage before granting production trust Link each NHI to its originating application, repository, and deployment path so security teams can determine whether the identity still has a legitimate purpose. Lineage data makes it possible to remove access without guessing.
Key takeaways
- Workforce change becomes an NHI security event when secrets outlive the people who created them.
- M&A magnifies the problem because inherited identities often arrive without context, ownership, or retirement data.
- Practitioners should align offboarding, lineage, and rotation so machine access does not become permanent by default.
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-03 | Credential rotation and retirement are central to orphaned NHI cleanup. |
| NIST CSF 2.0 | PR.AC-1 | Orphaned machine identities are a weak access-control outcome. |
| NIST Zero Trust (SP 800-207) | Zero trust requires continuous verification of machine access, not just human sessions. |
Tie every NHI secret to rotation and retirement triggers, then verify they still match business need.
Key terms
- Orphaned NHI: An orphaned NHI is a non-human identity that still exists after the person, team, or system that created it is gone. The account or secret may continue to authenticate and access resources even though no clear owner remains responsible for its use or retirement.
- Identity Lineage: Identity lineage is the traceable relationship between a non-human identity and the application, repository, pipeline, or process that created it. It helps security teams understand purpose, ownership, and dependencies so they can revoke or rotate access without breaking legitimate automation.
- NHI Offboarding: NHI offboarding is the controlled removal or reassessment of machine credentials when business ownership changes, work ends, or a system is retired. It extends human offboarding concepts to secrets, tokens, certificates, and service accounts that can otherwise remain active indefinitely.
- Credential Rotation: Credential rotation is the replacement of a secret with a new value so any exposed or stale credential loses usefulness. In NHI governance, rotation is only effective when paired with ownership, inventory, and review, otherwise old access patterns simply persist under a different token.
What's in the full article
Entro Security's full blog post covers the operational detail this post intentionally leaves for the source:
- How the vendor maps orphaned NHIs to owners across cloud, code, collaboration tools, and CI/CD stacks
- What the vendor says about flagging unused secrets within minutes during mass layoffs scenarios
- The contextual inventory approach used for M&A transitions, including lineage and purpose mapping
- Operational examples of identifying idle, over-privileged, or risky NHIs before revocation
Deepen your knowledge
NHI lineage, ownership, and lifecycle controls are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is dealing with layoffs, restructures, or inherited environments, it is worth exploring.
Published by the NHIMG editorial team on 2025-07-15.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org