TL;DR: C1.ai says custom connectors can shorten IGA onboarding from code-heavy projects to YAML-driven configuration or SDK-based builds, normalising users, groups, entitlements, and grants across SaaS apps, APIs, databases, and homegrown systems. The governance shift is not just faster integration: it is whether access reviews and application growth can stay aligned without sacrificing a consistent data model.
At a glance
What this is: This post explains how C1.ai positions custom connectors as a way to move IGA onboarding from code-heavy integration to configuration-led mapping with a consistent data model.
Why it matters: It matters because IAM and IGA teams need faster application onboarding without losing control over normalisation, access provisioning, or the quality of review data.
👉 Read C1.ai's guide to custom connectors and IGA onboarding speed
Context
The core governance problem is not connector syntax but onboarding latency. When every application requires bespoke development, organisations slow down the moment business growth adds new systems, new identities, and new entitlement models that must be governed.
In IGA programmes, connector design determines whether access data can be normalised consistently enough for provisioning and recertification. C1.ai frames custom connectors as a way to reduce that friction by supporting both SDK-based development and YAML-based configuration across SaaS applications, REST APIs, and databases.
Key questions
Q: How should teams balance speed and governance in application onboarding?
A: Teams should accelerate the repeatable parts of onboarding while keeping ownership, scope, and privilege decisions under governance review. Speed matters only if it expands control coverage without weakening the control boundary. The right balance is faster intake with explicit approval points for data access, service account permissions, and entitlement scope.
Q: When does connector speed become a governance problem?
A: It becomes a problem when onboarding delays leave applications outside review and provisioning workflows for too long. At that point, the issue is not just implementation cost, it is unmanaged access scope and stale governance coverage.
Q: What breaks when application-specific identity data is not normalized?
A: Provisioning and recertification lose consistency because the same access concept is represented differently across systems. One app may expose groups, another roles, and another projects, which makes governance decisions harder to compare and enforce.
Q: How do you decide between code-based and configuration-led connectors?
A: Choose code-based connectors for systems with complex logic, edge cases, or protocol handling needs, and use configuration-led connectors when the target model is stable enough to map without custom development.
Technical breakdown
What a connector has to normalise in IGA
A connector does two jobs: it ingests identity and access data from an external service, then provisions changes back into that service. The hard part is not transport, it is semantic normalisation. Different systems name the same concepts differently, so a connector has to map upstream objects such as teams, roles, or accounts into a shared model for users, groups, entitlements, and grants. Without that layer, access reviews and provisioning rules become application-specific exceptions instead of governed controls.
Practical implication: define the minimum canonical model your IGA platform must enforce before you onboard the next application.
How SDK-based connectors differ from configuration-led connectors
SDK-based connectors suit systems that need custom logic, rate limiting, pagination handling, or deeper control over edge cases. YAML-based connectors shift much of that work into configuration, where IT teams can describe resources and mappings without writing code. The architectural distinction matters because it changes who can build and maintain integrations, how quickly changes can be introduced, and how much engineering dependency sits between business growth and identity governance.
Practical implication: reserve code-based connectors for complex systems and use configuration-led connectors where the data model is stable.
Why data model consistency drives governance quality
IGA fails when integration speed outpaces data quality. If one application exposes groups, another exposes projects, and a third exposes ad hoc permissions, governance reports become difficult to compare and certifying access becomes inconsistent. A consistent model turns heterogeneous systems into a manageable estate, so lifecycle workflows, provisioning actions, and review campaigns can operate across applications rather than inside isolated silos. That consistency is what makes scale possible.
Practical implication: test whether connector mappings preserve identity and entitlement meaning across every target system, not just whether the sync succeeds.
NHI Mgmt Group analysis
Connector governance is now an IGA control plane issue, not a back-office integration task. The article shows that onboarding speed directly shapes how quickly applications can enter governance scope. When integrations are slow, organisations leave applications partially managed or unmanaged for too long, and that is a lifecycle risk as much as an implementation problem. The practitioner conclusion is that connector strategy belongs in identity architecture decisions, not in isolated engineering backlog management.
A consistent data model is the real control, not the connector format. Baton SDK and YAML are simply two ways to solve the same governance problem: making access data comparable across different systems. If users, groups, entitlements, and grants are mapped inconsistently, recertification and provisioning lose reliability even when the connector technically works. The practitioner conclusion is that model fidelity matters more than whether the integration is code-driven or configuration-driven.
Custom connectors expose the hidden cost of application growth. Every new system adds more than integration work; it adds review scope, entitlement variation, and lifecycle complexity. Teams that treat connector build time as the only metric will understate the governance burden created by slower onboarding. The practitioner conclusion is that application growth should be measured against the organisation's ability to normalise identity data at the same pace.
Configuration-led integration lowers the barrier to coverage, but it also shifts accountability. When non-developers can define connectors, the governance team must ensure mapping quality, entitlement semantics, and provisioning boundaries remain controlled. Faster onboarding does not remove the need for assurance, it moves assurance earlier in the lifecycle. The practitioner conclusion is that speed and control have to be designed together.
Named concept: identity normalisation velocity. This article is really about how quickly an IGA programme can convert a new application into governed identity data. That velocity determines whether access reviews stay current or become backlog management exercises. The practitioner conclusion is that connector architecture now functions as a measure of governance throughput.
What this signals
Identity normalisation velocity: connector strategy is becoming a practical measure of how quickly an IGA programme can absorb new applications without creating governance backlog. When that velocity is low, onboarding delays turn into delayed reviews, delayed provisioning, and delayed accountability.
Custom connectors also shift the operating model for IGA teams. The people defining mappings are no longer just developers, so governance teams need stronger validation of entitlement semantics, provisioning boundaries, and application-specific edge cases before integrations go live.
For practitioners
- Define a canonical connector data model Standardise how users, groups, entitlements, and grants are represented before onboarding new applications so every integration feeds the same governance logic.
- Separate complex integrations from configuration-led ones Use code-based builds only where custom logic, pagination, or rate limiting makes them necessary, and prefer configuration where mappings are stable.
- Measure onboarding latency as governance risk Track how long it takes to bring a new application into review and provisioning scope, then treat long delays as unmanaged identity exposure.
- Validate entitlement semantics during connector testing Confirm that mapped objects preserve meaning across systems, especially where one application uses teams, another uses roles, and a third uses project membership.
Key takeaways
- Custom connectors matter because application onboarding speed now directly affects how fast governance coverage can expand with the business.
- The central technical issue is not transport alone, but whether identity data can be normalised consistently across different application models.
- Teams need connector choices that balance configuration speed with enough control to preserve review quality and provisioning accuracy.
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 addresses the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Connector mapping errors can overstate or understate access scope across integrated applications. |
| Recommendation — Audit connector mappings so entitlement scope stays aligned with actual application permissions. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about governing how access data is represented and enforced across apps. |
| Recommendation — Use PR.AA-05 to keep application entitlements normalized and reviewable across the estate. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Connector-driven provisioning depends on lifecycle control over credentials and access artifacts. |
| Recommendation — Apply IA-5 governance to any connector flow that creates, updates, or removes access. | ||
| CIS Controls v8 | CIS-5 — Account Management | Fast onboarding still requires disciplined account and entitlement management across systems. |
| Recommendation — Use CIS-5 to standardize account lifecycle handling as new connectors bring applications into scope. | ||
Key terms
- Edge Normalization: Edge normalization converts data into a consistent structure near the source before central ingestion. It reduces parser dependency, limits protocol mismatch failures, and makes downstream analysis more predictable, especially when telemetry comes from mixed devices and hybrid environments.
- Entitlement: An entitlement is the permission set that defines what a non-human identity can do after it authenticates. It is usually expressed through roles, policies or access assignments, and unmanaged entitlements are a common reason machine identities become over-privileged over time.
- Grant: A grant is the relationship that shows which principal has which entitlement on which resource. It is the most governance-relevant unit of access because it connects identity, permission, and target system in one auditable record. Without reliable grants, access reviews become partial and remediation becomes guesswork.
- Access Review: A formal process for confirming whether access is still needed and justified. In IAM programs, the review becomes an evidence-bearing control when decisions are recorded, scoped correctly, and traceable to the right reviewer, application owner, or auditor.
What's in the full article
C1.ai's full post covers the implementation detail this analysis intentionally leaves for the source:
- How Baton SDK structures traits, resource types, resources, entitlements, and grants
- How YAML configuration maps users, groups, and projects without code
- How the connector behaves across cloud and self-hosted deployment options
- How C1.ai positions its 300+ out-of-the-box connectors alongside custom builds
👉 The full C1.ai post covers connector models, YAML examples, and Baton SDK details.
Deepen your knowledge
NHI governance, identity lifecycle management, and workload identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 7, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org