Application onboarding should be routine in modern IGA

At a glance

What this is: This is Fischer Identity's argument that application onboarding should be a routine IGA capability, not a bespoke engineering project, and that configuration-driven architecture is the key finding.

Why it matters: It matters because identity teams governing NHIs, human access, and future autonomous workflows all need onboarding patterns that scale with change instead of scaling custom code.

By the numbers:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, with 46% confirmed and 26% suspected.

👉 Read Fischer Identity's analysis of why application onboarding should be routine in IGA

Context

Application onboarding in identity governance should be a repeatable operational process, not a one-off software project. When every new system requires custom connectors, scripts, middleware, and regression testing, the IGA programme starts scaling labour instead of governance.

Fischer Identity argues that this problem is architectural, not just resourcing-related. The core issue is whether complexity lives in configuration and policy, or in customer-owned code that becomes technical debt every time the application landscape changes.

That distinction matters for modern identity programmes because the same onboarding discipline has to support human users, service accounts, APIs, and eventually autonomous systems without turning each integration into a separate engineering effort.

Key questions

Q: How should security teams reduce application onboarding backlog without weakening governance?

A: Start by ranking applications by business criticality, data sensitivity, and access risk, then automate discovery and connector setup for the highest-value targets first. Keep account correlation and human approval as mandatory checkpoints. Speed matters, but only when the organisation can prove that governed state is preserved as each application is added.

Q: Why does custom connector work create long-term IGA risk?

A: Custom connector work creates long-term risk because it turns every new application into software that must be built, tested, deployed, and maintained. That shifts the burden from governance operations to engineering capacity, and it makes future change expensive. Over time, the organisation inherits brittle integrations instead of a repeatable identity control model.

Q: What breaks when identity lifecycle management only automates onboarding?

A: Offboarding and role changes become the weak point, which leaves stale access, orphaned accounts, and entitlement drift in place after the business has moved on. Automation that stops at provisioning creates process speed without governance. The control must prove that access can be removed as reliably as it can be granted.

Q: What should teams evaluate before choosing an IGA platform?

A: Teams should evaluate whether the platform can absorb change after deployment without requiring customer-specific code. The key question is how well it handles new applications, new authoritative sources, and changing business rules while preserving governance continuity. That is the real test of architectural flexibility, not initial connector count.

Technical breakdown

Why custom onboarding turns IGA into a software development problem

Traditional IGA implementations often rely on custom connectors, scripts, workflow branches, and middleware to adapt each application. That approach works in the short term, but it makes every new system a mini software project with its own testing, deployment, and maintenance burden. The result is that identity governance capacity becomes tied to developer availability rather than policy maturity. In practice, the platform stops acting like a governance layer and starts behaving like a bespoke integration stack.

Practical implication: treat each onboarding workflow as a governance asset, not a code asset, so new applications do not require full engineering cycles.

Configuration-driven identity governance and lifecycle logic

Configuration-driven IGA pushes variation into policy, attributes, lifecycle rules, and reusable integration patterns. Instead of rebuilding logic for every application, the platform uses common provisioning and deprovisioning behaviour, access rules, and authoritative-source mappings to fit new systems into the existing control model. This matters because onboarding is not just account creation. It also includes entitlement discovery, joiner-mover-leaver handling, approvals, and reconciliation across hybrid estates.

Practical implication: standardise lifecycle logic and integration patterns so onboarding new systems becomes policy work rather than custom engineering.

What architectural flexibility means after go-live

A mature IGA platform is judged by how well it absorbs change after initial deployment. HR replacements, new business units, acquired populations, and shifting authoritative sources should not require redesigning the identity architecture. If the platform can adapt through configuration, it reduces technical debt and preserves service continuity. If it cannot, the organisation ends up paying repeatedly for the same implementation problem in different forms.

Practical implication: evaluate platforms on post-go-live change tolerance, not just initial connector coverage.

NHI Mgmt Group analysis

Application onboarding should be treated as an identity governance control surface, not a delivery project. The article is right to challenge the industry habit of rewarding sheer integration count. Once onboarding depends on customer-owned code, the control plane is no longer policy-led, it is developer-led. The practitioner conclusion is straightforward: if onboarding effort grows linearly with each application, the IGA architecture is already constraining governance scale.

Configuration beats customisation when identity programmes must survive organisational change. HR system replacement, M&A-driven population changes, and SaaS migration should be normal conditions for IGA, not exceptional events. A configuration-first model keeps business logic in the programme rather than in brittle implementation artefacts. The practitioner conclusion is to measure whether the platform can absorb source-system change without redesign.

