Notifications
Clear all
Topic starter
30/07/2026 10:49 pm
TL;DR: IGA programmes often look mature on paper but still govern only a fraction of the application estate because connectivity, not features, is the real constraint, according to StackBob and survey data from SailPoint, Omdia, Gartner, and others. The governance problem is coverage, not capability: if identity state cannot be read or written, maturity scores overstate control.
NHIMG editorial — based on content published by StackBob: an analysis of how IGA maturity models miss application connectivity
By the numbers:
- At organizations averaging roughly 1,100 applications, only about 54% are adequately integrated with IGA.
- Only 5.7% of organizations have full visibility into their service accounts.
Questions worth separating out
Q: How should teams measure IGA maturity when many applications are not integrated?
A: Measure the percentage of the application estate that can be governed end to end, not the number of features purchased.
Q: Why do IGA programmes look mature but still leave major gaps?
A: Because maturity models often score capabilities inside the platform rather than the applications the platform can actually reach.
Q: What breaks when disconnected applications are not brought into identity governance?
A: When disconnected applications sit outside the identity system, provisioning, review, and offboarding become inconsistent and hard to evidence.
Practitioner guidance
- Map governed application coverage Build a current-state inventory that separates applications into three groups: fully governable, partially governable, and unreachable.
- Measure maturity by reach, not features Replace capability scorecards with a coverage metric that shows what percentage of applications support live identity control.
- Prioritise integration for control-critical apps Start with applications that carry privileged access, regulated data, or high transaction volume.
What's in the full article
StackBob's full analysis covers the operational detail this post intentionally leaves for the source:
- The maturity ladder and the coverage logic behind each stage, including how reach changes the score.
- The practical case for extending governance to applications without SCIM, APIs, or standard connectors.
- The vendor's view of how no-code autonomous provisioning fits into the broader IGA coverage problem.
- The implementation framing for deciding when platform replacement is justified versus when integration is the real fix.
👉 Read StackBob's analysis of IGA maturity and application connectivity →
IGA maturity models and application connectivity: what teams miss?
Explore further
30/07/2026 10:56 pm
Application reach is the real maturity metric, not feature count. An organization can own governance workflows, roles, certifications, and lifecycle tooling while still controlling only a minority of its application estate. That is not a tooling problem in isolation, it is a coverage problem that invalidates maturity scoring based on capability checkboxes. Practitioners should reframe maturity around what is actually governable end to end.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
A question worth separating out:
Q: Should organisations replace their IGA platform when coverage is low?
A: Not by default. Low coverage is often an integration and application architecture problem, not proof that the platform itself is wrong. Replace the platform only when it is unsupported or structurally incapable of your environment. Otherwise, expand connectivity first and reassess after the estate is visible.
👉 Read our full editorial: Application connectivity is the real gap in IGA maturity
