TL;DR: Many identity integrations called “connected” only surface account data, while true governance requires provisioning, deprovisioning, entitlement changes, and verification that updates actually landed, according to READI. Read-only links produce reports, not control, so access can remain in place long after a review closes.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on READI's blog post: Identity governance integrations are often read-only, and visibility alone does not constitute governance.
Why it matters: IAM and IGA teams need to distinguish reporting feeds from control paths, because access reviews and joiner-mover-leaver processes only reduce risk when the integration can actually change access.
Context
Identity governance programs often blur two very different capabilities: seeing access and changing access. A connection that only pulls account and entitlement data can support reporting, but it cannot complete the governance loop if it cannot provision, modify, deprovision, and confirm the change in the target system. IAM and IGA basics set the governance baseline, but this distinction is where many programmes overstate coverage.
The practical gap is simple. If a connector cannot execute lifecycle changes, then access reviews generate tasks rather than outcomes, and the risk remains until someone performs the change manually. That makes the connection useful for visibility, but incomplete for governance.
The same issue appears when integration status is measured as a count rather than a capability profile. Two systems may both be marked connected, yet only one actually supports controlled access change. In governance terms, those are not equivalent states.
Key questions
Q: How do I tell whether an identity integration is actually governing access?
A: An integration is actually governing access when it can read the entitlement model, detect who has what, and write changes back to the target system. A true governance connector supports provisioning, deprovisioning, access reviews, or entitlement updates, not just reporting. If it only exports data, any remediation still depends on manual action.
Q: Why do read-only connectors create risk in identity governance?
A: Read-only connectors create risk because identity governance tools can see entitlements but cannot change them, so reviewers may approve access that stays in place after remediation. That leaves service accounts, API keys, or human accounts with stale rights. The usual failure mode is manual work after the review closes, which delays removal and weakens certification control.
Q: How should teams measure identity governance coverage beyond connector count?
A: Teams should measure coverage by the share of in-scope identities, applications, entitlements, and privileged roles that can be governed end to end. Count whether the connector can provision, deprovision, recertify, and apply SoD controls, not how many systems are connected. A smaller set of lifecycle-enforcing integrations is more meaningful than broad visibility alone.
Q: What should teams do when an application cannot support automated deprovisioning?
A: Use compensating controls when an application cannot support automated deprovisioning, such as disabling the account at the directory or SSO layer, removing group memberships, or revoking tokens and certificates. Then track the gap as an exception with manual offboarding steps and an owner. Without lifecycle enforcement, access removal remains dependent on human follow-up.
Technical breakdown
Why read-only connectors are not governance controls
A read-only connector aggregates identity data from a target application, usually accounts, entitlements, or status fields, and forwards that information to an IGA platform for review or reporting. That is useful for discovery and certification, but it stops short of governance because it does not alter the source system. In practice, the connector behaves like a telemetry feed. It can tell you that access exists, but it cannot remove standing privilege, correct entitlement drift, or confirm that a change was enforced. A governance connection needs both write capability and validation, otherwise it only documents the problem. See the NHI Lifecycle Management Guide.
Practical implication: Treat read-only integrations as visibility controls, not governance controls, and do not count them as coverage for lifecycle enforcement.
What true lifecycle connectivity must do
A governance-capable connector has to support the identity lifecycle end to end: create access when needed, adjust entitlements when roles change, remove access when the relationship ends, and verify that the target application reflected the change. Verification matters because a queued or failed instruction is not the same as a completed entitlement update. This is especially important in applications with idiosyncratic permission models, partial APIs, or brittle admin workflows. Without that final confirmation step, organizations may believe a certification was closed while the account or entitlement remains active.
Practical implication: Test provisioning, modification, and deprovisioning as separate outcomes, and require evidence that the target system actually changed.
Why connector count creates false confidence
Connector count is a weak measure of governance maturity because it rewards breadth of coverage rather than depth of control. A program can accumulate hundreds of integrations while still leaving the hardest applications in a manual queue, especially where the system supports viewing data more easily than changing it. That creates a misleading status view: the platform looks widely connected, but the organization still depends on tickets and manual follow-up to end access. In governance terms, that means the control surface is narrower than the inventory suggests, and the residual risk sits in the gap between review and action. See the IAM and IGA Basics.
Practical implication: Measure integrations by what they can change, not by how many systems they can list.
NHI Mgmt Group analysis
Connectivity is not governance unless it can change source access. The core governance failure is treating observation and enforcement as the same control. A system that only reads entitlements can support audit evidence, but it cannot close the loop on JML or access review outcomes. That means many programmes are certifying visibility rather than control, which leaves standing access in place until a person intervenes.
The metric problem is as damaging as the integration gap. When teams optimise for connector count, they often select the easiest integrations first and defer the applications that matter most operationally. The result is a coverage story that looks strong on a slide deck but weak in practice. The governance implication is that coverage must be defined by what the integration can do, not by whether it exists.
Access review without enforcement is administrative theatre. If a certification can surface inappropriate access but cannot remove it, then the review only generates downstream work. That breaks the basic governance assumption that review and remediation are part of one control loop. Practitioners should treat this as a lifecycle integrity issue, not a tooling preference.
Governance coverage is a capability spectrum, not a checkbox. The word “connected” hides the difference between read access, write access, and post-change verification. IAM and IGA basics provide the conceptual basis for that distinction, but the operational reality is whether an integration can provision, modify, deprovision, and prove the result. Programs that collapse those states into one label will keep overestimating their control surface.
Named concept: connected governance gap. This is the space between having visibility into access and having the ability to govern it at the source. The gap matters because it turns lifecycle controls into workflows that end in tickets rather than outcomes. Practitioners should use this concept to separate reporting integrations from true enforcement paths when assessing programme maturity.
From our research library:
- Nearly 60% of IT leaders cite restrictive cost and complexity as a weakness of legacy identity governance, according to the 2025 State of Identity Governance Report.
- Read next: NHI Lifecycle Management Guide
What this signals
Identity governance programmes should stop treating connectivity as a binary state. The real question is whether an integration can enforce entitlement change at the source, because visibility without enforcement leaves the lifecycle control incomplete.
The operational consequence is straightforward: certification and provisioning workflows only reduce risk when the system can act on the finding. When it cannot, the programme shifts work to tickets and manual administration, which is where access persistence survives.
Connected governance gap: This is the point where organisations mistake read access for control. Once teams separate observation from enforcement, they can prioritise the applications where source-side deprovisioning is still missing.
For practitioners
- Define connected coverage by capability Classify each integration as read-only, write-enabled, or lifecycle-enforcing, then remove read-only systems from any metric that implies governance coverage.
- Test deprovisioning as a real outcome Run a joiner-mover-leaver scenario against each critical connector and confirm the target system actually removed or changed the entitlement, not just that the task closed.
- Separate reporting from enforcement Use certification and dashboard feeds for discovery only, and require a different control path for access removal or entitlement modification.
- Audit high-risk applications first Prioritise applications that hold finance, HR, engineering, or regulated data because those systems create the highest cost when access change remains manual.
Key takeaways
- Many integrations marketed as connected still function only as reporting feeds, which means they cannot complete identity governance at the source.
- The control gap becomes visible when access reviews close but entitlement changes still depend on manual work.
- Programs that define coverage by enforcement capability, not connector count, are better positioned to reduce stale access and audit noise.
Related NHI Mgmt Group resources: IAM and IGA Basics · NHI Lifecycle Management Guide · Top 10 NHI Issues · Ultimate Guide to NHIs: Regulatory and Audit Perspectives
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack surface, NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Read-only connectors leave removal workflows incomplete, which is an offboarding failure for non-human access. |
| Recommendation — Map integrations that cannot revoke access to NHI-01 and separate them from true lifecycle enforcement. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is about enforcing entitlement change, not just observing it in reports. |
| Recommendation — Apply PR.AA-05 to ensure entitlements can be changed at source, not merely reviewed. | ||
| CIS Controls v8 | CIS-5 — Account Management | Governance-capable connectors must manage account lifecycle actions, not only inventory them. |
| Recommendation — Use CIS-5 to verify that account changes are executed and confirmed in each target application. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | If access cannot be removed or adjusted reliably, least privilege cannot be maintained over time. |
| Recommendation — Enforce AC-6 by requiring source-system entitlement changes when roles or access end. | ||
| ISO/IEC 27001:2022 | A.8.2 — Privileged Access Rights | The governance gap affects privileged accounts and their removal as much as ordinary access. |
| Recommendation — Control privileged access rights so deprovisioning is confirmed, not assumed. | ||
Key terms
- Connected Governance Gap: A connected governance gap is the difference between seeing an entitlement and being able to control it through the governance platform. It exists when an integration can report access but cannot provision, deprovision, or enforce review outcomes in the target system, leaving remediation manual and incomplete.
- Read-Only Integration: A read-only integration can observe data and activity without changing application behavior or user workflows. In security architecture, that means the connector can collect evidence, inspect content, and raise findings while avoiding control-plane impact, making it suitable for governance and monitoring use cases where non-disruptive visibility is required.
- Lifecycle-Enforcing Integration: A lifecycle-enforcing integration is a connector that can apply identity changes to a target system, not just read data from it. It supports joiner, mover, and leaver actions such as account creation, privilege changes, deprovisioning, and entitlement revocation, so governance decisions can be executed instead of tracked only as records.
- Access Review Remediation: Access review remediation is the follow-up action taken after an access review identifies excessive, stale, or inappropriate permissions. It includes removing, reducing, or reauthorizing access, then confirming the change was applied correctly so the review produces real risk reduction rather than documentation only.
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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on November 5, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org