Notifications
Clear all
Topic starter
24/06/2026 10:41 pm
TL;DR: Fewer than 7% of roughly 10,000 applications support SCIM, leaving most enterprise apps outside automated provisioning, deprovisioning, and access governance workflows, according to Cerby. That app gap turns identity lifecycle management into manual work, with orphaned accounts, delayed removals, and fragmented audit trails becoming structural rather than exceptional.
NHIMG editorial — based on content published by Cerby: disconnected apps and the limits of identity lifecycle automation
By the numbers:
- 7% support SCIM (System for Cross-Domain Identity Management)., anagement).
- When 80% of an application portfolio is not connected to an IdP or IGA solution’s governance or provisioning workflows, lifecycle risk compounds quickly.
Questions worth separating out
Q: How should security teams govern applications that cannot support SCIM or IGA workflows?
A: Treat those applications as governed exceptions, not as covered assets.
Q: Why do disconnected apps create more identity risk than standardised SaaS applications?
A: Disconnected apps increase risk because provisioning, deprovisioning, and access reviews cannot be executed centrally or consistently.
Q: How do teams know whether manual identity processes are actually working?
A: They should measure whether the requested change was completed in the application, not whether a ticket was closed.
Practitioner guidance
- Inventory disconnected apps by lifecycle criticality Build a register that separates SCIM-enabled apps from apps that require manual provisioning, then rank them by sensitivity, user volume, and offboarding risk.
- Assign an exception owner for every manual workflow Name a control owner for each app that sits outside automated governance, and document who approves access, who executes changes, and how removals are verified.
- Recertify stale access in disconnected systems first Target apps with local identity stores, spreadsheets, or ticket-based administration for immediate access review, because those environments are most likely to hold orphaned accounts.
What's in the full article
Cerby's full article covers the operational detail this post intentionally leaves for the source:
- A deeper breakdown of how disconnected apps break provisioning and deprovisioning workflows in practice
- More detail on the manual handling patterns that create orphaned accounts and audit fragmentation
- The follow-on analysis of why the app gap persists as a structural feature of enterprise environments
👉 Read Cerby's analysis of why disconnected apps break identity lifecycle automation →
Disconnected apps: the governance gap IAM teams keep missing?
Explore further
25/06/2026 7:28 am
The app gap is a permanent identity governance condition, not a temporary integration defect. The article is right to frame disconnected apps as an enduring reality of enterprise IT, because application diversity keeps outpacing identity standardisation. The implication is that IAM maturity has to be measured against coverage of the full app estate, not just the standards-compliant subset.
A few things that frame the scale:
- Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems, according to The 2026 Infrastructure Identity Survey.
- 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, which is why lifecycle coverage gaps are becoming a strategic issue rather than an administrative one.
A question worth separating out:
Q: Who is accountable when disconnected applications fall outside IAM and IGA coverage?
A: Accountability should sit with the identity governance owner, the application owner, and the operational team that still performs the manual change. If those roles are not explicitly assigned, lifecycle gaps will persist because no one owns verification, exception handling, or audit evidence for the disconnected app estate.
👉 Read our full editorial: Disconnected apps are breaking identity lifecycle automation
