Inherited roles, duplicated permissions, and stale exceptions survive the merger and create a control environment where nobody can prove access still matches business need. That weakens accountability, increases lateral movement risk, and makes service continuity harder to defend. The failure is not just technical integration. It is governance that no longer maps cleanly to the new operating model.
What actually breaks when identity and access models are merged without revalidation?
When councils merge identity and access models without rechecking the underlying rules, the broken part is usually not the directory or policy engine first. It is the governance model behind them, inherited roles, duplicated permissions, stale exceptions, and assumptions about who should still have access. The result is access that looks unified on paper but no longer reflects the current operating model.
A merger can leave old entitlement patterns intact because the new model is built on old grants, not fresh business justification. That creates a drift problem: the organisation may believe it has simplified control, while the actual access graph has become harder to explain, review, and defend.
The most common failure is that access decisions lose their business anchor. A role that made sense in one council or organisational unit may become oversized in the merged structure, while exceptions remain because no one can prove they are obsolete. That weakens accountability and turns access review into a documentation exercise instead of a control.
Why merged models drift from business need so quickly
Identity and access models are only durable when the access model, the ownership model, and the review process all match the same operating reality. If a merger changes reporting lines, product boundaries, or approval authorities, the old access structure can survive longer than the organisation’s intent. That is especially true where IAM and IGA Basics are treated as one-time design work instead of an ongoing governance loop.
Once the model drifts, inherited roles tend to accumulate extra permissions because they are convenient starting points for new teams. Duplicated permissions then appear across overlapping functions, and stale exceptions remain because nobody wants to break a service during the merger. The technical system may still function, but the control environment stops answering a simple question: why does this identity still need this access?
That is also why merger activity is a classic point where role engineering and access governance must be revisited together. If the organisation does not revalidate roles, entitlement ownership, and review cadence at the same time, it can end up with merged reporting and split accountability.
Where the control failure becomes operationally visible
The first visible symptom is usually inconsistency in review outcomes. Two reviewers can approve the same entitlement set for different reasons, because the merged model no longer gives them a shared standard for what “appropriate” means. The second symptom is remediation friction: teams hesitate to remove permissions because no one can prove whether they are still required for continuity, support, or escalation handling.
That is why a merger can undermine both accountability and resilience. If the access model is no longer aligned to the operating model, service continuity becomes harder to defend during incidents, staff changes, or audit review. A good control environment depends on a clean answer to ownership, and that answer gets blurry when councils merge without reconciling exceptions, approvals, and role boundaries. The same logic applies to Identity Governance Maturity Model when the question is whether governance still matches how access is actually granted and reviewed.
A merged model can also create hidden privilege concentration. Small overlaps between role sets, legacy emergency access, and inherited admin rights may not look severe individually, but together they expand lateral movement paths and make internal abuse easier to sustain. That is why councils should examine the merged access graph, not just the merged policy document.
Risk and Threat Considerations
Merging identity and access models without revalidation creates a governance gap that attackers and insiders can exploit. The risk is not only excessive privilege, it is the loss of reliable ownership and review discipline, which makes it harder to spot who has access, why they have it, and whether it still matters.
Failure mechanism: Legacy entitlements survive the merger, exceptions are grandfathered forward, and duplicated permissions accumulate across the new model. Over time, that widens the attack surface and leaves privileged paths in place after the business need has changed.
Impact: Lateral movement becomes easier, access reviews become less credible, and service continuity is harder to justify because the organisation cannot clearly prove that access matches current need.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Merged access models change account and entitlement ownership. |
| AC-6 — Least Privilege | Duplicate and stale permissions create excessive privilege after mergers. | |
| AU-6 — Audit Review, Analysis, and Reporting | Revalidation depends on review evidence that can explain access decisions. | |
| Recommendation — Revalidate account ownership and remove inherited access that no longer has a current business need. Reduce merged roles to the minimum permissions needed for current duties. Use access review evidence to challenge permissions that cannot be justified after the merger. | ||
| CIS Controls v8 | CIS-5 — Account Management | Council mergers often leave orphaned, duplicated, or stale access assignments. |
| Recommendation — Inventory and remove inherited accounts and permissions that no longer map to current roles. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Merged identity and access models need coherent access rules and reviewable governance. |
| Recommendation — Update access control rules so merged roles still reflect current business need and approval paths. | ||
Practitioner Guidance
What to verify: Revalidate the merged role catalogue against current business ownership, not against the pre-merger grant history. If a role cannot be explained in business terms, treat it as a candidate for redesign or removal rather than preservation.
Decision rule: If a permission exists only because two legacy models were combined, do not assume it is safe to keep. Require explicit reapproval for inherited roles, duplicated entitlements, and any exception that depends on the old operating model.
What practitioners underestimate: The hardest problem is often not privilege excess but unclear accountability. When ownership is ambiguous, remediation slows down, reviews lose force, and the same access paths survive because no team feels fully responsible for challenging them.
Practitioner takeaway: A merged model is only defensible when every inherited entitlement can still be justified, owned, and reviewed under the new governance structure, otherwise the merger simply industrialises access drift.