TL;DR: Fewer than 7% of applications support SCIM, and most on-premises or private apps still resist federation, leaving manual identity execution as the default for many lifecycle tasks, according to Cerby. The app gap is structural, so IAM teams need governance models that assume disconnected systems will persist rather than disappear.
At a glance
What this is: This article explains why identity automation breaks down across enterprise apps and why disconnected applications remain a durable governance problem.
Why it matters: IAM and lifecycle teams need to design for permanent coverage gaps, because manual execution and brittle custom connectors create ongoing risk for joiner-mover-leaver control, access revocation, and audit readiness.
By the numbers:
- Fewer than 7% of applications support SCIM.
Context
Identity automation fails when applications do not expose the standards, APIs, or federation hooks that IAM tools expect. In those environments, joiner-mover-leaver work shifts back to people and tickets instead of policy-driven execution.
Cerby's argument is that this is not a short-lived maturity gap. Vendor incentives, on-premises persistence, and brittle custom connectors all keep disconnected apps outside normal lifecycle control, which means the governance model has to account for a permanent manual tail.
Key questions
Q: What breaks when an application has no SCIM or federation support?
A: Lifecycle automation breaks at the point where identity systems can no longer push authoritative changes into the app. Access changes then depend on tickets, scripts, or manual handling, which increases the chance of stale access, delayed offboarding, and weak audit evidence. The core issue is not inconvenience but loss of control over who still has access.
Q: Why do disconnected apps create so many audit problems?
A: Because auditors need proof that access was granted, reviewed, and revoked consistently, not just a statement that policy exists. Disconnected apps often force teams to assemble evidence after the fact from emails, screenshots, and export files. That is slow, fragile, and difficult to defend when controls are reviewed at scale.
Q: How should IAM teams handle applications that cannot be automated?
A: Treat them as governed exceptions, not temporary edge cases. Assign named owners, define manual approval and evidence steps, and review access changes on a schedule that matches the business risk of the application. The goal is to make manual execution controlled and auditable, even when standards-based integration is impossible.
Q: When should organisations prioritise standards support over custom integration work?
A: Prioritise standards support when the application is business-critical, has recurring joiner-mover-leaver activity, or would create a large compliance gap if access had to be managed manually. Custom work may solve one app, but standards reduce long-term maintenance and make lifecycle governance more scalable across the portfolio.
Technical breakdown
Why SCIM and federation coverage stays uneven
Standards support is not a purely technical adoption curve. App vendors balance identity standards against core features, reliability work, and revenue priorities, so SCIM and user management APIs often sit low on the backlog unless enterprise demand is strong enough to justify the build and maintenance burden. Even when vendors ship support, they may reserve it for higher tiers, turning baseline lifecycle control into a commercial gate rather than a default capability. That leaves IAM teams dependent on the product roadmap of third parties for access governance functions they do not control.
Practical implication: Treat standards coverage as a procurement and governance issue, not just an integration problem.
Why custom connectors create a maintenance tax
Custom integrations can bridge a single application, but they are usually hard-coded to a specific app state, version, or endpoint. When a vendor changes a UI, updates a private API, or alters a workflow, the connector can fail silently and create a backlog of fixes. The deeper problem is scale: each app may need different logic, and some apps expose no API or SCIM endpoint at all, which means no conventional integration path exists. The result is not automation at scale but a patchwork of brittle exceptions.
Practical implication: Assume every bespoke connector adds lifecycle debt unless it has an explicit ownership and revalidation process.
Why disconnected apps turn into governance blind spots
When identity control cannot be embedded into the application, lifecycle events drift away from authoritative systems. Leavers can remain active, movers can retain excess access, and audit trails become fragmented across helpdesk work, spreadsheets, and one-off scripts. That creates a control environment where the security consequence appears late, often during a breach review, an audit, or transaction diligence rather than at the point of access change. The governance issue is not just automation failure, but the loss of provable control over who still has access.
Practical implication: Design manual fallback workflows as governed control points with evidence, ownership, and review.
Threat narrative
Attacker objective: Exploit unmanaged application access paths that remain after identity automation breaks down.
- Entry begins when disconnected applications sit outside standard identity automation and must be managed through manual execution or brittle custom connectors.
- Escalation occurs when those integrations fail, lag behind app changes, or never exist, leaving stale access, excess privilege, or incomplete offboarding in place.
- Impact shows up later as breach findings, audit exceptions, and acquisition due diligence issues when access that should have been removed is still active.
Breaches seen in the wild
- Internet Archive breach 2024: An exposed GitLab token opened Internet Archive code and 31 million user records; unrotated Zendesk tokens let the attacker back in weeks later.
- Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
App standards gaps are a permanent governance condition, not a temporary integration backlog. The article shows that identity coverage problems persist because many applications will never support SCIM, federation, or reliable lifecycle APIs at baseline. That means lifecycle governance has to assume a durable manual tail instead of waiting for universal automation. Practitioners should treat disconnected apps as a standing control design constraint.
Identity standards have become a commercial gate as much as a technical capability. Cerby's analysis makes clear that vendors often reserve SSO, SCIM, and user management APIs for premium tiers or later roadmap stages. That turns basic access governance into a procurement variable and forces IAM leaders to evaluate not just technical fit but commercial access to control capabilities. The practical conclusion is that lifecycle coverage must be negotiated, not assumed.
Custom connectors create a maintenance tax that scales faster than coverage. Point-to-point integrations can reduce manual work for one app while increasing long-term operational burden across many apps. Each hard-coded connector introduces version fragility, endpoint dependency, and ownership ambiguity, which means the control eventually consumes the same team capacity it was meant to free. Practitioners should measure connector sustainability, not just initial integration success.
Manual identity execution shifts the control point from provisioning to evidence. Once an application cannot be automated, the governance question is no longer whether the action happened, but whether the organisation can prove it happened, by whom, and when. That is the real IGA failure mode in this article: lifecycle work moves outside the system of record. Teams should reframe disconnected apps as evidence-management problems as much as access-management problems.
Disconnected applications widen identity blast radius across the lifecycle. When offboarding, mover changes, and access corrections rely on manual follow-up, the exposure window extends beyond the original change event. The article's central warning is that this is where risk accumulates quietly, then appears during incident reviews, audits, or deal diligence. Practitioners need to govern the blast radius created by delayed or incomplete lifecycle execution.
What this signals
Identity standards coverage should be treated as an operating-model issue. If an application cannot support SCIM or federation, the IAM programme does not simply lose efficiency. It loses repeatability, evidence quality, and the ability to enforce lifecycle policy consistently across the portfolio.
Manual fallback needs governance, not optimism. Disconnected applications will continue to exist in most enterprises because business-critical systems, private deployments, and sovereignty constraints do not disappear on a roadmap timeline. The programme response is to formalise exception handling, owner accountability, and evidence capture for every manual change.
Custom connector debt becomes a hidden control risk. Each bespoke integration creates a dependency on app versions, private endpoints, and ongoing maintenance. Teams that do not track connector health as part of identity governance will underestimate how quickly integration fragility turns into stale access and audit exposure.
For practitioners
- Map disconnected applications by lifecycle criticality Classify apps that lack SCIM, federation, or usable user management APIs, then rank them by how much access risk they create if onboarding or offboarding is delayed.
- Design a manual fallback control for every uncovered app Define who executes changes, what evidence is captured, and how completion is reviewed when no standards-based integration exists.
- Retire brittle custom connectors on a schedule Assign owners to each bespoke integration, set revalidation checkpoints after app upgrades, and decommission connectors that cannot be sustained.
- Push identity standards into procurement requirements Make SCIM, federation, and supported lifecycle APIs part of vendor evaluation so app acquisition decisions reflect operational control needs.
- Track offboarding exceptions as a security metric Measure how many leavers, movers, and privilege changes still require manual handling, then report the backlog as governance debt.
Key takeaways
- Disconnected applications are not an edge case in enterprise identity, and the automation gap will persist where vendors do not expose standards-based controls.
- The risk is operational as much as technical, because manual execution and brittle connectors degrade lifecycle evidence and delay access removal.
- IAM and IGA teams need governed fallback processes for apps that cannot be integrated, with clear ownership and measurable exception handling.
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 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Disconnected apps make timely removal difficult and leave access active after lifecycle events. |
| NHI-03 — Vulnerable Third-Party NHI | Third-party app vendors control whether standards-based lifecycle integration exists and remains stable. | |
| Recommendation — Track offboarding exceptions for disconnected apps and require compensating controls until removal is verified. Assess vendor identity capabilities during procurement and escalate gaps as third-party access risk. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is about controlling and revoking entitlements across applications that resist automation. |
| Recommendation — Apply PR.AA-05 to ensure entitlements are granted, changed, and revoked through governed processes. | ||
| CIS Controls v8 | CIS-5 — Account Management | Manual identity execution and stale access are account-management failures in disconnected apps. |
| Recommendation — Use CIS-5 to inventory app accounts and remove stale access where automation cannot reach. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Stale access and unmanaged accounts widen opportunities for credential abuse and movement across apps. |
| Recommendation — Map disconnected-app exposure to TA0006 and TA0008 when stale credentials enable broader access. | ||
Key terms
- Disconnected Application: An application that is not integrated with the organisation's central identity and access stack. Access is often managed through shared passwords, manual approval, or local admins, which makes revocation, evidence, and ownership harder to enforce consistently across the application lifecycle.
- Manual Identity Execution: Identity change work carried out outside normal IAM or IGA automation, usually through helpdesk tickets, admin consoles, scripts, or ad hoc procedures. It preserves functionality when automation is unavailable, but it also increases drift, delays, and audit difficulty if not tightly controlled.
- Identity Standards: Common protocols and frameworks that let applications work with enterprise identity systems. Examples include SAML for authentication and SCIM for user provisioning. When applications do not support these standards, security teams lose the ability to manage access consistently, automate lifecycle actions, and enforce policy at scale.
- Connector Fragility: The tendency for third-party integrations to break when APIs, schemas, or vendor behaviour changes. In automation-heavy SOC platforms, connector fragility creates hidden downtime because response workflows depend on external systems staying stable.
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 June 12, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org