Notifications
Clear all
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.
NHIMG editorial — based on content published by Fischer Identity: Application Onboarding Should Not Be the Bottleneck in Modern IGA
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Map onboarding effort to architecture, not headcount Measure how much application onboarding depends on developer time, custom scripts, or professional services.
- 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.
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.
👉 Read Fischer Identity's analysis of why application onboarding should be routine in IGA →
Application onboarding in IGA: why is it still an engineering project?
Explore further
06/09/2026 6:21 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Application onboarding should be routine in modern IGA
