Identity governance fails when programs stop at phase one

At a glance

What this is: This analysis argues that phase-one IGA programs create durable coverage gaps because disconnected, legacy, and non-federated applications are left outside automated governance.

Why it matters: For IAM and IGA teams, the issue is not initial deployment but whether lifecycle control, access review enforcement, and offboarding still work when applications are hard to integrate.

By the numbers:

• Only 54% of applications are adequately integrated with an IGA platform.
• Only 6% of organisations report fully automated IGA processes.

Context

Identity governance programs often begin with a limited set of high-value applications, but that starting point can harden into a permanent boundary. The problem is coverage, not intent. When disconnected, legacy, or non-federated applications stay outside the governance plane, access reviews and lifecycle controls lose enforcement power.

The article's core claim is that phase-one thinking underestimates the operational and financial cost of getting to full coverage. That matters for IGA because unmanaged applications are not a side issue: they become the place where joiner-mover-leaver control, certification, and auditability break down first.

Key questions

Q: What breaks when identity governance starts with too many applications at once?

A: The programme loses control quality before it builds control coverage. Reviewers face too much scope, owners become unclear, remediation falls behind, and access decisions turn into checkbox activity instead of a governed process. Starting with critical systems keeps the first control loop small enough to complete, verify, and improve before broader rollout.

Q: Why do disconnected apps create so many audit problems?

A: Because auditors need proof that access was granted, reviewed, and revoked consistently, not just a statement that policy exists. Disconnected apps often force teams to assemble evidence after the fact from emails, screenshots, and export files. That is slow, fragile, and difficult to defend when controls are reviewed at scale.

Q: How can security teams tell whether IGA coverage is actually complete?

A: They should compare the number of applications in governance workflows with the number of applications found through discovery and network evidence. If those counts diverge materially, the programme is only covering the visible layer. Completeness, not process activity, is the real success measure.

Q: Should organisations prioritise full coverage or deeper automation first?

A: Coverage comes first when major application classes still sit outside the identity control plane, because automation that only applies to a narrow subset leaves the largest risk untouched. Deeper automation matters, but only after the programme can govern the applications most likely to carry stale access, manual exceptions, and lifecycle drift.

Technical breakdown

Why phase-one IGA architectures leave blind spots

Phase-one IGA usually prioritises the easiest integrations first, such as HR systems and a small set of compliance-sensitive applications. That approach creates a skewed control model because the hardest systems are left for later, including legacy platforms, vendor-hosted tools with gated APIs, and custom applications without standard connectors. Once those systems remain outside the integration layer, governance becomes partial by design. The architecture looks complete on paper, but the control plane never reaches the full application estate.

Practical implication: Treat partial integration as an architectural limitation, not a temporary implementation phase.

Why custom connectors become a maintenance tax

Custom connectors often have no durable support model after implementation ends. When an application changes its UI, API, or permission structure, the connector can break and has to be rebuilt from scratch. Over time, teams spend more capacity preserving old integrations than onboarding new ones. That maintenance burden quietly consumes the budget that was supposed to expand coverage, which is why many programs plateau well before full governance is reached.

Practical implication: Plan for connector lifecycle ownership before relying on custom integrations at scale.

How disconnected applications weaken lifecycle and access review controls

When an application cannot be connected to core identity systems, lifecycle actions become manual and access reviews become documentation exercises rather than enforcement. Administrators must log into each app separately to provision, deprovision, or change access, which increases delay and error. That is how ghost accounts and orphaned access persist. In governance terms, the issue is not just inconvenience. It is loss of control fidelity across the joiner-mover-leaver process.

Practical implication: Assume any disconnected application can preserve stale access unless lifecycle actions are enforced directly.

Threat narrative

Attacker objective: The attacker aims to find the least governed application path and exploit it for persistent, low-friction access.

1. Entry occurs through unmanaged, disconnected, or legacy applications that sit outside automated identity governance.
2. Credential or account misuse becomes easier because those applications do not consistently receive integrated lifecycle controls or certification enforcement.
3. Impact follows when stale accounts, delayed offboarding, and weak review enforcement create persistent access paths that security teams do not continuously see.

NHI Mgmt Group analysis

Partial IGA coverage is not a staging problem, it is a structural governance gap. Programs that stop at phase one do not merely delay maturity; they establish a two-tier control model where connected apps are governed and disconnected apps are effectively exceptions. That matters because the exception set is usually the most operationally awkward and therefore the least likely to shrink. Practitioners should treat coverage completeness as a core governance outcome, not a roadmap aspiration.

