When should organisations treat identity governance as core infrastructure instead of an add-on?

When Core Infrastructure Is the Right Operating Model

Identity governance belongs in the infrastructure layer when it has to work across multiple control planes, not just inside one application. Once access decisions affect cloud services, legacy systems, and business-critical workflows, the organisation needs a durable operating model for ownership, review cadence, and entitlement scope. That is the point where governance stops being a project and becomes part of the control plane.

In practical terms, core infrastructure means identity review, role maintenance, joiner-mover-leaver handling, and exception handling are designed into the rollout architecture rather than bolted on later. A core model is easier to standardise across platforms, and it avoids the common failure mode where each business unit or system owner invents its own partial approval path.

A useful test is whether the rollout can still be trusted if one major application changes, a new cloud environment is added, or a business process is replatformed. If the answer depends on ad hoc exceptions, manual reconciliations, or one-off spreadsheets, governance is already functioning as infrastructure in practice, even if it has not been funded that way.

What Add-On Governance Usually Gets Wrong

Add-on governance tends to trail the actual access model. That creates fragmented scope, inconsistent review quality, and delayed coverage for the systems that matter most. It also encourages teams to treat identity controls as a wrapper around applications instead of a design requirement for how access is granted, monitored, and removed.

The biggest weakness is that add-on governance usually covers the easy cases first and leaves the hardest ones for later. Legacy platforms, shared accounts, disconnected workflows, and business exceptions are then left outside normal review cycles, which creates blind spots in entitlements and makes the overall control harder to evidence.

For that reason, organisations should think in terms of control durability, not control convenience. If the governance process cannot survive system consolidation, workflow redesign, or ownership changes without losing coverage, then it is still an overlay. Core infrastructure is the model that keeps working when the environment changes.

Core treatment also improves accountability. When governance is owned as a platform capability, the organisation can define who owns policy, who owns exceptions, and who can prove coverage. That matters because identity governance fails most often at the handoff between system teams, security teams, and business owners.

How to Decide When the Shift Has Become Necessary

The shift becomes necessary when partial coverage creates material risk. That usually shows up as repeated audit gaps, inconsistent recertification across platforms, privileged access that is reviewed in some places but not others, or business workflows that can still run after an employee change, role change, or vendor change without reliable deprovisioning.

Another signal is scale. If the organisation must govern a growing mix of SaaS, on-premises applications, integrations, and non-standard access paths, then the architecture of governance matters as much as the policy itself. At that point, the main decision is no longer whether to review access, but how to make review, ownership, and enforcement repeatable across systems.

A core model is justified when the control itself depends on other core services such as source-of-authority data, role models, access review workflows, and entitlement inventories. When those dependencies become permanent, governance is no longer a surrounding process. It is part of the platform architecture that other controls rely on.

Risk and Threat Considerations

Identity governance left as an add-on creates predictable exposure: unreviewed access persists longer, exceptions multiply, and the organisation loses confidence that entitlement decisions reflect current business need. That becomes especially risky where access crosses cloud and legacy estates, because gaps in one environment can undermine the assurance of the whole control set.

Failure mechanism: Coverage starts unevenly, then fragments further as new systems, acquisitions, and manual exceptions bypass the original governance design. The result is stale access, orphaned accounts, privilege creep, and weaker evidence that access reviews are complete.

Impact: The organisation may fail to detect or remove excessive access before audit, incident response, or business change exposes it. In the worst case, a control that appears to exist on paper does not actually bound who can act inside critical workflows.

Practitioner Guidance

What to prioritise: Treat the highest-risk workflows first, especially those that cross platform boundaries or depend on multiple owners. If a workflow can move money, change records, approve actions, or alter entitlements, it deserves core governance treatment before lower-value application onboarding.

What to verify: Confirm that review scope, role ownership, and offboarding coverage are defined at the platform level, not per application. You should be able to show which systems are covered, who certifies access, what exceptions exist, and how removed access is actually enforced.

Common mistake: Do not measure success by platform purchase or policy publication. The relevant test is whether governance still works after system change, because that is where add-on designs usually fail.

Practitioner takeaway: Identity governance becomes core infrastructure when the organisation needs one repeatable control model for changing systems, not a collection of local reviews that happen to use the same policy language.

Related resources from NHI Mgmt Group

• What breaks when organisations treat machine identity governance as a side project instead of a core security discipline?
• What breaks when organisations treat identity compliance as a one-time legal exercise instead of an ongoing governance function?
• Why is it important to integrate identity and data governance?
• When should organisations treat an NHI as a high-priority risk?