IGA enforcement fails when non-standard apps stay out of scope

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Way Security's blog post: IGA programmes often stop at SCIM-friendly applications, leaving legacy, custom and disconnected systems outside lifecycle enforcement and access review coverage.

Why it matters: This matters because IAM and IGA teams are judged on control coverage, not deployment status, and partial enforcement leaves the highest-risk systems governed by manual workarounds rather than policy.

Context

Enterprise IGA often stalls at the point where applications stop behaving like the governance model expects. Standard connectors, clean schemas and predictable lifecycle workflows make some systems easy to control, but the remainder of the portfolio still has to be governed somehow. That gap creates implementation limbo: the platform exists, but enforcement does not reach every identity and entitlement it was meant to cover.

The governance problem is not the purchase of an IGA platform. It is the boundary between systems that can be automated and systems that cannot, especially when teams compensate with spreadsheets, CSV exports and manual deprovisioning. That is where access reviews and certification become a coverage problem rather than a process problem.

Key questions

Q: How should teams handle applications that cannot be enforced by IGA tooling?

A: Treat them as a governance exception with a named owner, documented scope, and compensating controls such as manual certification, periodic entitlement attestation, log review, and time-bound review dates. If IGA tooling cannot enforce provisioning or deprovisioning, the application still needs an accountable system owner, a clear access model, and an offboarding path for accounts, roles, and shared credentials.

Q: Why do access reviews fail when key applications are out of scope?

A: Access reviews fail because the review only covers what the IGA platform can see, so material entitlements in out-of-scope systems remain unexamined. That leaves orphaned accounts, excessive privileges, and toxic combinations outside certification, which weakens the joiner, mover and leaver process and makes attestation incomplete even when the formal review is signed off.

Q: How should security teams reduce risk in manual identity governance processes?

A: Security teams should remove repeatable approval work from email and spreadsheet handling, then tie each access decision to identity context, entitlement state, and ownership. The goal is not just speed. It is to make every access change auditable, reviewable, and easier to defend when compliance or incident response asks why the access existed.

Q: What is the difference between lifecycle automation and partial governance coverage?

A: Lifecycle automation provisions, changes, and removes access through an integrated workflow, while partial governance coverage only certifies or reports on some systems. The joiner, mover and leaver process can still work for covered applications, but uncovered ones need manual provisioning, deprovisioning, and evidence collection, otherwise access drift persists outside the automated control.

Technical breakdown

Why IGA enforcement stops at the application boundary

IGA platforms depend on applications exposing something governable, such as a standard connector, API or schema that maps users and entitlements cleanly. When an application does not meet that threshold, the platform cannot enforce lifecycle actions or review workflows in the normal way. Teams then choose between custom integration, professional services or treating the app as out of scope. That turns enforcement into a portfolio-selection problem instead of a governance control. The mechanism is not a software failure alone. It is a mismatch between the governance model and the application interface. See the NHI Lifecycle Management Guide.

Practical implication: Classify every application by whether it can actually be enforced, not just whether it is listed in the IGA programme.

How manual middleware replaces policy

When governance tools cannot reach an application directly, people become the enforcement layer. They export user lists, deprovision accounts by hand and reconstruct entitlement evidence in spreadsheets so access reviews can proceed. That workaround preserves the appearance of control, but it removes repeatability, auditability and timeliness. The failure mode is not just inefficiency. It is that the governance decision is now separated from the system of record by human intervention, which creates drift, delay and inconsistent outcomes across the portfolio.

Practical implication: Treat repeated manual handling of identities and entitlements as a control dependency, not an acceptable operating model.

What full enforcement means for lifecycle automation

Lifecycle automation only deserves the name when it applies across the portfolio, including legacy, homegrown and disconnected applications. If half the estate is automated and the rest is handled outside the platform, the programme has coverage gaps that will show up in audits and access disputes. The deeper issue is that governance intent has been configured centrally but not enforced consistently at the edge. That makes the programme look complete while leaving real exposure in the systems hardest to retire.

Practical implication: Measure lifecycle automation by enforced coverage across all applications, not by the number of apps connected to the platform.

NHI Mgmt Group analysis

