The new hire's first morning. SSO logs them into the eight apps that support SCIM. The other thirty-two land in the access request queue. By Wednesday they have most of them. The dashboarding tool finance uses takes until Friday because the admin panel doesn't honor SCIM and someone has to enable it by hand. The ticket lives in Slack. The screenshot lives in someone's downloads folder. The audit trail lives nowhere.
This is what governance looks like in the parts of the stack that nobody designed to be governed. Apps on standard plans that gate provisioning behind enterprise tiers. Internal admin tools that grew up before SCIM existed. Legacy systems someone in finance set up a decade ago. The new SaaS marketing signed up for last quarter that nobody told IT about. SCIM covers somewhere around twenty percent of the average company's app stack. The other eighty percent is where IT spends most of its real time.
This is how to govern it.
What the SCIM tax actually means
Apps like Notion, Linear, and Asana charge five to ten times more for the enterprise plan that includes SCIM provisioning. The standard plan is what your team is using. The enterprise plan is what their pricing page wants you to upgrade to.
The reason this matters: SCIM is the protocol most identity tools use to automate user lifecycle (create, update, deactivate) inside an app. If the app doesn't expose a SCIM endpoint at your current plan tier, the identity tool can't run that lifecycle. The choices are to pay the upgrade, to provision and deprovision manually, or to leave the app ungoverned and hope nothing goes wrong.
For a 200-person company with fifteen apps that gate SCIM, the upgrade math typically lands somewhere north of two hundred thousand dollars a year. The actual SCIM functionality on most of those apps is the same as what their standard-plan API or admin endpoint already supports. You're paying for the SCIM label, not the underlying capability.
Iden calls this the SCIM tax. It's a vendor pricing strategy, not a technical necessity. The way to avoid it isn't to upgrade. It's to provision through the channels the app already exposes at your current plan: the API, the admin endpoint, the browser-level admin interface. Same actions, same audit trail. No upgrade required.
The 80/20 gap
Across the average company between fifty and two thousand employees, SSO and SCIM together cover about twenty percent of the app stack. The remaining eighty percent is some combination of:
- SaaS apps on standard plans, gated by the SCIM tax
- Apps with no SCIM endpoint at any plan tier
- Internal admin panels and homegrown systems
- Legacy systems set up by someone who left years ago
- On-prem databases, data warehouses, cloud admin consoles
- Service accounts, API keys, AI agents, and other non-human identities
Modern identity governance vendors (Lumos, ConductorOne, Zluri, BetterCloud) all advertise coverage of "the modern SaaS stack." When you read the integration list closely, they mean coverage of the SCIM-supported subset of the modern SaaS stack. The 20%. The 80% gets a Jira-ticket integration, which is to say, no integration.
The math doesn't work. You can't run an identity program where four out of every five apps are ungoverned. Either close the gap or stop calling it governance.
How non-SCIM provisioning actually works
There's no single technique. There are three, used in combination.
The API layer
Most apps without SCIM still have an API. Many have a richer API than their SCIM endpoint would expose. The API knows how to create users, assign permissions, transfer ownership, deactivate accounts. The identity tool calls those endpoints directly, using whatever auth model the app supports (OAuth, API key, admin token).
This covers a meaningful share of the long tail. Custom Salesforce profiles, GitHub fine-grained repository access, Snowflake role assignments, ServiceNow user records, Workday HCM mutations. None of these are SCIM. All of them have APIs that do the same job at the same granularity.
The browser-automation layer
Some apps don't expose an API for user management. Or the API exists but doesn't cover what you need to do. Common in legacy SaaS that didn't grow up cloud-first, and in admin panels for internal systems. For these, the identity tool drives the admin interface the way an admin would: log in as an admin service account, navigate to the user management page, perform the action, capture the result.
This is more fragile than API-based integration. Vendors change their UIs. Iden's connectors detect breakage and self-heal where possible, ship updates within hours where they can't. Where browser automation is the right tool, it works.
The custom connector layer
Some apps don't fit either of the first two. Internal admin tools that grew up before APIs were a thing. A LIMS that holds data the FDA cares about and has its own bespoke permissions model. A mainframe terminal that nobody on the IT team wants to touch.
For these, Iden ships a custom connector built specifically for the system. Two-day delivery, maintained indefinitely. Our team builds it, our team maintains it, our team updates it when the upstream changes.
The 48-hour connector model
Most custom connectors land in 48 hours. Some take a week if the upstream API documentation is wrong (it sometimes is) or the auth flow needs negotiation with the vendor. The work is open at the contract level. If you depend on the app, we build the connector. If we built it, we maintain it. You don't.
What's out of scope: physical access systems and operational technology environments where regulatory or safety considerations require a different model. We'll tell you when we hit that line. Otherwise, the answer is yes.
The 48-hour number is real because connector work is the company's main competency. The teams that build SCIM endpoints inside SaaS vendors are building one thing once. The team that ships connectors at Iden is building hundreds, all on the same toolchain. Repetition makes the work fast. There's no other secret.
Patterns that break in non-SCIM territory
A few common failure modes worth knowing.
The half-built SCIM endpoint. An app advertises SCIM support. The endpoint exists. What you find when you connect: SCIM only reads group memberships and creates users, but doesn't expose per-permission grants, doesn't honor deprovisioning, or has a thirty-minute lag. SCIM is a label that means different things to different vendors. Test the specific capabilities you need before relying on the marketing claim.
The standard-plan workaround that everyone uses. A shared admin login. One person enables and disables users by hand. The credentials are in a password manager that some people on the team have access to. The audit trail is whatever Slack remembers. This is the most common configuration in companies under 500 employees, and the most dangerous.
The Jira ticket disguised as an integration. Some IGA tools claim non-SCIM coverage and what they do is open a ticket in your ticketing tool, which a human on the IT team then handles. This counts as automation in the brochure but not in the work. Read the integration docs to see whether the actions execute in the target app or get handed back to IT.
The connector that depends on the admin who left. A custom connector was built on a Saturday two years ago by an engineer who's since moved on. Nobody on the current team knows how it works. It breaks during a vendor upgrade and stays broken because the documentation is in a private GitHub repo nobody has access to. Same failure mode as the manual checklist, just less visible until it breaks.
What working lifecycle across non-SCIM looks like
The HRIS marks a new hire as starting Monday. Birthright access fires Monday morning across every app in the catalog: SCIM apps via SCIM, API apps via API, admin-panel apps via browser automation, custom connectors as needed. The new hire opens their laptop and the eight apps SSO knows about are logged in. The other thirty-two have an account ready and permissions assigned.
The same trigger model handles movers. Promotion changes propagate to entitlement bundles. Department change reroutes ownership of files and data. Project rotation expires the elevated access automatically.
Departures fire the offboarding sequence covered in the offboarding pillar. Same machinery, opposite direction. Non-SCIM apps get the same revocation treatment as SCIM apps. No ticket. No screenshot.
Where Iden fits
Iden was built for the part of the stack other tools cannot reach. SCIM-supported apps get the SCIM integration. API-supported apps get the API integration. Apps that need browser automation get browser automation. Apps that need a custom connector get a custom connector, delivered in two days, maintained for life.
The 80% other tools wave away is the work that decides whether identity governance is real or theater. That's the work this layer does.