Custom Connector

Expanded Definition

A custom connector is used when an identity platform must govern an application that does not expose a native integration. In practice, it becomes the translation layer between policy and application state, converting identity actions such as grant, revoke, disable, or enumerate into the target system’s API calls, SCIM operations, database updates, or file-based controls.

In NHI operations, the term usually applies to access orchestration, not to general-purpose application development. The connector may be read-only, write-enabled, or hybrid, and the design choice depends on whether the control objective is visibility, enforcement, or both. Definitions vary across vendors, but the operational standard is straightforward: the connector must reliably reflect the identity system’s view of entitlement state without creating shadow access paths. Guidance from the NIST Cybersecurity Framework 2.0 is relevant here because connector integrity supports governed access management and continuous monitoring.

The most common misapplication is treating a custom connector like a one-time integration script, which occurs when teams skip lifecycle handling, error recovery, and revocation logic.

Examples and Use Cases

Implementing custom connectors rigorously often introduces maintenance overhead, requiring organisations to weigh faster coverage of legacy systems against the cost of keeping the integration stable as target applications change.

• Connecting an identity platform to a legacy SaaS app that exposes only a limited REST API for creating and disabling accounts.
• Using a connector to read group membership from a SCIM endpoint and reconcile it with entitlement policy after a role change.
• Writing to a database-backed access table for an internal application that has no external provisioning interface.
• Polling a file-based control list to synchronize access decisions for an operational system that cannot support real-time APIs.
• Extending governance to hard-to-reach systems identified in the Ultimate Guide to NHIs, especially where service accounts and API keys outnumber human identities at scale.

For implementations that use standards-based provisioning, the connector should align with the semantics of NIST Cybersecurity Framework 2.0 functions such as govern, protect, and detect, so the integration remains auditable and not merely functional.

Why It Matters in NHI Security

Custom connectors are often the difference between a governed NHI estate and a fragmented one. When they are missing, brittle, or misconfigured, access changes can stall, leaving orphaned permissions, stale service accounts, and unresolved revocation requests. That is especially dangerous in environments where secrets and service identities already create large exposure surfaces. NHI Mgmt Group reports that only 5.7% of organisations have full visibility into their service accounts, and 79% have experienced secrets leaks, with 77% of those incidents causing tangible damage, according to the Ultimate Guide to NHIs.

From a governance perspective, custom connectors help close the gap between policy intent and application reality. They support deprovisioning, entitlement review, and lifecycle enforcement across systems that would otherwise remain outside central control. This matters even more in zero trust programs, where standing access is supposed to shrink rather than persist. The NIST Cybersecurity Framework 2.0 reinforces the need for managed, observable access pathways rather than ad hoc exceptions.

Organisations typically encounter the true importance of custom connectors only after an access review, breach investigation, or failed offboarding exposes accounts that could not be touched through native controls, at which point the connector becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• When should organisations prefer standards over custom implementations?
• Should organisations use connector-less deployment for on-prem DSPM where possible?
• When do custom IAM roles become a governance problem?
• How should security teams choose between basic, predefined, and custom GCP IAM roles?