The Non-SCIM SaaS Playbook for IT Operators — 2026

~40% of mid-market SaaS apps don't support SCIM. This playbook shows IT teams how to govern them — manual, API, and browser automation — with a real audit trail.

TL;DR

• Industry research estimates roughly 40% of mid-market SaaS apps don't support SCIM — meaning automated identity lifecycle tools have a blind spot covering nearly half the average stack.
• When a SCIM-less app isn't accounted for, ex-employees keep access long after their HR record says terminated.
• Three options exist: manual deprovision (runbook + ticket), direct API integration where the vendor supports it, or browser automation for everything else.
• Browser automation is the only approach that scales without an API and generates a signed audit trail.
• KINT covers non-SCIM deprovisioning via browser automation: Adobe Admin Console is live today; Figma, Canva, and Notion are in progress.

The 40% blind spot in your SaaS stack

According to industry research, roughly 40% of mid-market SaaS applications don't support SCIM. That's not a niche edge case. If your company uses 30 apps, around 12 of them probably have no SCIM provisioning endpoint at your plan tier.

Most joiner-mover-leaver (JML) automation tools — identity providers, lifecycle platforms, directory syncs — route deprovisioning through SCIM. That works well for the apps that support it. For the ones that don't, nothing happens automatically. When someone leaves, their account in those apps stays open until an IT admin manually closes it.

That's the non-SCIM problem in one sentence: you've automated 60% of your stack, and the other 40% is running on tickets, memory, and luck.

Why does this keep happening? (The honest reason some apps still lack SCIM)

SCIM has existed since 2011 — a long time for a standard to be underadopted. The reason it persists is straightforward: building and maintaining a SCIM endpoint takes real engineering effort, and enterprise-grade provisioning is deprioritised by vendors whose primary buyers are small to mid-size teams on standard plans.

Many apps offer SCIM only on their highest-tier licences. If your company is on Adobe Creative Cloud's standard Business plan, Figma's non-enterprise tier, or Notion's Business plan, the SCIM endpoint either isn't available or covers only partial user management.

Adobe Admin Console is the textbook mid-market example. Adobe's enterprise agreement includes full SCIM provisioning. On the standard Business and Teams plans — which most 100–500 employee companies use — provisioning via SCIM is either unavailable or limited enough that reliable automated deprovisioning requires a different approach.

Figma, Canva, Notion, Loom, and Miro follow the same pattern. These are among the most-deployed collaboration tools in mid-market stacks. They're also among the least consistent SCIM adopters at non-enterprise plan tiers.

This isn't going away in the near term. The economics haven't changed: SCIM investment pays off when the buyer is enterprise-grade and will churn without it. Below that threshold, vendors ship other features first.

What actually breaks when an app lacks SCIM

Ghost accounts and dormant licences

When a leaver's account in a non-SCIM app isn't deprovisioned, three things happen in parallel.

Their access stays open — a security gap. Their licence keeps billing — a cost gap. And your offboarding records show that app as "handled," even when it wasn't — an audit gap.

At 20 leavers per year across 10 non-SCIM apps, that's 200 manual deprovisioning steps. Each one is a potential miss.

The SOC 2 CC6.3 problem

SOC 2's CC6.3 control requires evidence that logical access is revoked when an employee's relationship with the organisation ends. "We sent an IT ticket" is not audit evidence. A signed, timestamped record — showing which account was deactivated, in which system, at what time, triggered by which HR event — is.

A manual deprovision with no automatic evidence record leaves a CC6.3 gap. When an auditor asks for access-removal evidence for a specific termination from six months ago, the answer cannot be "we're confident the IT admin handled it."

The scale problem

At 100 employees, tracking non-SCIM apps manually is annoying but manageable. At 200–300 employees, it becomes a compliance risk. At 500 employees, the volume of manual steps makes an accurate audit trail structurally impossible without automation.

The median offboarding lag at mid-market companies that haven't automated lifecycle management is around 11 days (industry research). That's 11 days of open access per leaver per event. For a 300-person company with 4% annual churn, that's roughly 130 person-days of ghost account exposure per year — across the full stack, not just the SCIM-supported part.