The maintenance burden of custom connectors is the hidden reason phase-one programs stall. Every brittle integration competes with new onboarding, and every change to a target application creates rework that rarely shows up cleanly in budget plans. The result is control debt: the governance programme spends more time preserving past integrations than expanding reach. The practical conclusion is that connector durability is as important as connector availability.

Identity governance fails when access review is reduced to recordkeeping for disconnected systems. If certification cannot drive revocation, the control has lost its enforcement value and become audit theatre. That failure mode is most visible in applications that cannot participate in automated joiner-mover-leaver processes, which is why disconnected apps are where lifecycle control and auditability diverge first. Teams should measure whether reviews actually change access, not whether the review was completed.

Coverage gaps convert identity governance into a risk-acceptance workflow for the rest of the estate. Once teams normalise exceptions for hard-to-integrate applications, the programme starts optimising for convenience rather than control. That creates a false sense of maturity because the visible core is well managed while the hidden edge remains open. Practitioners should reframe full coverage as the point at which the programme begins to function as governance rather than documentation.

Coverage completeness is the new identity blast radius metric. The more applications sit outside governed workflows, the larger the effective attack surface becomes, even if the central IGA platform itself is well managed. This is a governance problem with security consequences, not a security tool problem with governance side effects. Practitioners should evaluate blast radius by the share of applications that can actually be governed, not by the size of the platform deployment.

From our research library:

• Nearly 60% of IT leaders cite restrictive cost and complexity as a weakness of legacy identity governance, according to the 2025 State of Identity Governance Report.
• Read next: NHI Lifecycle Management Guide

What this signals

Coverage completeness, not just platform deployment, is the real maturity marker for identity governance. A program that governs only the easy applications leaves a hidden control boundary around the systems most likely to resist standard integration. That boundary becomes the place where joiner-mover-leaver controls, certification, and offboarding lose their force.

Disconnected applications force identity teams to choose between manual work and governance drift. The longer that choice persists, the more identity governance becomes a recordkeeping function instead of an enforcement function, which changes the programme's security value even when the core platform appears healthy.

For practitioners

• Define coverage as a programme objective Set a target for the percentage of applications that must be governed, not just the number of systems initially integrated. Track disconnected apps separately so phase-one does not become the de facto end state.
• Inventory the hard-to-integrate estate Create a separate backlog for legacy, non-federated, vendor-hosted, and custom-built applications that cannot join standard workflows. Rank them by risk and operational friction instead of assuming manual control is acceptable.
• Test whether certification actually enforces revocation Sample access reviews in disconnected systems and verify that approved removals are executed, not just recorded. If reviews do not change access, treat the control as documentary, not preventive.
• Assign connector lifecycle ownership Make one team accountable for connector health, rebuilds, and changes in target application APIs or UI. Without explicit ownership, integration failures will accumulate as hidden control debt.
• Measure offboarding lag in unmanaged apps Track the time between leaver events and actual revocation in systems outside the core identity stack. That metric exposes where manual lifecycle work is creating stale access.

Key takeaways

• Phase-one IGA programs tend to overprotect the easiest applications and under-govern the hardest ones.
• Disconnected systems turn certification, provisioning, and offboarding into manual processes that are slower and less reliable.
• Full coverage is a governance objective, not a later optimisation, because exceptions become the place where stale access accumulates.

Key terms

• Phase One IGA: A limited identity governance rollout that covers only a small set of high-priority applications first. The approach is useful for early progress, but it becomes a risk when the rest of the application estate is left outside enforceable lifecycle and certification controls.
• Disconnected Application: An application that is not integrated with the organisation's central identity and access stack. Access is often managed through shared passwords, manual approval, or local admins, which makes revocation, evidence, and ownership harder to enforce consistently across the application lifecycle.
• Connector lifecycle: Connector lifecycle is the full set of steps that covers creating, scoping, reviewing, rotating, and retiring integration accounts and add-ons. The lifecycle matters because integrations often remain active after business ownership changes, which creates hidden access and audit risk. Governance has to track the connector from birth to offboarding.
• Time To Governance Coverage: Time to governance coverage is the interval between a new system, entitlement or identity type appearing and that access being brought under policy and review. In mature programmes, the interval is short enough that business change does not create a prolonged blind spot.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.