Why do Light IGA programmes often fail in mixed estates?

Why This Matters for Security Teams

light iga programmes are attractive because they promise faster onboarding, simpler certifications, and less administrative overhead. The problem is that mixed estates rarely behave like a clean SaaS-only identity model. Legacy applications, contractor access, custom APIs, service accounts, and air-gapped environments often sit outside the tooling’s native collection path, so the review process becomes a partial inventory rather than a governance control. That is a structural weakness, not a maturity issue.

When identity governance only sees one layer of the estate, toxic access can survive in the blind spots for months. That matters even more where secrets and credentials are already under pressure: NHIMG’s The State of Secrets in AppSec shows how fragmented secrets handling and slow remediation are common across organisations. The same dynamic appears in mixed estates, where the governance team assumes coverage that the tooling cannot actually prove. The NIST Cybersecurity Framework 2.0 is useful here because it treats asset visibility and control coverage as foundational, not optional.

In practice, many security teams encounter unresolved access paths only after a joiner-mover-leaver event, an audit request, or a credential incident has already exposed the gap.

How It Works in Practice

Light IGA usually works best in estates where identities, entitlements, and applications share a common control plane. In mixed environments, that assumption breaks down. The programme may still produce certification reports, but those reports reflect only what the connector can observe. That means the real design question is not whether access reviews exist, but whether the organisation has a complete and continuously updated map of human and non-human access across every system boundary.

Effective teams usually combine IGA with other control layers rather than expecting one platform to solve the entire estate. Common patterns include:

• Using IGA for high-value business applications while using PAM for administrative and break-glass access.
• Pulling in contractor, third-party, and service account inventories from CMDB, HR, cloud, and secrets systems.
• Reconciling entitlements from legacy systems through exports, scripts, or scheduled jobs when no native connector exists.
• Defining exception workflows for air-gapped or operational technology environments where direct integration is impossible.
• Tracking both human and non-human access so service identities are not silently excluded from reviews.

This is where governance and identity architecture intersect. NIST’s identity guidance in the NIST Cybersecurity Framework 2.0 reinforces the need for complete asset visibility and access control. For NHI-heavy estates, NHIMG’s LLMjacking research is a reminder that compromised machine identities are often exploited faster than teams can refresh access records, so governance must keep pace with actual credential exposure, not just quarterly review cycles.

These controls tend to break down when the estate contains unmanaged service accounts, bespoke integrations, or systems that cannot export entitlement data in a consistent format because the review process becomes dependent on manual reconciliation.

Common Variations and Edge Cases

Tighter governance often increases operational overhead, requiring organisations to balance coverage against integration cost and audit fatigue. That tradeoff is especially visible in mixed estates, where the “light” approach may be enough for low-risk SaaS but too thin for regulated, legacy, or contractor-heavy environments.

Best practice is evolving, but current guidance suggests there is no universal standard for how much of an estate must be directly integrated before a programme can claim meaningful coverage. Some teams accept partial automation if they can prove compensating controls, while others treat any unmanaged slice as a policy exception that must be risk accepted explicitly. The right answer depends on the blast radius of the uncovered systems.

Edge cases usually include mainframe access, offshore support teams, merged acquisitions, and temporary vendor access where identity source systems differ and revocation timelines are inconsistent. In those environments, the failure mode is not usually a missing report. It is a false sense of completeness created by good-looking dashboards. A mature programme should surface gaps, label them clearly, and route them into remediation or formal exception handling rather than pretending they do not exist. NHIMG’s DeepSeek breach is a useful example of how hidden exposure can become material long before a routine control catches it.

Where integration is impossible, the control objective should shift from perfect automation to demonstrable visibility, documented exceptions, and explicit ownership for every uncovered identity source.

Related resources from NHI Mgmt Group

• Why do SSO tools often fail to solve access governance on their own?
• Why does role modelling often fail to reduce access risk in practice?
• Why do cloud app security tools often fail IAM governance needs?
• What do security teams get wrong about RBAC in IGA programmes?