Custom connectors change IGA onboarding speed for application growth

At a glance

What this is: This is a blog post about reducing IGA integration friction through custom connectors, with the key finding that configuration-first connectors can bring applications under management faster while preserving a normalised identity data model.

Why it matters: It matters because IAM and IGA teams often lose governance coverage when onboarding drags, and connector design now influences how quickly human, NHI, and agent-linked applications can be brought into scope.

By the numbers:

• C1 says its platform includes 300+ out-of-the-box connectors for faster application onboarding.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• Only 5.7% of organisations have full visibility into their service accounts.

👉 Read ConductorOne's post on custom connectors and no-code integration

Context

Custom connectors are the mechanism that lets an identity platform ingest application data and provision access back into the service without forcing every integration into the same build path. For IAM and IGA teams, the governance gap is not just coverage, but the time it takes to turn an unmanaged application into something visible, reviewable, and controllable.

That matters because every new SaaS app, database, or internal service introduces a new identity shape, a new entitlement model, and a new lifecycle burden. When integration work becomes the bottleneck, application growth outpaces access governance, and organisations fall behind on onboarding, certification, and offboarding. The broader NHI lifecycle challenge is covered in the NHI Lifecycle Management Guide and the Ultimate Guide to NHIs.

Key questions

Q: How should teams bring unmanaged applications under IGA without long development cycles?

A: Use a connector strategy that separates transport from identity modelling. Standardise the objects you need to govern, such as users, groups, roles, entitlements, and grants, then use configuration where possible and code only where necessary. The goal is not faster sync alone, but faster movement from discovery to reviewable access control.

Q: What breaks when each application uses a different connector model?

A: Governance breaks because access data cannot be compared consistently across systems. If one application exposes teams, another exposes groups, and a third exposes roles without a shared abstraction, access reviews become fragmented and remediation is manual. A normalised model is what lets IGA treat different applications as part of one control plane.

Q: How do security teams know whether connector coverage is actually improving governance?

A: Coverage is working when new applications move into review, certification, and offboarding workflows quickly and stay there. If integrations increase but access data is incomplete, inconsistent, or hard to revoke, the programme has expanded surface area without expanding control. Measure governance by actionability, not connector count.

Q: Should organisations use no-code connectors or SDK-based integration for identity governance?

A: Use both, but for different reasons. No-code connectors are useful when the source system is straightforward and speed matters, while SDK-based connectors are better for homegrown or unusual systems that need deeper modelling. The deciding factor is whether the connector preserves lifecycle control, not whether it is technically simpler.

Technical breakdown

Connector normalisation and the identity data model

A connector does two jobs: it ingests objects from an external system and it provisions access back into that system. The hard part is not transport, but normalisation. Different applications call similar things by different names, such as users, accounts, teams, groups, roles, or memberships. A consistent model maps those differences into shared identity objects so governance logic can operate across SaaS apps, APIs, and databases. That is what makes cross-application lifecycle control possible. Without normalisation, each integration becomes a one-off governance island, which fragments visibility and slows down recertification.

Practical implication: define a canonical object model before scaling integrations, or every new application will create its own governance exception.

Baton SDK, traits, entitlements, and grants

A code-based connector framework typically breaks identity data into reusable traits, resource types, resources, entitlements, and grants. Traits describe the principal or asset, resource types map upstream objects into the model, resources represent individual instances, entitlements describe permissions, and grants record who or what has which permission on which resource. This structure matters because governance systems need relationships, not just inventories. The connector is therefore less about simple sync and more about preserving the access graph in a form that can be reviewed, certified, and actioned consistently.

Practical implication: if your IGA platform cannot preserve grants and entitlement relationships cleanly, access reviews will stay incomplete and remediation will remain manual.

No-code YAML connectors and lifecycle velocity

No-code connector configuration changes the operating model for onboarding. Instead of engineering every integration from scratch, teams can define resources, map fields, and pull from APIs or SQL sources using configuration. That lowers the threshold for bringing shadow applications into scope, especially where the target system is simple but numerous. The trade-off is governance discipline: configuration speed only helps if the mapped data is accurate, current, and tied to access workflows that can still enforce review, approval, and offboarding across the application estate.