Implementation limbo is a governance state, not a temporary rollout phase. A programme that controls only the applications with clean connectors does not become safer because it is fully licensed or well diagrammed. It becomes selective governance, with the hardest systems left to manual exception handling. The practitioner question is not whether the platform works on the easy estate. It is whether the control model survives contact with the rest of the portfolio.

Enforcement, not procurement, defines whether IGA exists in practice. Buying a governance platform creates policy potential, not policy coverage. Once the team starts exporting CSVs, screenshotting entitlements or deprovisioning through individual consoles, the operating model has shifted from automated governance to human middleware. That is a structural weakness because the control path now depends on staff capacity and memory rather than enforceable system behaviour.

Coverage gaps create an audit problem before they create an attacker problem. If an access review omits the systems where sensitive data lives, the organisation has certified only the easy part of the estate. The broken assumption is that a programme can be considered complete while its least standard applications remain outside enforcement. Practitioners should treat missing enforcement as a control gap, not a tooling nuance.

Custom connectors are often a symptom of governance debt, not a sustainable design choice. Repeated one-off integration work is usually how programmes postpone the harder decision about application rationalisation, enforcement scope and control ownership. The named concept here is enforcement limbo: the condition where IGA is active in theory but incomplete in practice. Teams should read that as a signal that control coverage, not product deployment, is the real maturity issue.

Legacy and disconnected applications define the true perimeter of identity governance. Systems that resist standard integration are not edge cases once they contain business data or privileged access. They are the systems that determine whether lifecycle controls, access reviews and deprovisioning are meaningful. The programme boundary is therefore operational, not architectural, and it is set by the hardest-to-govern application in scope.

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.

What this signals

Enforcement coverage is the real maturity metric. IGA programmes should now be judged by how much of the application portfolio is actually under policy enforcement, not by how many connectors exist on paper. Once manual handling becomes the routine fallback, the organisation has already accepted a two-tier governance model that will be difficult to defend in audit or incident review.

The operational signal to watch is whether exceptions are shrinking or becoming permanent. A programme that keeps adding ungoverned systems while calling itself live is not in transition. It is normalising exception-driven identity control, and that pattern tends to spread from legacy apps into adjacent governance processes.

For practitioners

• Audit enforcement coverage by application class Separate apps that are genuinely enforced from apps that are only listed in the programme. Document where lifecycle actions, access reviews and deprovisioning are automated, and where staff still intervene manually.
• Eliminate manual middleware for recurring controls Replace CSV exports, spreadsheet-based certification and console-by-console offboarding with a tracked control path. If the team repeats the same manual steps each quarter, that activity is functioning as part of the control design.
• Set a hard standard for in-scope systems Require each application to meet a defined governance threshold before it can be counted as covered. Systems that cannot support that threshold should be escalated as exceptions, not silently absorbed into the programme.
• Use application rationalisation to close exception drift Review whether long-lived exceptions exist because the app is strategically necessary or because the governance path is too expensive to build. If the latter is true, make the exception visible and time-bound.

Key takeaways

• IGA programmes can appear operational while still leaving critical applications outside enforced control.
• Manual workarounds such as CSV exports and spreadsheet certifications are evidence of a governance gap, not a harmless exception.
• The practical measure of maturity is whether lifecycle actions and access reviews are enforced across the full application estate.

Related NHI Mgmt Group resources: Access Reviews and Certification Guide · NHI Lifecycle Management Guide · IGA Buyer's Guide · Joiner-Mover-Leaver (JML) Guide

Key terms

• Identity Governance and Administration (IGA): A framework of policies, processes, and technology to manage and govern digital identities and their access rights. Increasingly extended to cover non-human identities alongside human users.
• Access Review: A formal process for confirming whether access is still needed and justified. In IAM programs, the review becomes an evidence-bearing control when decisions are recorded, scoped correctly, and traceable to the right reviewer, application owner, or auditor.
• Joiner Mover Leaver: Joiner Mover Leaver is the identity lifecycle process for creating, changing, and removing access as people enter, change roles, or leave an organization. It governs provisioning, modification, and deprovisioning across systems, ensuring access matches current job needs and reducing orphaned accounts, privilege creep, and residual access risk.
• Scim: System for Cross-domain Identity Management is the standard used to exchange user and group lifecycle data between an identity provider and an application. In production, the protocol only solves part of the problem. The harder issue is whether the implementation preserves attributes, order, and tenant scope consistently across real directory sources.

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.