Topic starter
24/07/2026 4:09 pm
TL;DR: More than 80% of enterprise applications remain ungoverned because onboarding into identity governance platforms is slow, costly, and inconsistent, according to Saviynt. The real shift is that onboarding backlog becomes a governance design problem, not a staffing problem, while its Terraform provider turns governance configuration into declarative code with versioning, review, and promotion.
Editorial analysis by NHI Mgmt Group, based on content published by Saviynt: “Onboarding as Code: How Saviynt's Terraform Provider Solves Identity Governance's Hardest Problem”.
By the numbers:
- More than 80% of enterprise applications remain ungoverned because onboarding into governance platforms is too slow and expensive.
- At 3–4 weeks per application and 500 applications to govern, the work can stretch into decades.
- Teams can move from 2–3 applications per month to 30–50 when common integration patterns are reusable.
Key questions
Q: What breaks when application onboarding into IGA is still manual?
A: Manual onboarding breaks coverage, consistency, and auditability at the same time.
Q: Why does onboarding as code reduce governance risk in IGA programmes?
A: Because it turns governance state into versioned configuration instead of hidden admin work.
Q: How do teams know whether their IGA onboarding model is actually working?
A: Look for whether new applications can be governed without bespoke configuration, whether changes are traceable through approval history, and whether environment promotion happens without manual rework.
Practitioner guidance
- Define onboarding as a governed deployment pipeline Treat each new application integration as code, with pull requests, approval workflows, and rollback paths for governance settings, entitlements, and provisioning rules.
- Standardise common integration patterns Build reusable modules for the application types you see most often, such as directory, database, API, SCIM, and LDAP patterns, so each onboarding does not restart from zero.
- Separate application and identity workstreams Let application teams define schema and connectivity while identity teams define governance and compliance controls, then converge them at deployment time.
Bottom line: Manual application onboarding in IGA creates a structural coverage gap that leaves many systems outside formal governance.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
24/07/2026 4:13 pm
Onboarding backlog is a governance design failure, not an administrative inconvenience. When more than 80% of applications remain ungoverned, the control problem is coverage, not intent. Manual onboarding makes identity governance depend on scarce human coordination, which means the programme will always lose to the growth rate of the application estate. The practical conclusion is that governance architecture has to be judged by throughput, not policy language.
A few things that frame the scale:
- Nearly 60% of IT leaders cite restrictive cost and complexity as a weakness of legacy identity governance, according to the 2025 State of Identity Governance Report.
A question worth separating out:
Q: Should identity teams standardise onboarding modules before expanding coverage?
A: Yes, when the application estate contains repeated patterns that can be normalised. Standard modules reduce per-application variance, which makes scale possible and lowers the cost of bringing the next system under governance. Without that reuse, coverage growth usually stalls after the easiest integrations are done.
👉 Read our full editorial: Onboarding as code changes the economics of IGA governance