By NHI Mgmt Group Editorial TeamBased on StackBob: “You Can't Govern What You Can't Connect” (July 27, 2026)

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.


At a glance

What this is: This analysis argues that IGA maturity is constrained less by feature depth than by application connectivity, so many programmes govern only a fraction of their estate.

Why it matters: For IAM and IGA teams, the real risk is mistaking policy coverage for enforceable control when disconnected applications remain outside effective governance.


Context

Application connectivity is the practical boundary between identity governance on paper and identity governance that can actually change account state, entitlements, and access decisions. If an IGA platform cannot reach the application, certification and provisioning become records of intent rather than enforceable controls, which inflates maturity scores and obscures control gaps.

This article frames the problem as a governance coverage issue rather than a feature shortage. The central question for identity teams is not whether they own an IGA platform, but whether the platform can read and write identity state across enough of the application estate to make reviews, deprovisioning, and reconciliation meaningful.


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 mature IGA programmes still leave major gaps in access governance?

A: Because governance capability and application connectivity are different controls. A team can have workflows, certifications, and JML processes in place while still depending on manual handling for disconnected applications. In those cases, the programme governs intent, but not the live access state that determines actual risk.

Q: What breaks when an IGA platform has no discovery layer for unconnected applications?

A: Without discovery, governance only covers the apps already in the system of record. That leaves shadow IT, team-purchased tools, and unconnected applications outside provisioning, certification, and remediation workflows. The result is incomplete visibility, weaker role mining, and a false sense of control because the most relevant risks often sit in the apps the platform never learns about.

Q: Should teams replace their IGA platform or fix connectivity first?

A: Fix connectivity first unless the platform is truly end-of-life or incompatible with the architecture. Replacing the tool does not remove application constraints such as missing APIs, SCIM, or connector support, so the same coverage ceiling often returns in a new product wrapper.


Technical breakdown

Inventory, governance, and connectivity are not the same thing

Inventory tells you an application exists, governance says it is supposed to be controlled, and connectivity determines whether the identity system can actually act on it. An app can sit on a certification list, have an owner, and still remain operationally outside IGA if there is no connector, API, SCIM path, or other mechanism to read and write state. That distinction matters because many maturity models collapse these states into one score. When they do, they measure process paperwork rather than executable control.

Practical implication: Treat connectivity as a separate maturity dimension, not a subfeature of governance.

Why disconnected applications create attestation theater

When reviewers certify access against exported lists, they are validating a snapshot, not current system state. That means revocation, entitlement cleanup, and joiner-mover-leaver outcomes can all look complete in the governance tool while the application itself remains unchanged. This is the classic failure mode of indirect governance: the control exists in the workflow, but not at the point where access is enforced. The result is policy compliance without operational effect.

Practical implication: Require evidence that reviews and deprovisioning touch live application state, not stale exports.

Connector limits are architectural, not just procurement problems

The article’s deeper point is that connector scarcity reflects the architecture of many legacy and long-tail applications, especially where SAML, OIDC, or SCIM are absent and custom integration is slow. Replacing the IGA platform does not remove those constraints if the application estate remains the same. The issue is therefore not just vendor selection, but how the programme handles the long tail of apps that resist standard integration. Mature governance depends on reach, not rebranding.

Practical implication: Map the application long tail and design a coverage strategy before deciding whether platform replacement is justified.


NHI Mgmt Group analysis

Application connectivity is the real maturity control, not feature breadth. An IGA programme can own certification, workflows, and JML processes and still govern only a subset of the estate if it cannot reach the applications themselves. That means maturity scores based on capability inventories systematically overstate real control. For identity leaders, the practical conclusion is that coverage must be measured as an operational control surface, not as a software checklist.

Disconnected applications create a governance blind spot that looks compliant until execution time. If access reviews and deprovisioning happen against exported data, the programme is certifying stale state rather than live entitlements. This is why the gap is not cosmetic: the control exists in policy form, but the application remains outside effective governance. Practitioners should treat uncoupled apps as a different risk class, not as partially mature controls.