The three options for governing SaaS apps without SCIM

There are exactly three approaches. Here's what each costs in practice.

Manual works at 5 leavers per year and 3 non-SCIM apps. It stops working cleanly above that threshold. Direct API integration is the right answer where it's available — but it requires the vendor to expose the correct endpoints, and many don't at mid-market plan tiers. Browser automation fills the gap for everything the other two can't cover.

How browser automation handles deprovisioning (the mechanics)

Browser automation is what it sounds like: a script that drives the admin console the way an IT admin would, but deterministically, at machine speed, with a full evidence record attached.

The execution flow

1. The leaver event fires — triggered by your HR system (BambooHR, Workday, Rippling, Keka, Greythr, or a CSV upload) or your IdP (Microsoft Entra, Okta, Google Workspace).
2. The lifecycle engine routes each app in the leaver's access set to the correct execution method: SCIM where it's supported, direct API where available, browser automation for the rest.
3. For a browser-automation app, the engine opens the admin console headlessly, navigates to user management, locates the account, and deactivates or removes it.
4. At each step, a screenshot and a structured action record are captured.
5. The evidence is signed with Ed25519 and appended to the leaver's audit packet — alongside the SCIM and API evidence from the other apps in the same workflow.

The result is a single signed, timestamped evidence packet covering access removal across the entire stack — regardless of whether each individual app supports SCIM.

A live example: Adobe Admin Console

Adobe Admin Console is KINT's first fully live browser automation integration. On standard Business and Teams plan tiers, when a leaver event fires:

KINT opens the Adobe Admin Console headlessly. Navigates to Users. Removes the user from each licensed product — Acrobat, Photoshop, Illustrator, or whatever's assigned. Captures a screenshot per product removal. Signs the evidence and closes the session.

Total execution: approximately 5 seconds per Adobe seat. The signed record maps to SOC 2 CC6.3 and is exportable in three clicks alongside the rest of the offboarding evidence.

Eight things to check in any browser automation approach

Not all browser automation implementations are equal. Whether you're evaluating KINT or any other tool, these eight questions separate a robust implementation from a brittle one.

1. Does it capture per-action evidence, or just a completion log? A log that says "user removed from Adobe Admin Console" is not the same as a signed record with screenshots of each step. SOC 2 auditors will ask for the latter.

2. Is the evidence signed and tamper-evident? A screenshot saved to a cloud bucket can be modified. A screenshot signed with a private key and verifiable with a public key cannot. Ask what signature standard is in use. KINT uses Ed25519.

3. Is the automation idempotent? If the script runs twice — because a retry fired, or a second trigger came in — does it create a duplicate action or leave the app in an unknown state? Correct automation should detect that the account is already removed and log "already completed" without re-executing.

4. What happens when the vendor's admin UI changes? Vendors redesign their admin consoles. A script written against the old UI can fail silently. Ask how quickly UI changes are detected and patched, and whether the system fails closed (alerts IT and waits) or fails open (silently skips the deprovision).

5. Does it require storing admin credentials in plaintext? Browser automation that logs in with a stored plaintext password is a security liability. Credential management — via OAuth, a secrets store, or equivalent — matters.

6. Can it run in parallel across multiple non-SCIM apps? A leaver with five non-SCIM apps should trigger all five deprovisions concurrently, not sequentially. Sequential execution at five apps multiplied by 10 seconds each is 50 seconds. Parallel execution is 10 seconds.

7. Is there a human approval gate for privileged accounts? For standard-access accounts, fully autonomous execution is appropriate. For admin-level accounts — GitHub org admin, Salesforce system admin, HubSpot super admin — a human review step before execution reduces the risk of removing access that's needed for a transition handover.

8. Does routing happen automatically, or does IT configure it per app? The value of browser automation is that it extends your JML workflow to apps that don't fit the standard SCIM path. If IT has to manually flag each non-SCIM app and configure its routing, the overhead largely cancels the benefit. The lifecycle engine should detect what's available for each app and route accordingly.

KINT's current state for non-SCIM apps (honest, as of May 2026)

