SCIM gaps are leaving disconnected apps outside identity control

At a glance

What this is: This analysis explains how apps without SCIM or APIs create identity lifecycle gaps that leave provisioning, offboarding, and access certification manual and error-prone.

Why it matters: It matters because IAM, IGA, and PAM programmes only work when lifecycle controls reach every application, including disconnected SaaS, legacy, and on-premises systems.

By the numbers:

• 58% of organisations say former employees have retained access to systems after departure, largely due to apps without SCIM or API-based automation.

Context

SCIM gaps are an identity governance problem, not just an integration problem. When an application cannot receive automated create, update, and revoke events, the identity programme loses control of the account lifecycle and starts depending on tickets, spreadsheets, and manual follow-up.

Disconnected applications widen the gap between identity policy and identity execution. The article focuses on SaaS, legacy, and on-premises systems that do not support SCIM or user management APIs, which means joiner, mover, and leaver processes no longer behave consistently across the application estate.

For IAM and IGA teams, the issue is not whether SCIM is useful. It is whether lifecycle governance can still function when a meaningful portion of the environment sits outside standard automation paths.

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 much access risk?

A: Disconnected apps create risk because they sit outside the enterprise identity fabric, so access is granted and removed locally instead of through central controls. That makes it easy for former vendors, contractors, or employees to remain active long after the business need ends. The risk is highest when no one can prove who currently has access.

Q: How do you know if disconnected app governance is actually working?

A: Look for complete application inventory, documented ownership, timely revocation after departure, and audit-ready evidence for each critical account. If the only proof of access lives in chat logs or someone’s memory, the control is not working in practice, even if the team believes it is.

Q: What should IAM teams do when SCIM does not cover the full SaaS stack?

A: They should assume SCIM is only one layer of deprovisioning and design a fallback process for apps that keep their own sessions or tokens alive. If the application cannot respond to lifecycle events directly, the offboarding control must still terminate access in that app before the user is considered fully removed.

Technical breakdown

Why disconnected apps break lifecycle automation

SCIM standardises account provisioning and deprovisioning by letting an identity provider push lifecycle events into connected applications. Where SCIM is absent, every onboarding, attribute update, and offboarding action becomes a separate manual transaction. That creates delay, inconsistency, and a higher chance that account state drifts from HR and identity records. Proprietary APIs do not fully solve the problem because each integration behaves differently, changes over time, and demands ongoing maintenance. The technical issue is not just lack of automation, but lack of a common lifecycle contract across applications.

Practical implication: classify disconnected apps as lifecycle exceptions and measure how many identity actions still depend on manual handling.

Why access reviews become evidence recovery exercises

When apps are connected, the identity system can log approvals, timestamps, entitlement changes, and revocations as part of a continuous audit trail. Disconnected apps break that chain. Reviewers then need to reconstruct access history from exports, screenshots, and spreadsheets, which weakens both accuracy and completeness. The problem is not only operational inefficiency. It is also evidentiary fragility, because the organisation can no longer prove who had access, when it changed, and whether the review was actually current. In practice, access certification becomes a detective task rather than a governance control.

Practical implication: treat disconnected applications as audit-evidence risk and do not assume a completed access review equals a complete record.

Why stale access persists after offboarding

Offboarding works in connected environments because the revocation event propagates quickly to downstream systems. In disconnected apps, revocation depends on human action, which creates a time window where former employees, contractors, or transfer cases may still hold access. That gap is especially risky when direct credentials exist outside the central identity stack, because there is no guarantee that HR exit processing reaches every system on time. The failure mode is not simply slower administration. It is an orphaned account lifecycle that outlives the governance process meant to control it.

Practical implication: map every app where revocation is still manual and prioritise those with direct login credentials or privileged access.

Threat narrative

Attacker objective: The objective is not a malicious actor in the abstract but sustained unauthorised access that remains available because lifecycle governance cannot reach the application in time.

1. Entry occurs through normal onboarding or direct account creation in applications that do not accept SCIM-driven lifecycle events.
2. Credential or account state then persists because revocation is manual, inconsistent, or delayed when the user changes role or leaves.
3. Impact follows when former users retain access long after departure, creating orphaned access, compliance exposure, and avoidable security risk.

Breaches seen in the wild

