They know it is under control only when duplicate accounts are removed, privileged access is vault-managed, stale credentials are rotated, and each identity has a clear owner. If those conditions are not measurable across both estates, the merger is still carrying hidden access risk, even if business systems are already connected.
Why This Matters for Security Teams
inherited access is only “under control” when the organisation can prove who owns each identity, what it can reach, and whether that access is still justified after the transaction. That matters because duplicate accounts, stale secrets, and unmanaged privileged paths tend to survive migrations long after business integration is declared complete. NHI Management Group’s Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into service accounts, which is why “we’ll clean it up later” often becomes permanent risk.
Security teams also need to separate inherited access from inherited trust. A connected merger estate can contain service accounts, API keys, and OAuth grants that were created for temporary integration work but never removed. The OWASP Non-Human Identity Top 10 treats over-privilege, secret exposure, and weak lifecycle control as core failure modes, not edge cases.
In practice, many security teams discover the real scope of inherited access only after a vendor integration, audit, or incident exposes how little of it was actually being governed.
How It Works in Practice
Control starts with inventory, but inventory alone is not control. Teams need to classify every inherited identity by owner, purpose, privilege level, last use, secret type, and dependency chain. That includes human-owned admin accounts, service accounts, machine-to-machine tokens, and third-party OAuth grants. The most reliable signal is not whether an account exists, but whether it has a documented business owner and a current technical owner who can answer for it.
From there, the operating model should move to measurable lifecycle controls:
- Remove duplicate or shadow accounts created during migration or integration.
- Vault-manage privileged access instead of leaving standing secrets in scripts, code, or shared documents.
- Rotate stale credentials on a defined schedule, with faster rotation for high-impact systems.
- Revoke inactive access after a short grace period, not at the next annual review.
- Track every identity to a named owner and a named system of record.
This is where evidence matters. The Ultimate Guide to NHIs — Key Challenges and Risks highlights how excessive privileges and weak rotation persist because teams cannot see the full population. Pair that with policy guidance from the OWASP NHI Top 10 and the operational discipline in Ultimate Guide to NHIs — Standards to define what “controlled” means for the merged estate. The practical test is simple: if an auditor asked for the owner, last rotation date, and current purpose of any inherited identity, the answer should be immediate and verifiable. These controls tend to break down when merged environments still share credentials across teams, because no single owner can revoke access without risking business disruption.
Common Variations and Edge Cases
Tighter inherited-access control often increases operational overhead, so organisations must balance speed of integration against the risk of carrying hidden privilege forward. That tradeoff is most visible in acquisitions, divestitures, and partner ecosystems where identity boundaries are still shifting.
Current guidance suggests treating the following as higher-risk exceptions rather than normal exceptions:
- Shared break-glass accounts that are not vault-managed and monitored.
- Legacy application accounts that cannot support rotation without code changes.
- Third-party OAuth grants that are owned by a business unit but administered by central IT.
- Service accounts embedded in CI/CD pipelines with no clean offboarding path.
There is no universal standard for every exception scenario yet, but best practice is evolving toward short-lived access, mandatory ownership, and periodic revalidation. The key question is not whether an exception exists, but whether it has an expiry date, an accountable owner, and a documented rollback path. For teams dealing with large NHI populations, the difference between “known” and “controlled” is usually whether stale access can be removed without manual heroics. Inherited access is still out of control when revocation depends on tribal knowledge instead of repeatable process.
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 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Inherited access must be inventoried and owned before it can be controlled. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Stale inherited credentials are a primary control failure in mergers. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege enforcement is central to removing excess inherited access. |
Rotate inherited secrets on a defined schedule and revoke any credential that cannot be proven current.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 23, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