Practical implication: use no-code connectors to expand coverage quickly, then validate data quality and entitlement mapping before putting the application into certification cycles.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Azure Key Vault privilege escalation exposure — Azure Key Vault Contributor role misconfiguration enabled privilege escalation.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Connector speed is now a governance control, not just an integration convenience. When onboarding takes months, application sprawl grows faster than certification coverage and offboarding discipline. The practical question is whether the identity programme can absorb new systems at the same rate the business adopts them. For practitioners, integration latency is a governance risk, not a technical nuisance.

Normalised entitlement graphs matter more than connector count. A large library of connectors is useful only if each one produces access data in a format that can be compared across systems. The problem identity teams face is not simply visibility, but equivalence: without a common model, users, groups, roles, and grants cannot be governed side by side. Practitioners should treat model consistency as a control requirement.

No-code onboarding changes who can bring applications under governance. YAML-driven connectors reduce dependence on specialist developers, which widens operational reach for IAM and IGA teams. That also increases the need for strong review over mapping logic, because fast integration without mapping discipline can create a false sense of control. The implication is that governance must cover configuration quality, not just application count.

Custom connectors expose the lifecycle gap between discovery and control. The ability to connect a system quickly does not automatically mean the associated identities are lifecycle-managed. Access still has to be reviewed, entitlement changes still have to be tracked, and dormant connections still have to be removed. Practitioners should read connector strategy as part of lifecycle governance, not as a separate engineering track.

From our research:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which explains why connector-driven discovery still matters for NHI governance.
• The next step is to pair connector coverage with lifecycle discipline, as outlined in the NHI Lifecycle Management Guide.

What this signals

Connector sprawl is becoming an identity governance design problem. When applications can be onboarded in hours instead of months, the limiting factor shifts from integration effort to the quality of the entitlement graph and the discipline of lifecycle control. Teams that treat connector strategy as plumbing will miss the real question, which is whether each new integration produces governable identity data or just more inventory.

The programme signal is clear: if an organisation cannot normalise access relationships across SaaS, API, and database sources, access review quality will erode even as coverage increases. That is why the combination of configuration-first integration and lifecycle governance is now a practical requirement for modern IGA, especially in environments trying to keep pace with hybrid application growth.

For practitioners

• Standardise the connector data model Define the minimum object set your IGA programme must preserve for every integration, including principals, resources, entitlements, and grants. Use that schema as the acceptance test for both SDK-built and YAML-built connectors so access reviews remain comparable across applications.
• Prioritise the highest-friction applications first Start with homegrown apps, back-office systems, and databases that have been outside governance because traditional connector development was too slow. These systems usually carry the biggest lifecycle blind spots and create the fastest governance gains when brought under management.
• Tie connector onboarding to lifecycle controls Make every new connector pass through access review, provisioning, and offboarding checks before it is treated as governed. If the connector can ingest data but cannot support entitlement change and revocation workflows, it should remain in limited use until those controls exist.
• Validate no-code mappings before scale-out Review YAML mappings and SQL extracts for field accuracy, object matching, and entitlement completeness before extending them to broad application sets. A fast connector that misrepresents access relationships creates governance debt faster than a slow one.

Key takeaways

• Custom connectors matter because integration speed now determines how quickly applications enter governance, not just how quickly they connect.
• A normalised data model is the difference between a connector that syncs data and a connector that enables review, certification, and revocation.
• No-code onboarding lowers friction, but lifecycle controls still decide whether the application is truly under management.

Key terms

• Connector: A connector is software that exchanges identity and access data with an external system. In IGA, it is the bridge that ingests users, groups, roles, and permissions while also pushing access changes back into the target application. Its value is measured by how well it preserves governance meaning, not just how well it syncs records.
• Normalised Data Model: A normalised data model maps different application-specific identity objects into a consistent structure. This lets governance teams compare access across SaaS apps, APIs, and databases without rebuilding policy logic for every system. For identity programmes, normalisation is what turns isolated integrations into a controllable control plane.
• 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.
• Lifecycle Control: Lifecycle control is the set of processes that govern access from onboarding through change and removal. In identity programmes, it ensures that provisioning, review, and offboarding stay aligned as applications and permissions evolve. A connector that cannot support lifecycle control may sync data, but it does not fully govern access.

Deepen your knowledge

Custom connectors, entitlement mapping, and lifecycle control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is trying to bring more applications under governance without adding integration bottlenecks, it is worth exploring.

This post draws on content published by ConductorOne: Custom Connectors: Simplifying Integrations Without Code. Read the original.