SCIM gaps are leaving disconnected apps outside identity control

At a glance

What this is: This analysis shows that SCIM automates identity lifecycle management only where apps support it, leaving disconnected systems outside standard provisioning and deprovisioning controls.

Why it matters: IAM, IGA, and PAM teams need to account for disconnected apps because manual access changes create orphaned access, weak audit trails, and governance drift across human and non-human identities.

By the numbers:

• 58% of organizations say former employees have retained access to systems after departure, largely due to apps without SCIM or API-based automation.
• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.

👉 Read Cerby's analysis of SCIM gaps in disconnected identity environments

Context

SCIM is the protocol that lets an identity provider create, update, and remove user accounts in connected applications automatically. The governance gap appears when important apps do not support it, because identity changes then depend on manual work, custom APIs, or ad hoc cleanup that does not scale across modern SaaS estates.

For IAM and IGA programmes, the problem is not whether SCIM works in principle. The problem is that disconnected apps still exist in most enterprises, so access review, offboarding, and evidence collection remain uneven across the application stack. That leaves security teams with policy on one side and execution on the other.

Cerby’s analysis is typical of a broader enterprise identity problem: the hardest applications to govern are often the least standardised. That makes lifecycle automation a coverage issue, not just an integration issue.

Key questions

Q: How should security teams manage access in applications that do not support SCIM?

A: They should classify those applications as identity exceptions and assign explicit operational ownership for provisioning, deprovisioning, and evidence capture. Manual handling is acceptable only as a temporary control, because it creates delay and inconsistency. The goal is not to force every app onto the same pattern, but to prove that disconnected apps are still governed with documented process and measurable completion.

Q: Why do disconnected apps create so much IAM risk?

A: Disconnected apps create risk because identity changes no longer propagate automatically, so access can outlive the business event that should have removed it. That leads to orphaned accounts, stale permissions, and incomplete audit trails. The risk is highest when the application is business critical but operationally invisible to standard lifecycle tooling.

Q: How do organisations know whether identity lifecycle automation is actually working?

A: They should measure execution coverage, revocation delay, and audit completeness across the full app estate, not just in the IdP. If a meaningful set of applications still requires tickets, spreadsheets, or manual exports, lifecycle automation is partial. A healthy programme can prove that access changes reach the systems where they matter, and that evidence is available without reconstruction.

Q: Who is accountable when access remains active after a user leaves?

A: Accountability sits with the identity, application, and business owners jointly, because the control failure usually spans process and integration. If the app cannot receive automated lifecycle events, someone must own the exception, the delay, and the evidence trail. Regulated programmes should also map this to access governance obligations under their internal controls and external audit requirements.

Technical breakdown

Why disconnected apps break identity lifecycle automation

SCIM standardises provisioning and deprovisioning by letting an identity provider send lifecycle events directly into a target application. When an app lacks SCIM support, the organisation falls back to manual updates or custom APIs, both of which introduce delay, inconsistency, and administrative overhead. In practice, this means the identity source and the application state drift apart. The IdP may say access has ended while the app still shows an active account or stale permissions. That gap is especially dangerous during offboarding, where timing matters more than convenience.

Practical implication: map which business-critical apps cannot receive lifecycle events automatically and treat them as control exceptions.

Why proprietary user management APIs do not solve the coverage problem

Some applications expose custom user management APIs, but these are not substitutes for a common lifecycle standard. Each API has different authentication, object models, rate limits, and attribute mappings, so every integration becomes a one-off maintenance burden. Identity teams then inherit the cost of monitoring endpoint changes and repairing broken automation. This is a governance problem as much as a technical one, because fragmented integrations make it hard to prove that access changes were executed consistently across the application estate.

Practical implication: inventory custom identity integrations separately from SCIM coverage and reclassify them as higher-maintenance controls.

How manual deprovisioning weakens auditability and access reviews

When identity events are handled manually, audit trails become incomplete and access certifications become evidence hunts. Reviewers are forced to ask application owners who has access, reconcile spreadsheets, and reconstruct timelines from screenshots or exports. That is slow, but more importantly, it weakens the integrity of the certification process because the evidence arrives after the fact and often in inconsistent formats. In regulated environments, the issue is not just operational inefficiency. It is the inability to demonstrate controlled access and timely revocation across all systems where identities exist.

Practical implication: prioritize disconnected applications for manual control testing and evidence retention until automation is in place.

NHI Mgmt Group analysis

SCIM coverage is now a governance boundary, not a feature checklist. The article shows that lifecycle automation only has real value where it reaches the applications that matter. When critical tools sit outside SCIM coverage, identity policy stops at the integration edge and the organisation inherits manual exceptions, stale access, and broken evidence chains. Practitioners should treat coverage gaps as an identity governance design problem, not an implementation nuisance.

