Why do large organisations struggle to onboard business applications into identity security workflows?

Why This Matters for Security Teams

Business applications are rarely uniform. Some expose SCIM, some rely on SAML or OIDC, many require custom APIs, and legacy systems often need manual mapping or brittle scripts. That variation turns onboarding into a control problem, not just a tooling problem. When apps are not brought into identity workflows consistently, access reviews, deprovisioning, and privilege reduction become partial at best.

This is why visibility and standardisation matter as much as connector coverage. NHI Mgmt Group’s Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into their service accounts, while 97% of NHIs carry excessive privileges. That combination creates onboarding friction and governance debt at the same time. NIST’s SP 800-53 Rev. 5 Security and Privacy Controls reinforces the need for consistent access control, but large estates still struggle to operationalise it across mixed application types. In practice, many security teams discover the mismatch only after an application has already accumulated unmanaged accounts and exception paths.

How It Works in Practice

Large organisations usually need a layered onboarding model. First, they classify each application by integration maturity: native directory integration, API-enabled provisioning, webhook-driven events, or manual fallback. That classification determines whether onboarding can be automated end to end or whether only partial governance is possible. Without that step, teams waste time chasing edge cases before they understand the integration surface.

Next, they standardise the identity mapping model. Business applications often store users, service accounts, and delegated permissions differently, so the onboarding workflow needs rules for translating source identities into application accounts, entitlements, and ownership records. The practical goal is not just to “connect the app,” but to make the app discoverable, reviewable, and revocable inside a repeatable control process. The Top 10 NHI Issues highlights why this matters: inconsistent handling of credentials and excessive privilege are common failure points once applications are in production.

• Use automated discovery to find applications before asking teams to onboard them manually.
• Assign a standard owner, integration type, and risk tier to each application.
• Map accounts, tokens, and service identities to a single governance record.
• Trigger access review, rotation, and revocation workflows from the same control plane.

Implementation guidance is evolving, but current best practice is to prioritise systems that support event-driven provisioning and policy-based approvals, rather than relying on one-off connector projects. For application identities and secrets, the onboarding process should also align with lifecycle controls described in the Ultimate Guide to NHIs. These controls tend to break down when a large organisation has dozens of inherited SaaS tools with no clear owner and no reliable API for provisioning or deprovisioning.

Common Variations and Edge Cases

Tighter onboarding controls often increase operational overhead, requiring organisations to balance speed against governance depth. That tradeoff becomes sharper in mergers, outsourced environments, and departments that purchase apps without central review. In those cases, the question is less about whether to automate and more about how much manual exception handling the identity team can tolerate.

There is no universal standard for app onboarding maturity yet. Some organisations only enforce discovery and ownership assignment for high-risk systems, while others require full lifecycle integration before an app can be approved for use. Both patterns can work, but the right choice depends on how much integration debt exists and how many application teams can support the same workflow. For organisations dealing with secrets sprawl or shadow integrations, the NHI lens becomes essential because business applications often mask service accounts, API keys, and delegated tokens behind a simple “app owner” label.

Current guidance suggests treating onboarding as a control gate, not an admin task. When the environment includes legacy finance systems, custom-built internal tools, or vendor-managed platforms with limited APIs, automation may only cover discovery and attestation at first. That is still valuable, but it should not be mistaken for complete governance. In large estates, the hardest failures usually appear where identity workflows stop at the directory boundary and never reach the actual application accounts.

Related resources from NHI Mgmt Group

• How should organisations implement policy-based access control in identity-centric security programmes?
• How should organisations secure privileged access, non-human identities, and secrets before an identity security conference or major programme rollout?
• How should healthcare organisations govern access to patient data across applications and privileged workflows?
• Why do organisations struggle to keep identity governance effective during rapid growth?