Notifications
Clear all
Topic starter
23/06/2026 9:11 pm
TL;DR: Custom connectors shift application onboarding from long development cycles to configuration-led integration, with Baton SDK for code-based builds and YAML for no-code mapping of users, groups, entitlements, and grants, according to ConductorOne. The governance change is not just speed: it is whether IGA can keep pace with application growth without weakening data normalisation or access review discipline.
NHIMG editorial — based on content published by ConductorOne: Custom Connectors: Simplifying Integrations Without Code
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.
Questions worth separating out
Q: How should teams bring unmanaged applications under IGA without long development cycles?
A: Use a connector strategy that separates transport from identity modelling.
Q: What breaks when each application uses a different connector model?
A: Governance breaks because access data cannot be compared consistently across systems.
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.
Practitioner guidance
- Standardise the connector data model Define the minimum object set your IGA programme must preserve for every integration, including principals, resources, entitlements, and grants.
- 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.
- Tie connector onboarding to lifecycle controls Make every new connector pass through access review, provisioning, and offboarding checks before it is treated as governed.
What's in the full article
ConductorOne's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step Baton SDK modelling for traits, resource types, resources, entitlements, and grants.
- YAML configuration patterns for no-code connector builds across API-backed services.
- SQL-based connector examples for applications without a native API.
- Deployment options for running connectors in cloud or customer-managed environments.
👉 Read ConductorOne's post on custom connectors and no-code integration →
Custom connectors for IGA: what changes when integration becomes configuration?
Explore further
25/06/2026 2:21 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Custom connectors change IGA onboarding speed for application growth
