Ownership, scoping, and lifecycle controls break first. The merged organisation inherits identities from different technical worlds, so service accounts and secrets keep working even when nobody can say who owns them, how long they should live, or which policy actually governs them. That creates unmanaged access paths and audit gaps.
Why a merged estate fails without a baseline
A merger does not just combine directories, platforms, and cloud tenants. It also combines different assumptions about who can create, own, approve, rotate, and retire access. Without a baseline, non-human identities inherit conflicting rules, so the organisation cannot tell which accounts are legitimate, which are duplicated, or which ones still need to exist for production to keep running.
That is why the first failure is usually not an outage, it is ambiguity. The merged environment may appear functional while service accounts, API keys, certificates, and automation credentials continue to work under inherited permissions that no one has reconciled. From a security perspective, the baseline is what turns a collection of working identities into a governable population.
What breaks first: ownership, scope, and lifecycle
Ownership breaks first because non-human identities often come from separate technical teams with different naming, ticketing, and approval habits. When those systems meet, the merged organisation may have credentials that are technically valid but operationally orphaned. A useful reference point is NHI Ownership and Accountability Guide, which centres the problem on assigning accountable owners before identities become unmanageable.
Scope breaks next. One business unit may have treated a service account as app-specific, while another treated the same pattern as shared infrastructure access. Without a baseline, the merger cannot easily separate local exceptions from enterprise-standard access, so least privilege becomes guesswork. The same issue applies to lifecycle: expiry, rotation, offboarding, and recertification all depend on a rule set that the merged estate does not yet share.
That is why merged estates so often end up with identities that are still active but no longer well explained. The account may be required by one workload, unknown to the platform team, and unreviewed by security. When that happens, the control failure is not just weak documentation, it is a broken chain of accountability from creation through retirement.
Why unmanaged identities create lasting access gaps
Once ownership and lifecycle are unclear, the security problem becomes persistent access. A merged environment can inherit service accounts with broad permissions, long-lived secrets, and overlapping integrations that keep authenticating long after the original design context has disappeared. Service Account Security Guide is useful here because it treats discovery, governance, and rotation as a single control problem, not separate chores.
That persistence matters because non-human identities are often embedded in automation and system-to-system trust. If nobody can say which policy governs an identity, then nobody can reliably prove whether the access is still appropriate. In practice, the merged organisation gets three hidden risks at once: forgotten privilege, duplicated secrets, and weak auditability. A baseline prevents those from being mistaken for normal inherited behaviour.
The same logic is why maturity models and general inventories matter in merger work. A baseline gives the team a way to identify which identities are ordinary, which are exceptions, and which should be decommissioned or reissued. For a broader view of the governance sequence, NHI Governance Maturity Model and Joiner-Mover-Leaver (JML) Guide both support the idea that lifecycle control must survive organisational change.
Risk and Threat Considerations
Without a baseline, merged non-human identities create a large and durable attack surface. Orphaned credentials, overprivileged service accounts, and undocumented integrations are attractive because they often blend into normal traffic and are less likely to be reviewed during the merger period.
Failure mechanism: The environment inherits valid access paths before it inherits the ownership, policy, and rotation rules needed to manage them. Attackers and insiders can abuse long-lived secrets, shared accounts, or forgotten automation paths to maintain access after the original business rationale has disappeared.
Impact: The result is unmanaged privilege, weaker detection, and a larger blast radius if a secret is stolen or a service account is compromised. The organisation also loses confidence in audit evidence because it cannot easily prove who approved the access, who owns it now, or when it should be removed.
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 surface, CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Merged estates often retain orphaned non-human identities after ownership is lost. |
| NHI-05 — Overprivileged NHI | A missing baseline leaves inherited service accounts with unclear or excessive access. | |
| NHI-07 — Long-Lived Secrets | Merged environments commonly preserve secrets that keep working beyond their intended life. | |
| Recommendation — Inventory inherited non-human identities and offboard or revoke any account that lacks a current owner. Review inherited permissions and reduce every non-human identity to least privilege. Rotate or replace long-lived secrets and enforce expiry for inherited credentials. | ||
| CIS Controls v8 | CIS-5 — Account Management | The question is about inherited identities, ownership, and lifecycle control after merger. |
| Recommendation — Centralise account inventory, ownership, and deprovisioning for inherited identities. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Inherited service accounts and secrets need rotation, revocation, and lifecycle control. |
| AC-2 — Account Management | Mergers create orphaned accounts and unresolved ownership across environments. | |
| Recommendation — Enforce credential rotation, revocation, and secure storage for inherited authenticators. Assign account owners and review inherited access before treating accounts as trusted. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | A merged baseline must standardise who can access and govern inherited identities. |
| A.5.16 — Identity management | The issue is the merged organisation's ability to manage identity ownership and lifecycle. | |
| Recommendation — Define and apply a single access-control baseline for inherited non-human identities. Maintain a single identity-management process for inherited service accounts and secrets. | ||
Practitioner Guidance
What to prioritise: Start with a complete inventory of service accounts, keys, tokens, certificates, and other automation credentials, then assign an owner and business purpose before you attempt broad rationalisation. If an identity cannot be tied to a live service, a named owner, and a rotation or expiry rule, treat it as a candidate for containment rather than immediate trust.
What to verify: Check whether the merged baseline defines naming, ownership, approval, rotation, and offboarding in a way that applies across both legacy environments. The practical test is simple: can a reviewer tell who owns the identity, why it exists, and what would happen if it were removed tomorrow?
Practitioner takeaway: In a merger, the control problem is not that non-human identities exist, it is that inherited identities outlive the assumptions that made them safe. Baseline first, rationalise second, because you cannot govern what you cannot attribute.