SCIM tax

The SCIM tax is what a company pays to make one application listen to its identity provider. SCIM, the System for Cross-domain Identity Management, is the protocol that lets an identity provider create, update and deactivate accounts in an application automatically. Most SaaS vendors have built it, and most of those have placed it on their enterprise plan. A company that wants provisioning to run without tickets therefore buys the enterprise plan for every seat. The difference between the plan it needed and the plan it bought is the tax.

The name follows the SSO tax, the term sso.tax gave to the same pattern applied to single sign-on. As SSO moved down to mid-tier plans under pressure from that list, SCIM stayed at the top, and provisioning became the feature that forces the upgrade.

Plan a team buys                  Plan with SCIM
+-----------------------+         +-----------------------+
| Single sign-on    yes |         | Single sign-on    yes |
| Audit log         yes |         | Audit log         yes |
| SCIM provisioning  no |  --->   | SCIM provisioning yes |
+-----------------------+         +-----------------------+
      $7.25 a seat                      $15 a seat
              x 220 seats x 12 months = about $20,000 a year

How big is the SCIM tax?

Three numbers answer that: how many vendors charge for the protocol, what the gap costs per seat, and what happens where no price is published at all.

The shape of the market

The SCIM Tax Index tracks 286 SaaS vendors and their plan tiers. At the June 2026 verification the picture was this.

Roughly six applications in ten charge for the protocol and a further two in ten never built it. That leaves fewer than one in twenty where an identity provider can provision on the plan a mid-sized company would normally buy.

What the gap costs per application

The number that matters is not the enterprise list price. It is the difference between the plan a team would have bought anyway and the plan that unlocks the endpoint, multiplied by every seat in the company, because a plan tier applies to the whole account rather than to the one administrator who needs the feature.

Prices are per user per month as published on 12 June 2026 and recorded in the Index, and the annual figures multiply the gap by seats and by twelve.

The tiers with no published price

Several of the most common tools, including Notion, Asana, Linear and Miro, place SCIM on an enterprise plan with no published price, so the gap is whatever the sales conversation produces. Three things change that conversation. Ask for the feature rather than the tier, because SCIM is occasionally available as an add-on to the plan already held and a seller will not volunteer that. Ask at renewal rather than mid-term, when the alternative to agreeing is losing the account. And get the number in writing, per seat per month on a stated seat count and term, because that is the only form finance can compare against the cost of provisioning the application by hand.

A former CTO who had to keep auditors happy described what the published version felt like from the buying side:

Why do vendors do it?

The economics are straightforward and vendors are not shy about them.

SCIM is an anchoring feature, not a cost centre

SCIM costs roughly the same to operate on any plan, since the endpoint is the same code. What differs is who asks for it, and a five-person team never does. An IT department at 200 people asks for it, with an auditor on the calendar and an offboarding checklist that keeps missing things, and that department cannot easily say no to the price. A SaaS founder made the case for the practice in the open, in the thread that popularised the SSO wall of shame:

I'd say that SSO should be available on the cheapest or second cheapest tier. However, I would then make SCIM support (automated provisioning/deprovisioning) part of the most expensive tier. If you're a small business, say 20-30 people then you can manage that by hand, but if you're a larger organisation then SCIM is a must-have. I run a SaaS business. When dealing with vendor qualification questionnaires, you can tell the small and large businesses apart by whether they want SCIM support or not.

The feature is doing segmentation work rather than engineering work. It identifies the customers with a compliance budget and moves their whole account to the tier that carries the margin.

Why SSO moved down and SCIM did not

The same logic put single sign-on behind enterprise plans a decade ago, and there it partly failed: a public list of offenders, an argument that a security control should not be a luxury tier, and enough buyers asking the question in procurement moved SSO into mid tiers at a good number of vendors. SCIM never attracted that attention, for two reasons. It is invisible to everyone except the administrator, so no employee ever complains that it is missing, and its absence is survivable, because somebody can create accounts by hand in a way nobody can hand-carry a login. The pressure that moved one feature has not moved the other, and several vendors that gave SSO away kept provisioning where the margin is. A commenter on enterprise AI pricing listed it as one of the standard moves:

Sell you X seats, noting that as soon you reach 2X seats, you need to move to the Enterprise plan, under which largely the same feature set plus a couple of gated SCIM controls will cost twice as much.

What does not paying cost?

The alternative to the upgrade is manual provisioning for that application, and manual provisioning has its own bill. It arrives in two parts, and only the first one ever reaches a budget.

The bill in hours

1. Somebody creates the account by hand on the start date, from an invite link, after a ticket.
2. Somebody removes it by hand on the leave date, or forgets to.
3. The forgotten removals become orphaned accounts.
4. The orphaned accounts become audit findings.
5. The finding lands on the same IT team that declined the upgrade.

At two joiners and two leavers a week, an application that takes five minutes each way costs about seventeen hours a year of somebody's attention, which is cheap. The cost is not the minutes. It is that the work is interruptive, undocumented, and last in the queue behind whatever broke that morning.

The bill in findings

The second part lands in an audit. A missed removal becomes an orphaned account, a sampled orphaned account becomes a finding, and a finding becomes a remediation plan with a date on it. One miss in twenty at four leavers a week is roughly ten open accounts a year in that one application, and an auditor only has to find one of them. Nobody publishes a clean number for this bill, because it is paid in IT hours, in licences nobody reclaimed and in findings nobody wanted. The shape of it is the point: the tax is paid either way, to the vendor or in hours. An IT leader at a mid-sized company described the middle:

Enterprise plans are too much (both in terms of cost and features) for us, but we are smart enough to have security requirements and one of those is SSO & SCIM. Very few SaaS offers that on anything but the most expensive "call for quote" tiers. That's a huge problem.

What are the ways around it?

There are three, and each has a cost.

Pay it, selectively

Upgrade the applications where a missed account matters most: the code host, the customer data platform, the tool with the most leavers. This is what most companies do by default, and the discipline is to choose rather than to upgrade everything that asks.

Provision over the API

Most applications expose account management through an API on every plan, because their own customers automate against it. A governance tool that speaks the API creates, changes and closes accounts without the plan tier entering the conversation.

Automate the console

For the applications with no API at all, a custom automation framework drives the admin console the way an administrator would. It is the least elegant path and the one that reaches the systems nothing else can.

The second and third do not depend on the plan tier, and they are how the non-SCIM majority of a stack gets automated without renegotiating every contract. The per-vendor pages of the SCIM Tax Index show the gated plan, the gap and the alternative for each application.

Iden provisions applications on the plan a company already pays for. The connector catalogue uses SCIM where it is included, the application's API where SCIM is gated, and a custom connector where there is no API, so the enterprise upgrade stops being the price of automation. The SCIM Tax Index is Iden's open dataset of who charges what, per vendor. The feature behind it is Day one access, without a ticket.

200+ connectors. SCIM where the app has it, an API where it does not, and a custom connector where neither exists.