Because governance depends on complete and accurate connections to the systems that actually hold access rights. When key applications are excluded or custom-built connections take too long, audit reporting, entitlement oversight, and access decisions become incomplete. The result is a partial control plane, not a complete programme.
Why the gap is a governance failure, not just a connector problem
Identity governance only works when it can see the systems that actually grant, change, and remove access. If integrations are missing or fragile, the programme may still produce reports, campaigns, and approvals, but those outputs apply only to the connected subset. That creates the false appearance of control while the real entitlement state remains partly outside the governance plane.
In practice, the issue is not whether a platform can store policies or workflow requests. The issue is whether it can continuously reconcile identity records with the authoritative systems that hold the rights. When that reconciliation breaks, governance becomes conditional on the coverage of the connector layer, which is exactly where gaps tend to hide.
For teams building out IAM and IGA basics, the important distinction is that governance is only as complete as its system coverage. A tool can enforce process on paper while still missing the applications, directories, cloud services, or custom platforms that create the actual access posture.
How incomplete integration breaks access oversight
Disconnected applications usually fail in one of three ways. First, they never enter the catalogue, so access is simply invisible. Second, they enter late or through brittle custom work, so the access model is already stale by the time reviews happen. Third, they synchronise partially, which leaves roles, entitlements, or ownership records inconsistent across systems.
That matters because audit reporting, entitlement certification, and role cleanup all depend on trustworthy data. If one business application is absent, a reviewer may certify a user as clean even though that user still has standing access elsewhere. If a custom connector only handles some objects, the programme may miss privileged entitlements while still reporting a successful review cycle.
Coverage and lifecycle control need to move together, which is why IGA buyers should evaluate connector depth and application coverage as seriously as workflow features. A platform that cannot reach the systems with the highest privilege density will not give you reliable governance, even if the interface looks mature.
The same logic applies to review quality. If the governance layer cannot close the loop after a decision, the review becomes documentation rather than control. That is why access reviews and certification only remain meaningful when the underlying entitlement inventory is complete enough to support removal, not just attestation.
Why custom-built connectors become a control bottleneck
Custom integrations are often introduced to reach legacy or niche systems, but they tend to be expensive to build, slow to maintain, and easy to break during application change. Every custom path adds another place where schema changes, API limits, naming mismatches, or owner handoffs can interrupt synchronisation.
Once that happens, governance drifts into exception handling. Teams defer onboarding difficult systems, accept stale data for “temporary” reasons, or rely on manual reconciliation to cover what the connector cannot do. Over time, the programme starts to resemble a patchwork of partial controls instead of a single control plane.
This is also where an identity security programme needs clear ownership and integration priorities. The practical question is not whether a system can eventually be connected, but whether the integration path is reliable enough to support ongoing review, revocation, and evidence collection without creating permanent blind spots.
Risk and Threat Considerations
Integration gaps create a blind zone that can conceal excessive access, stale access, or unmanaged privileged accounts. That increases the chance of missed revocation, failed recertification, and inaccurate audit evidence, especially when high-impact systems are excluded or only partially synchronised.
Failure mechanism: Governance decisions are made from an incomplete entitlement dataset, while the real access state continues to change in systems that are not fully connected or not synchronising correctly.
Impact: Attackers or insiders can retain access longer than intended, reviewers can rubber-stamp incomplete campaigns, and the organisation can report control activity without actually reducing privilege exposure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Incomplete integrations prevent full account and entitlement oversight across systems. |
| AC-6 — Least Privilege | Missing connectors hide excessive access and make privilege reduction incomplete. | |
| AU-6 — Audit Review, Analysis, and Reporting | Audit reporting becomes partial when key applications are excluded or poorly synced. | |
| Recommendation — Scope account inventories to all authoritative systems and verify joiner, mover, leaver coverage. Continuously remove excess access from every connected and unconnected entitlement source. Validate audit evidence against complete entitlement coverage before relying on reports. | ||
| CIS Controls v8 | CIS-5 — Account Management | Connector gaps undermine inventory, review, and lifecycle control over accounts. |
| Recommendation — Centralise account lifecycle visibility across all systems that grant access. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Access control fails when governance cannot see or manage all granting systems. |
| Recommendation — Apply consistent access-control rules across every authoritative application and platform. | ||
Practitioner Guidance
What to prioritise: Start with the applications that hold the highest privilege, the most sensitive data, or the most frequent access changes. If a system can grant access but is not in the governance feed, treat that as a control gap, not a backlog item.
What to verify: Confirm that connector coverage includes the authoritative source of truth for each entitlement type, not just a downstream replica. The useful test is whether a deprovisioning action in the governance tool reliably removes the actual right in the target system.
Common mistake: Treating custom integrations as a permanent substitute for standard connectors. That usually shifts the cost from implementation into ongoing reconciliation, where the hidden operational burden and data quality risk become much harder to see.
Practitioner takeaway: Governance becomes unreliable the moment its visibility stops matching the real access surface, so connector completeness and sync quality are control requirements, not technical conveniences.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org