They should treat both as part of the same identity estate. Human onboarding, service account inheritance, API keys, and integration credentials can all introduce hidden access paths if they are not reviewed together. A merger is the wrong time to separate IAM from machine identity governance.
Why This Matters for Security Teams
Mergers create one of the fastest ways to inherit unreviewed privilege. Human accounts, shared mailboxes, service principals, API keys, certificates, and vendor integrations often live in separate systems with different owners and no common review process. If the organisation treats employee access and machine access as separate workstreams, gaps appear between IAM, PAM, and application ownership during the transition.
That matters because post-merger access sprawl is rarely visible in the first inventory. The business is focused on continuity, so teams may preserve access first and rationalise later. Current guidance from the NIST Cybersecurity Framework 2.0 supports a risk-based approach that identifies, protects, detects, and responds across the full identity estate, not just employee logins. In practice, many security teams encounter excessive access only after integration work has already widened the attack surface.
How It Works in Practice
Effective merger governance starts with a unified identity inventory. Security teams should map who and what can authenticate, which systems those identities can reach, and which access paths are inherited through business unit consolidation, shared tooling, or technical debt. That inventory should include human identities, non-human identities, privileged accounts, and secrets such as API keys and certificates. It should also identify orphaned accounts, dormant integrations, and duplicate trust relationships that were acceptable in the source organisations but become risky when environments are joined.
Operationally, the review should separate access into three questions: is the identity still needed, who owns it, and how is it controlled. For humans, that means role validation, Segregation of Duties checks, and privileged access recertification. For non-human access, it means validating service account purpose, credential rotation, token lifetime, secret storage, and whether the integration can be replaced with federated trust or short-lived credentials. The OWASP Non-Human Identity Top 10 is useful here because merger activity often exposes the very failures it highlights: hardcoded secrets, weak rotation, over-privileged service identities, and missing ownership.
- Build one consolidated access register for humans and machines.
- Classify accounts by business criticality, privilege level, and dependency chain.
- Revalidate every privileged and embedded credential before cutover.
- Use temporary controls such as just-in-time elevation where immediate removal is not feasible.
- Log all access changes in a way that supports incident response and audit review.
Where possible, map controls to NIST SP 800-53 Rev 5 Security and Privacy Controls so the merger team can translate business decisions into enforceable access policy. These controls tend to break down when integration teams preserve legacy connectivity for too long because temporary exceptions become permanent trust relationships.
Common Variations and Edge Cases
Tighter merger controls often increase operational friction, requiring organisations to balance continuity against the risk of hidden access paths. The tradeoff is sharpest when two companies rely on different identity stacks, different cloud tenants, or different standards for service-account ownership. In those cases, best practice is evolving rather than settled, and there is no universal standard for how quickly every non-human credential must be reissued.
Some environments can federate quickly, while others need staged migration because embedded credentials are tied to production systems, external partners, or regulated workflows. In financial services, healthcare, and other high-assurance sectors, the merger review should also consider auditability, evidence retention, and regulatory impact on access decisions. A practical exception is the acquired business with fragile legacy applications: immediate shutdown of every inherited integration may be unrealistic, but each exception should have a named owner, expiry date, and compensating control.
The governing principle is simple: if a human role is being changed, the machine identities supporting that role should be reviewed at the same time. That alignment is what prevents a clean HR event from becoming an unmanaged technical exception that persists long after the deal closes.
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 SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 | Mergers require identity inventory and access governance across the combined estate. |
| OWASP Non-Human Identity Top 10 | NHI-02 | Mergers often expose over-privileged or ownerless non-human identities. |
| NIST SP 800-53 Rev 5 | AC-2 | Account lifecycle control is needed to remove stale human and machine access. |
Inventory all identities and access paths, then verify they are authorised and tracked.
