A connector is the integration layer that lets an identity governance and administration platform read accounts, groups, and entitlements from an application and, when permitted, write changes back. In practice, the connector defines whether the governance programme can only observe a system or can also enforce access decisions inside it.
What an IGA connector does
An IGA connector is the integration layer between an identity governance platform and a target system. It lets the platform discover accounts, groups, roles, and entitlements, then sync changes back when the connector supports enforcement rather than read-only visibility.
That distinction matters because a connector is not just a data pipe. It determines whether governance can only observe access state or can also trigger provisioning, deprovisioning, and entitlement updates in the connected application.
How IGA connectors fit into governance workflows
Connectors sit at the boundary between governance policy and operational systems. They are the mechanism that makes access reviews, entitlement reconciliation, role cleanup, and joiner-mover-leaver processes real in downstream applications.
In a mature programme, the connector usually has to translate a generic governance action into whatever the target system understands, whether that is an API call, directory sync, file feed, or custom integration. That translation layer is where coverage, timing, and data fidelity are either preserved or lost.
Because connector scope varies by system, two applications may both be “integrated” while still behaving very differently. One may expose only identity data for certification; another may allow write-back for access removal, role assignment, or account lifecycle changes.
For a practical overview of how governance, entitlement discovery, and lifecycle processes fit together, IAM and IGA Basics provides the broader model that connectors plug into.
What connector coverage determines
Connector coverage determines how much of the application’s access state the IGA platform can actually see and control. If the connector cannot read nested groups, custom entitlements, or nonstandard roles, access reviews can miss meaningful privilege.
Coverage also affects lifecycle accuracy. If the connector cannot write changes back reliably, governance may approve a revocation or role change that never takes effect, leaving the system out of sync with policy.
Connector design therefore influences whether entitlement data is current, whether orphaned access is visible, and whether certifications are based on complete evidence. In practice, connector quality is often the difference between governance as a record-keeping exercise and governance as an enforced control.
When connector scope is a key buying or design question, IGA Buyer’s Guide is useful because it frames connectors as part of platform selection, not just implementation plumbing.
Common integration limits and failure modes
Connector failures usually show up as incomplete inventory, stale entitlements, delayed updates, or write-back exceptions. A system may appear “integrated” while the connector only supports a subset of objects, which creates blind spots in reviews and remediation.
Another common limitation is asymmetric capability. A connector may read deeply but write only a narrow set of attributes, or it may support provisioning but not deprovisioning. That asymmetry can leave the governance programme unable to complete the access action it approved.
Operationally, connectors also depend on stable schemas, permissions, and API behaviour in the target application. When those change without coordinated maintenance, sync jobs fail, certifications become less trustworthy, and access drift can accumulate.
Where connector gaps contribute to overexposure or stale access, the broader failure patterns are discussed in Top 10 NHI Issues and in Ultimate Guide to NHIs, Key Challenges and Risks, both of which cover visibility gaps and unmanaged access patterns.
Risk and Threat Considerations
IGA connectors create risk when the integration is partial, stale, or overtrusted. If a connector cannot accurately read or change entitlements, the governance programme may certify access that should have been removed or fail to detect privilege creep.
Failure mechanism: Incomplete object coverage, broken write-back, weak connector permissions, or schema drift can sever the link between policy decisions and actual system state.
Impact: The result is access that remains in place after it should have been removed, inaccurate audit evidence, and a wider window for misuse of excessive or orphaned privileges.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CSA Cloud Controls Matrix and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | IGA connectors operationalize identity governance across connected systems. |
| Recommendation — Map connector coverage to IAM controls and verify each target system supports required read and write operations. | ||
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Connectors support account lifecycle visibility and control enforcement. |
| IA-5 — Authenticator Management | Connector-integrated governance often manages credentials and related access material. | |
| AU-2 — Event Logging | Connector activity should be logged to support governance evidence and review. | |
| Recommendation — Use AC-2 to ensure connector-driven account changes are complete, timely, and traceable. Apply IA-5 to control credential-related lifecycle actions surfaced or enforced by the connector. Log connector actions and sync outcomes so governance evidence can be audited end to end. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Connectors enforce or observe application access decisions under access control policy. |
| Recommendation — Bind connector capabilities to access control policy and confirm they match approved enforcement scope. | ||
Practitioner Guidance
Why practitioners should care: Treat connector scope as a control boundary, not an implementation detail. The value of IGA depends on what the connector can reliably observe and enforce in each target application.
What to watch for: Pay close attention to systems with custom schemas, limited APIs, or manual exceptions, because those are the places where entitlement data and enforcement often diverge. A connector that is “working” but not complete can be more dangerous than no connector at all, because it creates false confidence.
For a practical guide to lifecycle coverage across provisioning, rotation, and offboarding, NHI Lifecycle Management Guide and Joiner-Mover-Leaver (JML) Guide are the most direct internal references for how connectors support state change across systems.