Topic starter
06/09/2026 6:20 pm
TL;DR: Application onboarding still turns into a custom engineering effort in many IGA programmes, even though mature architectures should make it repeatable, configuration-driven, and scalable, according to Fischer Identity. The governance issue is not application count itself, but whether identity teams can absorb change without accumulating customer-owned technical debt.
Editorial analysis by NHI Mgmt Group, based on content published by Fischer Identity: “Application Onboarding Should Not Be the Bottleneck in Modern IGA”.
Key questions
Q: What breaks when application onboarding depends on custom IAM code?
A: Onboarding stops being repeatable and becomes limited by engineering capacity, testing cycles, and the maintenance burden of customer-owned code.
Q: Why does application onboarding create so much identity technical debt?
A: It creates technical debt when organisations solve every integration problem with bespoke connectors, scripts, and middleware instead of reusable configuration.
Q: How do you know if an IGA platform is actually reducing onboarding effort?
A: Look at what happens when the environment changes.
Practitioner guidance
- Define a repeatability benchmark for onboarding Measure whether a new application can be connected using existing configuration patterns, policies, and workflows without custom code or specialist developer intervention.
- Inventory where onboarding still depends on customer-owned code Map connectors, scripts, middleware, and app-specific workflows that must be maintained outside the platform so you can separate governance from engineering effort.
- Test post-go-live adaptability before the next change cycle Validate how the platform handles a replaced HR source, a new business unit, or a new application population without redesigning core identity logic.
Bottom line: Application onboarding in mature IGA should be repeatable and configuration-driven, not a bespoke engineering exercise that consumes developer capacity.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
06/09/2026 6:21 pm
Application onboarding is an architecture problem, not a staffing problem: when each new system requires custom code, the identity programme is scaling labour rather than governance. That creates a ceiling on onboarding velocity and a long tail of customer-owned maintenance. The discipline should measure whether a platform reduces the need for bespoke implementation, not whether it can eventually be made to work with enough engineering effort.
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: What should IAM teams prioritise: faster onboarding or lower maintenance?
A: They should prioritise repeatable onboarding that reduces long-term maintenance, because raw speed is not useful if every new integration becomes a permanent support burden. The better outcome is a platform that scales identity governance without scaling custom code or specialised developer reliance.
👉 Read our full editorial: Application onboarding should be routine in modern IGA