Modern IGA should govern application 81 the same way it governed application 1. That is the named concept here: application onboarding debt, meaning the accumulating cost of every new integration that requires bespoke engineering. The industry mistake is assuming technical difficulty is inherent to the application, when often it is self-inflicted by platform design. The practitioner conclusion is to identify where onboarding friction is architectural rather than operational.

The same onboarding discipline now has to span human, NHI, and future autonomous identities. The article’s point about varied access models across hundreds of applications maps directly to identity lifecycle governance across actor types. Service accounts, APIs, and AI-driven workflows will only increase the pressure for repeatable onboarding. The practitioner conclusion is to favour identity architectures that can extend governance without multiplying custom code across actor classes.

From our research:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, with 46% confirmed and 26% suspected, according to The 2024 ESG Report: Managing Non-Human Identities.
• The average organisation believes more than 1 in 5 of their non-human identities are insufficiently secured, which reinforces how quickly unmanaged identity sprawl becomes operational risk.
• For a broader governance view, see Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs for the lifecycle controls that keep onboarding, rotation, and offboarding aligned.

What this signals

Application onboarding debt: the real issue is not how many applications a platform can connect, but whether each additional system increases the amount of custom work required to keep governance intact. That distinction is becoming more important as identity programmes span cloud apps, legacy systems, service accounts, and future autonomous workflows. The control objective is reusable lifecycle handling, not heroic implementation projects.

Organisations should now treat onboarding throughput as a leading indicator of identity programme maturity. If change still triggers redesign work, the platform is absorbing business complexity poorly, and the technical debt will eventually surface in slower governance, weaker consistency, and more exceptions.

The broader signal is that identity architecture is converging with lifecycle governance. As programmes mature, the winning pattern is not the platform that connects the most systems on day one, but the one that keeps working when the source landscape changes around it.

For practitioners

• Map onboarding effort to architecture, not headcount Measure how much application onboarding depends on developer time, custom scripts, or professional services. If each integration needs a separate build path, the programme is scaling labour instead of governance.
• Standardise lifecycle behaviour across application types Define common patterns for account creation, deprovisioning, entitlement aggregation, approvals, and reconciliation so new systems can inherit policy rather than receive bespoke logic.
• Test post-go-live adaptability before procurement Ask how the platform handles HR source changes, business-unit expansion, and application replacement without rewriting workflows or customer-owned code.
• Separate integration capability from governance ownership Require vendors to own connector development where extra capability is needed, so the customer programme remains focused on access policy and lifecycle control.

Key takeaways

• Application onboarding is a governance problem when every new integration requires custom engineering and customer-owned code.
• Configuration-driven architecture reduces identity technical debt by keeping lifecycle logic, policy, and integration patterns reusable.
• The strongest IGA platforms are measured by how cleanly they absorb change after go-live, not by connector count alone.

Key terms

• Application Onboarding Debt: The growing cost created when every new application requires bespoke identity engineering. It is a governance debt because the organisation pays for it repeatedly through testing, maintenance, and redesign instead of converting onboarding into a repeatable control pattern.
• Configuration-driven governance: Configuration-driven governance means identity policies, workflows, and approvals are expressed through platform settings and templates instead of bespoke code. That approach reduces upgrade risk and maintenance overhead, but only if the configuration remains aligned to business rules and audit requirements.
• Authoritative Source Change: A shift in the system that provides identity truth for a population, such as a new HR platform or directory. In mature IGA, this should be absorbed through controlled configuration, not treated as a full reimplementation of the identity programme.
• Lifecycle Logic: The set of rules that determines how identities are provisioned, changed, reviewed, and removed across systems. It matters because good IGA programmes express this logic once and reuse it across applications, rather than recreating it in each connector or workflow.

What's in the full article

Fischer Identity's full blog covers the operational detail this post intentionally leaves for the source:

• Specific examples of how configuration-driven onboarding replaces custom connector development in real deployments.
• The University of Virginia change-management sequence, including the move from multiple HR systems to Workday and later Oracle HCM.
• The article's full rationale for why application 81 should be treated as routine rather than exceptional.
• Additional product-context examples showing how the platform handles cloud, on-premises, hybrid, and legacy systems.

👉 The full Fischer Identity post covers the architecture argument, the UVA example, and the case for configuration-driven scale.

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.