A connector library is the set of pre-built integrations an IGA platform uses to reach directories, applications, and identity stores. It defines practical governance coverage because systems outside that library may remain partially managed, manually reconciled, or entirely invisible to the governance process.
Expanded Definition
A connector library is the catalogue of pre-built integrations that an IGA platform uses to discover, sync, provision, deprovision, and reconcile identities across directories, applications, and identity stores. In NHI governance, it is best understood as an operational coverage boundary, not just a software feature set. The library determines which targets can be managed through policy-driven workflows and which remain dependent on manual administration or custom scripts.
Definitions vary across vendors because some describe connectors as simple API adapters while others include sync rules, attribute mappings, and lifecycle actions in the same term. That difference matters: a connector that can read accounts is not necessarily one that can disable them, rotate credentials, or validate entitlement drift. For governance programs, the relevant question is whether the library supports continuous control execution across the actual systems in scope, consistent with NIST Cybersecurity Framework 2.0 principles of asset visibility and control coverage.
The most common misapplication is treating a long connector list as proof of governance maturity, which occurs when organisations equate advertised compatibility with full lifecycle enforcement.
Examples and Use Cases
Implementing connector libraries rigorously often introduces coverage tradeoffs, requiring organisations to weigh broad system reach against connector maintenance, testing, and dependency risk.
- Connecting an IGA platform to Active Directory or Entra ID to import users, groups, and group memberships for access reviews.
- Using a SaaS connector to provision and deprovision accounts in line with joiner-mover-leaver workflows, while validating that revocation actually completes.
- Integrating with HR and ticketing systems so identity changes can be correlated with approved business events rather than isolated technical changes.
- Linking a cloud application that exposes SCIM or API-based administration to reduce manual account handling and improve auditability.
- Tracking connector gaps by comparing managed systems against the exposure patterns described in the Ultimate Guide to NHIs, especially where service accounts or API keys may remain outside standard workflows.
Connector strategy also benefits from standards-oriented design. When a target system exposes identity data in a consistent format, administrators can align the integration more closely with NIST Cybersecurity Framework 2.0 objectives for identification, protection, and response. In practice, the library should be assessed not only for quantity but for whether each connector supports the exact control action needed.
Why It Matters in NHI Security
Connector libraries directly shape whether non-human identities are visible enough to govern. If a service account, bot, or API key sits in a system without a working connector, that identity can evade inventory, access review, rotation, and offboarding controls. This is especially dangerous in environments where operational dependencies are distributed across SaaS tools, cloud workloads, and legacy directories. NHIMG research shows that only 5.7% of organisations have full visibility into their service accounts, a signal that connector coverage is often far weaker than teams assume, as reflected in the Ultimate Guide to NHIs.
In governance terms, incomplete connector coverage can leave privileged NHI activity outside review loops, weakening compensating controls such as recertification, segregation of duties checks, and automated deprovisioning. It also complicates incident response, because responders cannot reliably tell which accounts exist or whether a change request actually disabled access. That gap becomes critical when audit evidence is requested or when a compromised token must be revoked across multiple systems. Organisations typically encounter this consequence only after an audit exception, access-related incident, or failed deprovisioning event, at which point connector library gaps become operationally unavoidable to address.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Connector coverage determines whether NHIs can be inventoried and governed across systems. |
| NIST CSF 2.0 | ID.AM-1 | Asset management depends on discovering identity stores and applications through connectors. |
| NIST CSF 2.0 | PR.AC-4 | Connectors must enforce least privilege through provisioning and access review workflows. |
Map every connected system to NHI inventory coverage and close gaps where identities remain unmanaged.
Related resources from NHI Mgmt Group
- Should organisations use connector-less deployment for on-prem DSPM where possible?
- What do security teams get wrong about connector credentials in infrastructure automation?
- What breaks when a prototype pollution bug combines with a request-building library?
- How should teams decide when a library-only auth approach is no longer enough?