Disconnected apps create identity drift that undermines the source-of-truth model. The IdP can only be the system of record when downstream applications accept lifecycle changes reliably. Once manual provisioning or custom APIs enter the picture, account state, role state, and approval state diverge. That is why access reviews become weaker over time, even if the process itself remains formally in place. The implication is that lifecycle authority must be measured by execution coverage, not by directory ownership.

Identity automation debt is the named concept this article sharpens. Identity automation debt is the accumulation of apps, processes, and exceptions that cannot receive lifecycle updates at the same speed or with the same evidence quality as the rest of the estate. It grows quietly because disconnected apps are often low-visibility tools with high business dependency. The longer the debt remains unpaid, the more offboarding, recertification, and audit evidence turn into manual reconstruction exercises.

Lifecycle governance has to span human users and non-human identities on the same operational model. The article is framed around employee offboarding, but the governance lesson extends to service accounts, shared credentials, and other non-human identities that live in disconnected systems. If the organisation cannot revoke or attest access consistently for one identity type, it will not manage the others cleanly either. Practitioners should use this gap to test whether lifecycle controls are truly enterprise-wide or only directory-bound.

From our research:

• 4.6% of all public GitHub repositories contain at least one hardcoded secret, according to the State of Secrets Sprawl 2025.
• Another finding shows that 38% of secrets incidents in collaboration and project management tools like Slack, Jira, and Confluence are classified as highly critical or urgent.
• For the operational angle on secret exposure and identity control, see the Guide to the Secret Sprawl Challenge.

What this signals

Identity automation debt is what many programmes will need to manage next. As SCIM coverage, custom APIs, and manual exceptions accumulate, identity governance becomes a coverage problem rather than a policy problem, and the gap will show up first in offboarding and audit evidence.

With 58% of organisations already reporting that former employees retained access after departure, per the 2026 Infrastructure Identity Survey, lifecycle gaps are no longer theoretical. The practical signal for IAM teams is whether their control design still depends on manual cleanup for business-critical applications.

Disconnected-app governance will increasingly need to sit beside lifecycle and secrets management in the same operating model. If an app cannot accept automated identity changes, it also tends to be where evidence fragments, ownership blurs, and stale access persists, which is why programme leaders should treat coverage as a resilience metric, not just an implementation metric.

For practitioners

• Inventory disconnected applications by business criticality Classify every app that lacks SCIM, federation, or a reliable user management API, then rank them by sensitivity, access volume, and offboarding impact. Use that list to define where manual controls are temporary exceptions and where they are unacceptable.
• Measure offboarding delay across non-integrated systems Track the time between an identity change in the source system and account revocation in each disconnected application. Separate applications with same-day execution from those that still leave access active for days or weeks, then use the delay data to set remediation priority.
• Extend access review evidence beyond the IdP Require application-level exports, approvals, and revocation records for tools that do not support automated certifications. Keep those records in a single audit evidence store so reviewers can reconstruct who had access, when it changed, and what closed the loop.
• Treat custom identity APIs as maintenance-controlled integrations Document each bespoke API integration, the owner, the failure mode, and the test schedule. Reassess whether the integration still delivers controlled provisioning and deprovisioning, or whether it is just another manual process with better branding.

Key takeaways

• Disconnected applications turn identity lifecycle management into a manual control, which increases orphaned access and weakens auditability.
• The problem is structural, because SCIM coverage does not reach every app and custom APIs do not remove the maintenance burden.
• IAM teams should measure coverage, revocation delay, and evidence completeness across the full estate, then prioritise the highest-risk exceptions first.

Key terms

• SCIM: SCIM is an open standard for automatically creating, updating, and removing user accounts across connected applications. It lets an identity provider push lifecycle changes into target systems, reducing manual administration and limiting the chance that access survives after a person changes roles or leaves.
• Disconnected Application: A disconnected application is a system that cannot receive identity lifecycle updates through SCIM, federation, or a reliable API. These apps force organisations back to manual provisioning and deprovisioning, which increases drift between the identity source and the real account state.
• Identity Drift: Identity drift is the gap that forms when the authoritative identity record and the downstream application state no longer match. It appears as stale roles, orphaned accounts, or missing revocation evidence, and it is a common consequence of partial automation.
• Access Certification: Access certification is the formal review of who has access and whether that access is still justified. In environments with disconnected applications, certifications often become spreadsheet-driven exercises because evidence must be collected manually from each system.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Cerby: SCIM and identity automation across disconnected applications. Read the original.