Native connectors govern applications already supported by the IGA platform, while identity connectivity extends fulfilment and reconciliation into systems that sit outside that native coverage. The distinction is architectural: one is built in, the other is added to close reach gaps.
How native connectors differ from identity connectivity in practice
Native connectors are the platform’s built-in integrations for systems it already understands, so they typically offer the cleanest path for provisioning, reconciliation, and reporting. Identity connectivity is the extension layer you add when a target system is not covered natively, but still needs identity-driven fulfilment or state synchronisation. The key question is not “which is newer,” but “which path gives you the least fragile operational model for that system.”
That distinction matters because native coverage usually implies tighter product support, more predictable field mapping, and fewer custom dependencies to maintain. Identity connectivity may be perfectly valid, but it often introduces extra design, testing, and exception-handling work, especially where the target system has unusual APIs, limited data fields, or idiosyncratic lifecycle rules.
What changes in fulfilment and reconciliation when you move outside native coverage?
Once you leave native support, the identity platform no longer has the same level of first-class knowledge about the target system’s objects, attributes, and lifecycle events. Fulfilment may still work, but it depends on an added integration path that translates identity decisions into actions the external system can accept. Reconciliation becomes more sensitive too, because the platform must infer state from whatever signals the target can expose.
In a native connector, the implementation usually follows the product’s intended data model. In identity connectivity, you are often compensating for a gap between the platform’s canonical workflow and the external system’s actual interface. That does not make it inferior, but it does make ownership and testing more important, because the integration is now part of your control surface rather than just a standard feature.
For teams building out lifecycle discipline, NHI Lifecycle Management Guide is a useful reminder that provisioning, rotation, offboarding, and visibility become harder as integration paths get less native. The same operational logic applies whether the subject is human or non-human identity.
Which architectural trade-offs should practitioners watch most closely?
Native connectors usually win on supportability, because they reduce custom code and align better with the vendor’s tested behaviour. Identity connectivity usually wins on reach, because it allows you to bring in systems that would otherwise stay outside governance. The trade-off is broader coverage versus more integration complexity, and the balance changes depending on how critical the target system is.
If a system is business-critical, the real decision is whether identity connectivity can deliver the same control outcomes you expect from native support: reliable fulfilment, timely reconciliation, clear failure states, and enough observability to prove the integration is working. If it cannot, the gap is not just technical, it is operational and governance-related.
Identity Security Programme Guide is helpful here because it treats integration choice as part of the wider operating model, not just a connector decision. For coverage planning, it also helps to compare this design choice against the broader set of identity issues surfaced in Top 10 NHI Issues, especially around ownership, visibility, and excessive permissions.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | Connector choice affects account lifecycle coverage and oversight. |
| Recommendation — Prefer the integration path that reliably provisions, reviews, and removes accounts. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Identity connectivity often governs credential and lifecycle handling across systems. |
| AC-2 — Account Management | The topic is about how identities are extended and governed into connected systems. | |
| Recommendation — Manage identity-related credentials centrally and rotate them on schedule. Automate account creation, modification, and removal for all connected targets. | ||
| ISO/IEC 27001:2022 | A.5.18 — Access rights | The distinction affects how access is granted, reviewed, and withdrawn across systems. |
| A.8.2 — Privileged access rights | Connector choices can determine how privileged access is governed in external systems. | |
| Recommendation — Review and revoke access rights consistently across native and extended integrations. Restrict privileged access paths created through custom or non-native integrations. | ||
Practitioner Guidance
What to verify: Confirm whether the target system needs standard lifecycle actions only, or whether it also needs custom attribute handling, non-standard reconciliation, or exception workflow. If the second case applies, identity connectivity may be justified even when a native connector exists for a nearby but less complete use case.
Decision rule: Use the native connector when it covers the required control outcome with low operational overhead. Use identity connectivity when the system is outside native coverage and the added integration layer still allows you to meet provisioning, deprovisioning, and reconciliation requirements without creating an unmanaged custom dependency.
Common mistake: Teams often choose identity connectivity for reach, then treat it like a one-time implementation. In practice, it becomes an ongoing control dependency, so ownership, monitoring, and change testing need to be explicit from the start.
Practitioner takeaway: The architectural difference matters less than the control outcome: if the integration can still deliver accurate lifecycle state and visible exceptions, it can be a sound extension; if not, the gap is likely to surface later as drift, missed deprovisioning, or reconciliation failure.
Related resources from NHI Mgmt Group
- What is the difference between code scanning and runtime identity monitoring?
- What is the difference between privilege reduction and secret rotation?
- What is the difference between a rules-based secret scanner and a hybrid scanner?
- What is the difference between zero trust for users and zero trust for NHIs?