Application connectivity is the real gap in IGA maturity

At a glance

What this is: This is an analysis of why IGA maturity models fail when they score capabilities instead of application reach, and why connectivity is the real limiter.

Why it matters: It matters because IAM, IGA, and PAM teams can only govern applications they can connect to, so maturity claims, audit posture, and lifecycle controls are misleading when half the estate sits outside integration.

By the numbers:

• 63% of organizations are in the lowest two of five maturity stages, and only about 10% are in the top two.
• 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.

👉 Read StackBob's analysis of IGA maturity and application connectivity

Context

IGA maturity is often measured by whether an organization has a platform, review workflows, and joiner-mover-leaver processes, but those capabilities do not equal governance if the programme cannot connect to the applications being controlled. In identity security, reach is the difference between policy on paper and enforced state in the system, and the primary keyword here is IGA maturity.

The article argues that many programmes are scoring the tool rather than the estate, which leaves auditors and security leaders with a false sense of control. That framing is directly relevant to NHI governance as well, because unmanaged applications create the same exposure pattern as unmanaged service accounts: visibility exists in theory, but not in operational reality.

The practical question is no longer whether teams own an IGA platform. It is how much of the application estate can be governed end to end, including apps without SAML, OIDC, SCIM, or usable APIs.

Key questions

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. The best maturity indicator is whether the programme can read identity state, push changes, and reconcile entitlements across priority applications. If those actions still rely on spreadsheets or tickets, maturity is overstated.

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. A team may have workflows, roles, and certifications while still governing only a narrow slice of the environment. The gap appears when integration coverage is low and manual processing fills the rest.

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. Access can persist after business need ends, audit trails fragment, and incident response loses confidence in who still has access. The result is not only operational drag but a control gap that weakens the entire identity perimeter.

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.

Technical breakdown

Why application connectivity defines real IGA maturity

IGA maturity only becomes operational when the platform can read identity state from an application and write changes back into it. Inventory tells you the application exists, governance says it should be controlled, and connectivity determines whether access can be provisioned, reviewed, reconciled, or revoked. Without that final step, certification is detached from runtime reality and lifecycle processes become manual exceptions rather than controls. The technical problem is not the absence of policy. It is the absence of integration surfaces that make policy executable across the estate.

Practical implication: measure maturity by governed application coverage, not by feature adoption alone.

Why connector gaps create attestation theater

When an app has no SCIM, API, or connector, the IGA process often falls back to spreadsheets, exported user lists, and manual owner review. That produces attestation, not control, because reviewers certify a snapshot rather than the live entitlement state. The system may look covered in an audit trail, but the underlying accounts and privileges remain untouched. This is why governance without connectivity can satisfy process metrics while failing to reduce access risk.

Practical implication: identify applications where certification cannot trigger actual deprovisioning or entitlement change.

Why visibility platforms depend on coverage first

Identity visibility and intelligence layers depend on a sufficiently complete data plane. If the programme can only observe half the estate, any risk scoring, entitlement analytics, or remediation recommendation is based on partial identity context. That makes intelligence directional rather than trustworthy. In practice, advanced analytics do not replace connectivity, they inherit its limitations. The estate must be reachable before the programme can become actionable.

Practical implication: sequence analytics and visibility investments after you have validated coverage of priority applications.

NHI Mgmt Group analysis

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.

Attestation without connectivity is governance theatre. If reviewers are certifying exported lists because the system cannot query or update live state, the control outcome is paperwork, not enforcement. That failure mode matters across IAM and NHI programmes because any identity domain that cannot be reconciled back to source of truth will drift into unmanaged privilege.

Identity visibility and intelligence cannot compensate for an unreachable estate. Advanced analytics only become reliable when the underlying application coverage is broad enough to represent the environment honestly. A partial data plane yields partial truth, which is useful for direction but not sufficient for control decisions. The implication is that teams should stop treating intelligence as a substitute for integration coverage.

Connectivity debt: The real problem is not missing governance intent, but accumulated application debt where integration surfaces never existed or were never built. That debt forces manual control paths that scale poorly and distort maturity reporting. Once teams name the debt correctly, they can separate architectural reach from programme capability and stop buying another ceiling.

Platform replacement does not solve a reach problem. Swapping one IGA tool for another does not change the fact that the applications outside the connector model remain outside governance. That means the strategic question is less about replacing a platform and more about expanding the set of applications that identity controls can actually touch. Practitioners should align investment decisions to coverage expansion, not brand migration.

From our research:

• 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.
• For the governance gap behind this post, see Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs for how lifecycle control depends on coverage.

What this signals

Connectivity debt will become a board-level identity risk because maturity claims will increasingly be judged against enforceable coverage, not platform ownership. Teams that cannot show live control over priority applications will struggle to defend their programme posture in audit, procurement, and incident response.

The same logic applies to non-human identities: if only 5.7% of organisations have full visibility into their service accounts, partial governance is not a tolerable steady state but a measurable exposure. Identity teams should expect coverage reporting to become a more important management control than feature adoption.

For practitioners, the next step is to align governance priorities to the applications that can change entitlement state today, then use that baseline to decide whether analytics, workflow automation, or platform changes will actually improve control.

For practitioners

• Map governed application coverage Build a current-state inventory that separates applications into three groups: fully governable, partially governable, and unreachable. Use the split to show where access reviews, provisioning, and deprovisioning can actually execute versus where they remain manual. Focus first on the highest-risk business applications.
• Measure maturity by reach, not features Replace capability scorecards with a coverage metric that shows what percentage of applications support live identity control. Include whether the application can read identity state, accept entitlement updates, and support automated deprovisioning. This makes maturity observable instead of self-reported.
• Prioritise integration for control-critical apps Start with applications that carry privileged access, regulated data, or high transaction volume. For each one, define whether the gap is API access, SCIM support, or process ownership, then choose the least disruptive integration path. Use the Ultimate Guide to NHIs for the governance model behind visibility and lifecycle coverage.
• Stop certifying what you cannot enforce Where the platform cannot revoke access or reconcile entitlements, change the control design rather than pretending the review is complete. If you must use manual review, label it explicitly as interim and track it as technical debt. That prevents attestation from being mistaken for control.

Key takeaways

• IGA maturity is overstated when it measures capabilities instead of the applications those capabilities can actually reach.
• The biggest control gap is not feature absence but connectivity debt, which turns certification into attestation without enforcement.
• Practitioners should score programmes by governed coverage first, then decide whether additional automation or platform change is justified.

Key terms

• Application Connectivity: The integration layer that lets identity systems reach an application well enough to request, approve, certify, revoke, and monitor access. In identity governance, connectivity is not just transport. It is the difference between an application that can be controlled and one that remains outside the programme's operational reach.
• Attestation theatre: A control pattern where reviewers approve exported lists or static evidence because the live system cannot be reached. It creates the appearance of governance while leaving the underlying accounts, permissions, and lifecycle state unchanged.
• Connectivity debt: The accumulated gap between the applications an identity programme claims to govern and the applications it can actually integrate with. This debt creates manual work, weakens audit confidence, and blocks automation from producing real control.
• Governed coverage: The share of an application estate that can be controlled end to end through identity processes such as provisioning, certification, and deprovisioning. It is a more honest maturity indicator than feature count because it measures enforceable reach.

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.

👉 The full StackBob post explains the maturity ladder, the connector ceiling, and the coverage argument in more detail.

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.