Attestation theater is the right name for maturity without reach. The article captures a common failure mode in which teams can point to owners, review schedules, and platform features while still relying on manual work for the long tail of applications. That is a structural mismatch between governance ambition and integration reality. The implication is simple: if the platform cannot touch the app, the maturity model should not award the same credit.

Connectivity debt explains why many identity programmes stall at the same ceiling. The long tail of applications creates an estate-level constraint that procurement alone does not solve, because the missing piece is the ability to execute identity decisions across diverse systems. This is why platform replacement so often disappoints when the underlying integration challenge remains. Identity teams should frame the problem as coverage debt, not tool dissatisfaction.

Application reach gap: Maturity models that ignore whether identity decisions can be executed across the application estate produce false confidence. The article’s core contribution is to reframe IGA maturity as an execution problem, where governance quality depends on how much of the environment is actually reachable. Teams that ignore that distinction will continue to score their programmes higher than their control reality warrants.

From our research library:

What this signals

Application reach gap: Many identity programmes are being measured on platform ownership while the real control issue is whether decisions can be executed across the application estate. That distinction will matter more as organisations add visibility layers on top of partial coverage, because intelligence built on incomplete reach is still incomplete.

Identity leaders should expect maturity conversations to shift from feature checklists to enforceable coverage. The programmes that can prove live connectivity, not just policy assignment, will be the ones that can defend their governance claims under audit and operational scrutiny.


For practitioners

  • Map governance coverage separately from tool ownership Create an application-by-application view that distinguishes inventory, policy inclusion, and live connectivity so you can see where governance is only nominal.
  • Prioritise the long tail of hard-to-connect apps Identify the applications that still require manual exports, ticketing, or spreadsheet-based reviews and assign them a remediation track based on risk and business criticality.
  • Validate that reviews touch live entitlement state Check whether certification, provisioning, and deprovisioning outcomes are written back to the source application instead of stopping at the governance workflow.
  • Separate platform selection from coverage remediation Assess whether the constraint is missing integration capability, poor data quality, or a genuine platform limitation before considering a replacement programme.

Key takeaways

  • The core problem is not missing governance features, but limited application reach, which means many IGA programmes control only part of their estate.
  • When governance depends on exported lists and manual handling, certification can look complete while live access state remains unchanged.
  • The most useful maturity question is whether identity decisions can be executed in the source application, not whether the platform has another workflow feature.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK addresses the attack and risk surface, while CSA Cloud Controls Matrix, NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
CSA Cloud Controls MatrixIAM — Identity and Access ManagementApplication connectivity determines whether cloud identity controls can be enforced across the estate.
Recommendation — Use IAM coverage checks to confirm every governed application has a live integration path.
NIST CSF 2.0PR.AA-05 — Access Permissions, Entitlements and AuthorizationsThe article is about whether access permissions can actually be governed and enforced.
Recommendation — Validate that entitlement reviews and changes reach the source application, not just the IGA workflow.
CIS Controls v8CIS-5 — Account ManagementDisconnected applications undermine account lifecycle control and deprovisioning accuracy.
Recommendation — Track account lifecycle coverage across all applications and close manual exceptions first.
MITRE ATT&CKTA0004;TA0006;TA0008 — Privilege Escalation; Credential Access; Lateral MovementWeak application governance expands opportunities for credential misuse and privilege abuse.
Recommendation — Map unmanaged application access paths to privilege escalation, credential access, and lateral movement risk.
NIST SP 800-53 Rev 5AC-6 — Least PrivilegeLeast privilege fails when the identity system cannot enforce changes inside the application.
Recommendation — Apply least-privilege controls only where the platform can verify and enforce entitlement changes.

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.
  • 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.
  • 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.

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.
NHIMG Editorial Note
Published by the NHIMG editorial team on July 28, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org