What is the difference between native integrations and custom connectors for access control?

Native integrations versus custom connectors in access control

Native integrations are the shortest path when a product already understands the target system’s authentication and entitlement model. Custom connectors are the fallback when the system does not fit that built-in pattern, but still exposes something governable, such as an API, SCIM endpoint, database, or access-control file. The practical difference is not philosophy, it is coverage, maintenance, and how much of the control plane you have to build yourself.

What native integrations usually give you

Native integrations are designed for the vendor’s supported sources, so they normally require less implementation effort and less ongoing upkeep. They are better when the target application exposes standard objects and workflows that map cleanly to the access-control product’s model, because onboarding, syncing, and policy enforcement are already pre-wired. That usually means faster deployment and fewer edge cases to troubleshoot.

They also tend to be the more stable option when the connector has direct product support for identity events, role changes, and access reviews. A foundational IAM and IGA guide helps frame why that matters: the less custom translation you need, the easier it is to keep entitlement data accurate over time.

When custom connectors are the better fit

Custom connectors matter when the application lives outside the product’s standard catalogue but still has a governable interface. That is common with internal platforms, legacy systems, line-of-business tools, and bespoke services where access is mediated through APIs, SCIM, direct database state, or file-based permission exports. In those cases, the connector is what turns an otherwise invisible system into something the access-control workflow can see.

The trade-off is that the connector becomes part of your control surface. You now own field mapping, error handling, polling or event timing, and the logic that decides whether the access model is authoritative enough for review and provisioning. If the integration is built poorly, governance can look complete while actually missing stale accounts, orphaned entitlements, or delayed revocation.

A guide to authorisation models is useful here because custom connectors often have to translate application-specific permissions into a reusable access-control model, not just copy raw data.

How to choose between them in practice

The decision is usually about fit, not preference. Use a native integration when it gives you the required coverage with less translation and better vendor support. Use a custom connector when the target system is important enough to govern, but too specialised to wait for native support. If the application holds sensitive access paths, the question is not whether the connector is elegant, but whether it can preserve least-privilege decisioning and reliable deprovisioning.

For many teams, the deciding factor is whether the system can supply trustworthy identity and permission data at the frequency your control process needs. If it cannot, a custom connector may still be better than leaving the system outside governance, but only if you can validate source-of-truth, sync cadence, and failure behaviour. That is where an IAM and IGA foundation and a clear authorisation model help prevent connector sprawl from becoming governance sprawl.

Risk and Threat Considerations

The main risk is false coverage: a team believes a system is governed because it is connected, but the connector only covers part of the permission surface or updates too slowly to protect revocation. Custom connectors also expand the attack and failure surface because they handle credentials, mappings, and sync logic that can be abused or broken.

Failure mechanism: A weak connector can miss permission drift, fail to map an access change correctly, or keep using stale secrets or tokens after the target system changes, which leaves excess access in place.

Impact: The result can be overprivilege, delayed deprovisioning, audit gaps, and, in the worst case, unnoticed persistence in systems that were assumed to be under control.

Practitioner Guidance

What to verify: Before trusting either model, verify what the integration actually covers, read access and write access paths separately, and confirm that revocation is enforced as reliably as provisioning. For custom connectors, confirm the source of truth for each attribute or entitlement field, because partial mappings are a common cause of silent governance gaps.

Decision rule: If the native connector already matches the system’s permission model and lifecycle events, prefer it for lower maintenance and lower operational risk. If it does not, build a custom connector only when you can test sync failure, reconciliation, and deprovisioning behaviour as part of the control design.

Practitioner takeaway: The best connector is the one that preserves governance fidelity, not the one that is easiest to launch. Coverage, revocation reliability, and operational clarity matter more than whether the connector is native or custom.

Related resources from NHI Mgmt Group

• What is the difference between native BI access controls and policy-based access control?
• What is the difference between relying on application-native authentication and using a network-based identity proxy for access control?
• What is the difference between native API enforcement and proxy-based privileged access control?
• What is the difference between secrets rotation and access control for non-human identities?