Why do read-only connectors create risk in identity governance?

Why read-only connectors become a governance control gap

Read-only connectors are useful for discovery, but they turn identity governance into an observational process when the platform cannot enforce the decision it records. That means the review result and the actual entitlement state can diverge. In practice, the review becomes evidence of intent, not evidence of remediation, especially when access spans human accounts, service principals, or shared credentials.

The core issue is that certification workflows often assume the system can close the loop after a reviewer flags access. With a read-only connector, the tool can detect what exists, but removal, role change, or secret rotation happens elsewhere. If that downstream work is not completed and verified, stale access persists after the campaign closes.

This is why the control gap is bigger than a connector limitation. It affects the integrity of the governance record itself, because an approved remediation may be logged without a completed state change. When entitlement data is not writeable, the organisation needs a separate, reliable enforcement path for revocation and a way to prove it happened.

How stale access persists after the review is closed

The failure mode is usually process drift, not a single technical defect. A reviewer marks an entitlement for removal, the ticket is created, and the governance report shows the item as handled, but the system of record still contains the right. That leaves service accounts, API keys, and human accounts with access that should have been removed.

In identity governance terms, this creates a delayed remediation window. The longer the gap between certification and removal, the more likely the access will be used, inherited, or forgotten. If the entitlement is tied to a long-lived secret, a stale API token, or a dormant account, the risk compounds because the entitlement can remain actionable long after the business owner believes it was cleaned up.

Operationally, read-only integration also weakens exception handling. Teams may assume the review process itself provides closure, but without a write-back or downstream enforcement workflow there is no automatic way to confirm deprovisioning, entitlement shrinkage, or secret invalidation.

What good remediation needs beyond visibility

Read-only connectors are not automatically bad, but they must be treated as observation-only inputs. If they are used in a certification programme, the organisation needs a separate remediation control that can update the target system, or at minimum a tightly governed workflow that validates execution after the review.

The important design choice is whether the connector is supporting discovery, or pretending to provide governance completion. When it only supports discovery, the control objective shifts to evidence quality, ticket closure discipline, and post-action verification. That is a weaker posture than closed-loop remediation, so it should be deliberate rather than accidental. For broader IAM and IGA design principles, see IAM and IGA Basics.

When connectors span service accounts or machine-held credentials, the remediation process must also account for where access is actually expressed. A single entitlement may be enforced through an application role, an API key, or a directory group, so the clean-up action has to match the control point rather than the review object.

Risk and Threat Considerations

Read-only connectors create a material risk of false closure: the governance tool records a decision, but the underlying access remains effective. That matters because stale rights are often the exact condition attackers and insiders exploit, especially when the access belongs to accounts that are rarely used and poorly monitored.

Failure mechanism: The certification workflow cannot execute or verify the entitlement change, so remediation depends on manual follow-up that may be delayed, incomplete, or dropped.

Impact: Organisations can retain active access after a review, which increases the chance of privilege creep, dormant account abuse, and untracked exposure across users, service accounts, and secrets.

Practitioner Guidance

What to verify: Do not trust a certification outcome until you can confirm the entitlement was actually removed or changed in the target system, not just marked for action in the governance tool. If the connector is read-only, require a second control that proves completion.

Decision rule: If the entitlement can grant production access, treat read-only governance as incomplete unless there is a tested downstream revocation workflow and a post-change reconciliation step. If those are missing, classify the review as advisory rather than remediating.

Common mistake: Teams often measure review completion instead of access removal. That creates a clean audit trail while leaving the real exposure untouched, which is exactly the condition that stale accounts and long-lived credentials exploit.

Practitioner takeaway: The real control is not the review event, it is the verified change in the target system. If the connector cannot enforce or confirm that change, the governance process must assume residual access remains until proven otherwise.

Related resources from NHI Mgmt Group

• Why do one-off connectors create governance risk in identity security?
• Why do SaaS connectors create identity governance risk after offboarding?
• When does a cloud identity platform create more governance risk than it reduces?
• Why does hybrid identity create extra NHI governance risk?