• Slack GitHub breach 2022: Slack employee tokens stolen via a compromised vendor were used to download private GitHub repositories over the 2022 holidays.
• 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.

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

Disconnected applications create a lifecycle governance blind spot. SCIM is not the point in itself. The real issue is that identity policy stops at the edge of connected applications, while the business keeps using tools that never join the automation plane. That means joiner, mover, and leaver controls become partial by design, and partial governance is not governance. Practitioners should treat disconnected apps as a permanent control boundary, not a temporary inconvenience.

Identity automation fails when execution and policy diverge. The vendor’s analysis shows that manual provisioning and deprovisioning are still common where SCIM or APIs are absent. That leaves identity state dependent on human follow-through, which is slower, harder to audit, and easier to miss than event-driven lifecycle control. The broader lesson is that IGA maturity is measured by reach, not by the sophistication of the core IdP. Teams should map where execution still depends on tickets and spreadsheets.

SCIM gaps expose an identity blast radius problem. Once disconnected apps sit outside the central control plane, every role change, approval, and exit event expands the window in which stale access can survive. This is where NHI-style thinking becomes useful for human IAM: the control objective is not just authentication, but lifecycle containment across every place an identity exists. Practitioners should focus on reducing the blast radius of each disconnected application.

Access certification without system connectivity is procedural theatre. If reviewers cannot see current entitlements and revocation status inside the application, the certification process becomes a retrospective guess. That weakens compliance evidence and hides operational drift. The point for security leaders is not to automate for the sake of automation, but to ensure that review, approval, and revocation are all tied to the same authoritative record. Practitioners should challenge any certification process that depends on exported spreadsheets as its primary source of truth.

From our research library:

• 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to the 2026 Infrastructure Identity Survey.
• Read next: NHI Lifecycle Management Guide

What this signals

Identity policy only matters where it can be executed. Disconnected apps turn lifecycle governance into a partial control model, because the IdP may hold the authoritative state while the application still acts on stale accounts. That is why teams should measure control reach as part of IAM and IGA maturity, not just rollout progress.

Lifecycle containment is the useful concept here: the real target is not universal SCIM coverage, but reducing the number of places where identity changes can lag behind business changes. Where SCIM is unavailable, the governance programme needs a deliberate exception path, not an informal workaround.

Organisations should expect this gap to persist, so the question becomes where to absorb the manual burden and where to redesign the application estate. The highest-risk systems are the ones with direct credentials, high privilege, or weak evidence trails, because those are the systems where stale access becomes both operationally expensive and hard to prove.

For practitioners

• Map disconnected-app exceptions Build a register of applications that do not support SCIM or user management APIs, and tag them by business criticality, privilege level, and offboarding risk.
• Prioritise offboarding paths first Start with the applications where former users retain access for the longest periods, especially tools with direct login credentials, shared admin paths, or no central revocation trigger.
• Separate audit evidence from app exports Require a controlled evidence process for disconnected systems that records who reviewed access, when revocation happened, and which account states were confirmed.
• Treat manual provisioning as a risk metric Track how many joiner, mover, and leaver actions still depend on tickets or spreadsheets, then escalate high-volume manual handling as an identity control deficiency.

Key takeaways

• Disconnected applications create a governance gap because identity changes cannot be pushed consistently into every system.
• The article cites 58% of organisations saying former employees retained access after departure, which shows the offboarding problem is already material.
• IAM teams need exception handling for apps outside SCIM coverage, with faster revoke paths and better evidence for reviews.

Key terms

• Scim: System for Cross-domain Identity Management is the standard used to exchange user and group lifecycle data between an identity provider and an application. In production, the protocol only solves part of the problem. The harder issue is whether the implementation preserves attributes, order, and tenant scope consistently across real directory sources.
• 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.
• Access Certification: Access certification is the periodic review of whether an identity still needs its current entitlements. For NHIs, certification is only reliable when reviewers know the identity's owner, purpose, and expiry, otherwise stale machine access can persist long after the original use case has ended.
• Identity Lifecycle Governance: Identity lifecycle governance is the set of processes that create, change, review, rotate, and revoke access across human and non-human identities. It matters because access risk usually increases when lifecycle events are slow, incomplete, or disconnected from the systems that rely on them.

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.