KINT handles non-SCIM apps via browser automation as one of three execution paths within the same joiner-mover-leaver workflow engine — alongside SCIM and direct API. The routing is automatic.

Live:

• Adobe Admin Console — full deprovisioning, signed evidence, ~5 seconds per seat.

In progress:

• Figma, Canva, Notion, Loom, Miro — partial or coming soon. Do not treat these as live.

For the full current list, check /connectors. That page is the source of truth for what's live today versus what's still being built.

Across KINT's catalogue: 50+ live API and SCIM connectors, with 200+ mapped in the catalogue. Browser automation apps are the expanding subset, with new connectors shipping regularly.

One honest note on the architecture: browser automation is not a fallback of last resort. It's a deliberate execution path for apps where SCIM or API isn't available at the relevant plan tier. The evidence it produces is the same standard — signed, timestamped, auditable — as the evidence produced by the SCIM and API paths.

The non-SCIM governance checklist

Starting from scratch takes most IT teams one to two days to complete. Work through this in order.

Step 1 — Audit your stack for SCIM coverage. Pull a list of every SaaS app your company uses. For each one, check whether a SCIM provisioning endpoint exists at your plan tier (usually visible under Admin settings > Security or Single Sign-On). Apps without it are your non-SCIM inventory. Be specific about plan tiers — SCIM availability on the enterprise plan doesn't help you if you're on the business plan.

Step 2 — Classify by risk. Tier 1 (1-hour SLA): apps where the ex-employee held admin or elevated access — GitHub, Salesforce, HubSpot, Zendesk, AWS. These create the most direct exposure if not deprovisioned immediately. Tier 2 (24-hour SLA): standard-access collaboration apps — Adobe Admin Console, Figma, Canva, Notion, Loom, Miro, Zoom. Tier 3 (48-hour SLA): read-only tools and lower-sensitivity apps.

Step 3 — Build the manual runbook for each non-SCIM app. For every Tier 1 and Tier 2 app: document who holds the admin credentials, where the user management page is, what "removed" looks like (deactivated versus deleted versus licence unassigned), and where to log completion. Do this now, even if you plan to automate. The runbook is your fallback when automation fails or a new app is added to the stack.

Step 4 — Decide on the automation threshold. Browser automation is worth the setup when you have more than 10 non-SCIM apps in your stack, or more than 10 leavers per year, or both. Below those thresholds, a disciplined manual runbook with a 24-hour SLA may be sufficient. Above either threshold, manual doesn't scale to an auditable standard.

Step 5 — Connect your HR trigger. Deprovisioning should start the moment the HR termination event fires — not when HR sends an email to IT. Connect your HR system (BambooHR, Workday, Rippling, Keka, Greythr, or a CSV upload) as the source-of-truth trigger. The gap between the HR event and the start of deprovisioning is where ghost accounts are created.

Step 6 — Set and publish your SLA. Write the SLA. Get it approved by your security lead or CISO. Include it in your security policy. SOC 2 auditors will ask what your stated revocation SLA is before they ask whether you met it. "We try to do it same day" is not an SLA.

Step 7 — Close the evidence loop. Every non-SCIM deprovision needs a record: which account, which app, what time, by what method. The record needs to be centrally stored and auditor-accessible. Manual deprovisioning: a signed-off ticket in your ITSM tool. Automated deprovisioning: the automation generates a signed evidence packet automatically. Either way, the record needs to exist and be searchable by employee and by date.

Pricing

KINT's browser automation for non-SCIM apps is available on the Growth plan and above.

14-day free trial. No card required. No automatic conversion.

The founding offer is currently available for the first 5 Growth customers: $1.50/employee/month, 12-month price lock, in exchange for case-study collaboration. Three spots remaining as of this writing.

FAQ

Which SaaS apps most commonly lack SCIM support at the mid-market plan level?

The most common mid-market non-SCIM apps are Adobe Admin Console (standard Business plans), Figma (most non-enterprise tiers), Canva Teams, Notion Business, Loom, and Miro. The pattern is consistent: the vendor offers SCIM on enterprise agreements, and mid-market plan tiers get either no provisioning endpoint or a limited one that doesn't reliably cover deprovisioning. These apps are also among the most widely deployed collaboration tools at 100–500 employee companies, which makes the gap particularly common.

