They fail because inherited access and approval chains often remain intact after the operating model changes. Two merged environments may have conflicting role definitions, duplicate privileges, and old admin paths that no longer match the new reporting structure. Without a full access rationalisation, SoD becomes a patchwork of exceptions rather than a control.
Why This Matters for Security Teams
segregation of duties only works when the organisation’s access model reflects how work is actually approved and executed. After a merger or reorganisation, that assumption often breaks: inherited admin paths, duplicated approvers, and legacy exceptions can survive long after reporting lines change. NIST’s NIST Cybersecurity Framework 2.0 treats governance as an ongoing function, which is exactly the point here: SoD is not a one-time design artefact.
The practical risk is not only fraud or policy breach. Broken SoD also creates unclear ownership, delayed approvals, and shadow workarounds that bypass the new operating model. In merged environments, teams often keep “temporary” access in place because no one wants to block business continuity during transition, and those temporary paths become permanent. NHI Management Group’s Ultimate Guide to NHIs — Standards is useful here because the same access drift patterns show up in both human and non-human identities when inventory and governance are incomplete.
In practice, many security teams discover SoD failure only after a control exception is triggered, rather than through intentional access rationalisation.
How It Works in Practice
The control fails when post-merger access is mapped to old role assumptions instead of the new operating model. A purchasing manager, for example, may inherit both request and approval rights from one legacy system and retain privileged task execution in another, even though those duties should now be separated. The issue is amplified when each side of the merger uses different RBAC taxonomies, different ticketing workflows, and different approval chains.
A workable response starts with a full entitlement inventory across both environments, then a reconciliation of business roles, system roles, and delegated approvals. Security teams usually need to:
- identify overlapping privileges and duplicate approvers across inherited systems
- rebuild role definitions around current business functions, not legacy org charts
- remove standing exceptions and convert temporary elevation into time-bound approval flows
- validate SoD rules against actual transaction paths, not just policy documents
- treat privileged access as a separate review stream, especially where admin paths survived the transition
For broader identity hygiene, NHIMG’s DeepSeek breach case material shows how quickly exposed credentials and weak governance compound when environments are already fragmented. That pattern is relevant in reorganisations too: once people, systems, and approvals are re-threaded informally, control evidence becomes unreliable. Current guidance suggests combining access recertification with process redesign, not treating recertification as a standalone checkbox.
These controls tend to break down when two enterprise resource planning systems remain active in parallel because SoD checks are enforced differently in each platform and no unified approval model exists.
Common Variations and Edge Cases
Tighter SoD enforcement often increases operational friction, requiring organisations to balance cleaner control boundaries against slower execution during transition periods. That tradeoff is especially visible in carve-outs, shared services, and post-merger integration programmes where the business cannot afford to stop processing while access is being redesigned.
There is no universal standard for this yet, but best practice is evolving toward continuous access rationalisation rather than annual review cycles. In highly regulated environments, a temporary exception register may be necessary, but it should have expiry dates, named owners, and a path to removal. In weaker governance environments, exceptions tend to become the new operating model.
Two edge cases matter most. First, when the same person gains authority through multiple legal entities, SoD can appear satisfied on paper while still failing in practice because approvals are effectively self-approved through alternate channels. Second, when automation or service accounts replace human workflows, teams sometimes overlook that NHI permissions can recreate the same conflict patterns if bot ownership and approval logic are not separated. The operational lesson is simple: after a merger, SoD must be tested against real transactions and real approvers, not inherited documentation.
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 AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-03 | Mergers require ongoing governance and risk recalibration, not one-time SoD design. |
| OWASP Non-Human Identity Top 10 | NHI-04 | Inherited privileges and stale access paths are classic identity hygiene failures. |
| NIST AI RMF | Organisational change needs governance, mapping, and accountability across shifting workflows. |
Reassess SoD risk continuously after integration and update controls when roles or approvals change.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
