What breaks when IAM and PAM tools are not aligned across two merged companies?

Why This Matters for Security Teams

When two companies merge, IAM and PAM rarely fail in a single dramatic event. They fail as a control-plane mismatch: one side trusts broad directory groups, the other trusts tightly scoped privileged workflows, and neither mapping is complete. That leaves administrators, service accounts, and break-glass paths with contradictory ownership, which delays remediation and makes access review decisions unreliable. NIST’s NIST Cybersecurity Framework 2.0 treats governance as an enterprise function, but post-merger identity programs often inherit two different operating models that were never designed to reconcile. In NHIMG research on the Ultimate Guide to NHIs, 97% of NHIs carry excessive privileges, which is exactly the kind of hidden exposure that becomes harder to detect after integration.

Security teams usually expect the directory merger to be the hard part. In practice, many organisations discover the real problem only after a dormant privileged path is used, rather than through intentional identity rationalisation.

How It Works in Practice

Alignment starts by treating IAM and PAM as one lifecycle problem instead of two tools. Identity consolidation must map who can request access, who can approve it, who can elevate it, and who can revoke it. If those decision points do not line up across both companies, inherited access remains valid even after accounts are merged, renamed, or shadow-linked through nested groups. That is how hidden trust relationships survive long after the Day 1 integration plan is closed.

Operationally, the combined estate needs a single authoritative view for user identities, service accounts, and privileged pathways. PAM should not merely wrap existing entitlements; it should enforce time-bound elevation, session controls, and auditability for the merged set of roles. IAM should provide consistent joiner-mover-leaver handling, but it must also ingest privileged state so that an account’s ordinary role and its elevated reach are always evaluated together. Current guidance suggests that merged firms also need a structured inventory of secrets, keys, and break-glass accounts because those assets frequently outlive the directory records tied to them. NHIMG’s Azure Key Vault privilege escalation exposure illustrates how privilege boundaries can collapse when role design and secret access are not aligned.

• Reconcile role catalogs before moving users into shared groups.
• Map privileged entitlements to a single approval chain and a single revocation process.
• Validate offboarding for both human and non-human identities, including API keys and service accounts.
• Use periodic entitlement diffing to identify accounts that gained privilege through migration shortcuts.

For technical control design, NIST CSF 2.0 is useful for governance structure, while the BeyondTrust API key breach is a reminder that privileged tooling itself becomes a merger risk if secrets, approvals, and session controls are not re-baselined. These controls tend to break down when one company uses federated access heavily and the other depends on local administrative exceptions, because exception handling becomes the path of least resistance.

Common Variations and Edge Cases

Tighter identity consolidation often increases operational friction, requiring organisations to balance cleaner governance against business continuity during the merger window. The hardest edge cases are usually not employee accounts but service identities, vendor accounts, and emergency access. Those identities often sit outside standard HR-driven lifecycle processes, so they survive platform consolidation with stale approvals attached. Best practice is evolving here: there is no universal standard for how quickly both estates should converge, but there is broad agreement that parallel trust models should not remain in place indefinitely.

A second variation appears when one company has mature PAM and the other has only directory-based access controls. In that case, the merged program can mistakenly assume PAM coverage exists because the tool is licensed or partially deployed. It may not. The result is split governance, where privileged sessions are monitored in one environment but still granted through legacy admin rights in the other. That gap also affects non-human identities because machine credentials are often harder to discover than human entitlements. NHIMG’s Schneider Electric credentials breach shows how credentials exposure can persist when ownership and revocation are not synchronised.

Merged companies should also expect exceptions around subsidiaries, regulated business units, and third-party integrations. Those areas often need temporary dual controls, but the exception must have an expiry date and a named owner. Otherwise, the integration program quietly turns temporary overlap into permanent risk.

Related resources from NHI Mgmt Group

• What breaks when identity governance is split between IAM, PAM, and secrets tools?
• What breaks when audit evidence is fragmented across IAM and PAM tools?
• What breaks when IAM is treated as a set of tools instead of a process?
• How should security teams govern access to sensitive data across IAM and data security tools?