Can I automate deprovisioning for apps without SCIM, or does it always require a human?

You can automate it using browser automation. A lifecycle platform with a browser automation engine scripts the admin console actions an IT admin would take manually — navigate to user management, locate the account, remove or deactivate it — and executes them when a leaver event fires. KINT does this for Adobe Admin Console today: when a leaver event triggers, KINT removes the user from each licensed Adobe product, captures a screenshot per action, and signs the evidence. No human required.

How is browser automation for deprovisioning different from general RPA?

Traditional RPA tools — UiPath, Automation Anywhere, Power Automate — are general-purpose. They can automate any repetitive web workflow. Browser automation built specifically for identity lifecycle management is purpose-built for one job: deprovisioning user accounts when a leaver event fires. Purpose-built automation includes things general RPA doesn't: idempotent execution (safe to run twice without creating duplicates), signed evidence capture per action, automatic routing logic based on whether the app has SCIM or API support, and audit output structured for SOC 2 CC6 mapping.

Is browser automation reliable enough for a SOC 2 audit?

Yes — with the right evidence model. The key question is what the automation produces. A log entry that says "completed" is not audit evidence. A screenshot of each action, signed with Ed25519, timestamped, and stored with a verifiable hash is. KINT's browser automation generates the latter. Before using any browser automation tool for SOC 2 evidence, confirm: (1) per-action screenshots are captured, (2) the evidence is signed with a recognised cryptographic standard, and (3) the records are exportable in a format your auditor can verify.

What is the actual security risk of leaving non-SCIM apps un-deprovisioned?

It depends on what access the ex-employee held. In the highest-risk cases — admin access to GitHub, elevated permissions in Salesforce, write access to a shared Notion workspace — an un-deprovisioned account is a direct data-access risk. In the typical case, it is a cost and compliance gap: licences are being paid for accounts that now sit outside your data governance policies. Industry research puts the median time-to-full-revocation at mid-market companies without lifecycle automation at around 11 days. For a 300-person company with normal churn, that adds up to a meaningful window of uncontrolled access exposure per year.

Does KINT support browser automation for Figma and Notion right now?

Not fully, as of May 2026. Figma and Notion browser automation are in progress. Adobe Admin Console is the only fully live browser automation integration today. Check /connectors for current live status — that page is updated as new integrations ship.

How do I find out which apps in my stack support SCIM?

Check each app's Admin settings, usually under Security or Identity Management. Look for "SCIM provisioning," "user provisioning," or "automated user management." Your SSO or IdP provider — Okta, Microsoft Entra, or Google Workspace — may also list the apps it can provision automatically; those are the SCIM-supported ones. Every app outside that list at your current plan tier is a candidate for manual coverage or browser automation. When in doubt, assume an app doesn't have SCIM at your plan tier until you confirm it in the admin settings.

What is the fastest path to non-SCIM deprovisioning coverage at a 200-person company?

Three steps. First, audit your non-SCIM apps — for a 200-person company this is typically 8–15 apps. Second, connect KINT to your HR system (BambooHR, Workday, Rippling, Keka, or a CSV export) — OAuth setup takes under 5 minutes. Third, activate browser automation for your highest-risk non-SCIM apps. KINT routes automatically: SCIM apps get SCIM, API apps get API, browser automation apps get the browser automation engine. You configure the workflow once; leaver events trigger everything. The joiner-mover-leaver engine handles the full sequence, not just the non-SCIM piece.

Governing the 40% of your stack that SCIM doesn't reach is solvable. It just requires the right execution path.

Book a 15-min walkthrough →

14-day trial · No card · Live in under an hour

KINT (by Kingsley Integrators) is an HR-driven identity lifecycle automation platform for companies with 100–500 employees. It automates onboarding, role changes, and offboarding across SaaS apps — including the apps without APIs, via browser automation — and produces SOC 2 CC6 audit evidence as a byproduct. Pricing is published per employee per month ($3 Starter, $5 Growth). Self-serve signup at kingsleyint.com.