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.
At a glance
What this is: This is a Fischer Identity analysis arguing that application onboarding in modern IGA should be routine, repeatable, and driven by configuration rather than custom engineering.
Why it matters: For IAM and IGA practitioners, the issue is whether onboarding scale is constrained by architecture or by developer labour, because that determines how well the programme can absorb change without accumulating technical debt.
Context
Application onboarding in IGA is the process of connecting a new business system to identity governance so accounts, entitlements, provisioning, deprovisioning, and lifecycle rules can be managed consistently. Fischer Identity argues that this should be routine in mature environments, not a bespoke engineering effort every time a new application appears.
The governance gap is architectural, not operational. When onboarding depends on customer-owned code, scripts, middleware, and repeated regression work, the identity programme scales with labour instead of with policy and configuration. That creates technical debt that persists long after go-live.
The article uses higher-education and healthcare examples to show that large identity environments keep changing after deployment, which means the platform must absorb authoritative-source changes, application replacement, and new populations without being rebuilt.
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. That slows governance coverage, increases technical debt, and makes each new application a mini implementation project instead of a routine identity operation.
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. The debt shows up later as fragile change management, difficult upgrades, and long-term support costs that outlive the original onboarding effort.
Q: How do you know if an IGA platform is actually reducing onboarding effort?
A: Look at what happens when the environment changes. If a new HR source, new business unit, or application replacement can be absorbed without redesigning workflows or rewriting integrations, the platform is reducing effort. If each change triggers engineering work, it is not.
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.
Technical breakdown
Why custom onboarding becomes the default in legacy IAM
Older IAM environments often treated each application as a special case. Custom connectors, scripts, middleware, and app-specific workflows were used to bridge gaps between systems, but that approach made every new integration depend on engineering capacity. Over time, organisations confused implementation complexity with architectural necessity. The result is a fragile operating model where onboarding speed is limited by how much bespoke code the team can absorb and maintain, not by how many systems the business needs to govern.
Practical implication: Practitioners should separate genuine application complexity from unnecessary implementation complexity before adding another custom integration.
Why configuration-driven IGA changes the onboarding model
A configuration-driven IGA platform shifts complexity into policy, workflow, attributes, lifecycle logic, and reusable integrations. In that model, onboarding means defining authoritative sources, entitlements, provisioning rules, and governance controls inside the platform rather than building a new code path for each application. The architectural difference matters because it determines whether onboarding is a repeatable identity operation or a software development project disguised as governance.
Practical implication: Identity teams should favour platforms that express onboarding through configuration and reusable patterns instead of customer-owned code.
What happens when the authoritative-source landscape changes
The most revealing test of an IGA architecture is how it behaves after go-live. Organisations replace HR systems, add authoritative sources, acquire companies, and move applications to SaaS, so onboarding is really about adapting to constant change. If each change forces a redesign of core identity logic, the platform has not eliminated complexity. It has merely postponed it. Flexible architectures should absorb source-system churn without disrupting governed populations or requiring a rebuild.
Practical implication: Teams should evaluate whether their IGA design can adapt to source changes without rewriting workflows or reengineering the integration stack.
NHI Mgmt Group analysis
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.
Configuration-driven onboarding is the dividing line between governance and development: if entitlements, lifecycle rules, and provisioning logic live in reusable policy and workflow, application change becomes operational. If those controls live in scripts and middleware, every new system expands technical debt and weakens the programme’s ability to adapt. Practitioners should treat that difference as a core architecture decision, not a deployment preference.
Identity platforms must be judged on post-go-live change absorption: the real question is whether the environment can absorb new authoritative sources, application replacements, and population changes without reconstruction. That is the point at which many IAM programmes expose hidden fragility. The best indicator of maturity is not initial connectivity, but whether application 81 is still routine.
Customer-owned connector code is a governance liability: it shifts identity ownership into assets the business did not intend to operate. That model makes support, change control, and lifecycle maintenance harder over time, especially when the application landscape keeps moving. A mature IGA programme should keep the organisation focused on governing identities, not maintaining integration code.
Application onboarding should be measured by repeatability, not heroics: celebrating the ability to connect dozens of applications can hide the fact that each one required one-off effort. A better benchmark is whether the platform can accommodate repeated onboarding without expanding the implementation team at the same rate. That is the operational test practitioners should apply when evaluating IGA architecture.
From our research library:
- 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.
What this signals
Identity onboarding maturity is revealed after the first implementation wave: the real programme risk is not whether one or two applications can be connected, but whether the architecture still behaves predictably as source systems, business units, and populations change. Teams should benchmark their own environments on post-go-live adaptability, not first-pass delivery.
Application onboarding should be a governance function, not a software project: when identity teams own policy and lifecycle logic while the platform absorbs integration change, the programme becomes easier to sustain. That is the operating model practitioners should aim for if they want scale without perpetual technical debt.
For practitioners
- 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.
- Shift onboarding ownership back to identity governance Make sure the IAM team controls policy, entitlement mapping, and lifecycle rules, while engineering support stays limited to truly exceptional integration cases.
Key takeaways
- Application onboarding in mature IGA should be repeatable and configuration-driven, not a bespoke engineering exercise that consumes developer capacity.
- The main architectural risk is customer-owned technical debt, which grows when connectors, scripts, and middleware become the default way to absorb change.
- Practitioners should judge IGA platforms by how well they handle post-go-live source changes and application churn without rebuilding identity logic.
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 |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Application onboarding in IGA governs entitlements, provisioning, and lifecycle access. |
| Recommendation — Use PR.AA-05 to keep onboarding tied to governed entitlements rather than one-off integrations. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The article focuses on lifecycle governance for application access and account setup. |
| Recommendation — Apply IA-5 to ensure application onboarding is governed through managed account and credential processes. | ||
| CIS Controls v8 | CIS-5 — Account Management | Onboarding and offboarding application accounts is the core operational concern in the article. |
| Recommendation — Use CIS-5 to standardise account provisioning, deprovisioning, and ownership across onboarding flows. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | The article repeatedly ties onboarding quality to lifecycle changes and future offboarding readiness for applications and accounts. |
| Recommendation — Treat onboarding design as part of the identity lifecycle so offboarding remains configurable and auditable. | ||
Key terms
- Application Onboarding Management: Application Onboarding Management is the workflow used to register new applications into an identity or governance platform with the right controls from the start. It helps teams collect basic application data, apply standard settings, and extend identity features later without rebuilding the onboarding process.
- Configuration-Driven Infrastructure: Configuration-driven infrastructure is a cloud operating model where systems are created and changed through code and automation rather than manual server administration. This approach improves speed, but it also requires security teams to embed policy checks, vulnerability scanning, and approval logic into deployment workflows.
- Customer-Owned Technical Debt: Customer-owned technical debt is the long-term maintenance burden created when the organisation must support bespoke code, scripts, or middleware to keep identity controls working. In IGA, it often appears after onboarding shortcuts that solve the immediate problem but make future change expensive and fragile.
- Authoritative Data Source: A trusted source used to confirm identity attributes, such as a government database or regulated banking record. These sources reduce reliance on self-reported information and improve confidence in onboarding decisions. The quality of the verification outcome depends heavily on source coverage, freshness, and whether the data can be matched reliably.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle 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 September 6, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org