Origin
Earlier this year, Pranay worked with a database startup through their proof of concept. In September, Pranay caught up with the IT lead at a developer-tools company whose provisioning project had been dropped. The two companies were set up very differently. Both were still filing access tickets.
The developer-tools company had done everything right. They had an identity provider, ran a provisioning project and connected everything they could. It came to 10 to 20% of their apps. Slack was in the other 80 to 90%, still done by hand. They don't have enterprise plans, the IT lead said, so they don't get SCIM. The project was dropped. When we spoke in September, they were looking again.
The database startup's problem was one level down. Getting a new hire into Slack wasn't the hard part. Getting them into the right channels was. Their admin told us automatic channel invites were limited to Slack's enterprise plan, so it fell to a person.
"I need to manually put them in."
One company stopped at the account. The other stopped at the channel. Both ended in a ticket.
That's the test I'd use for coverage. Take a new hire and list the access their job actually needs, at the depth it needs: this repo, this channel, this project, this role in the finance system. Count the tickets it takes to get there.
Zero tickets is covered. Anything more means the connector made an account and left the real access to a person. Then run it backwards when they leave: does all of it come off, at the same depth, without a ticket?
We've written about the new-hire queue, what SCIM costs and why a ticket isn't a process. This is about what's left after all 3: the access below the account.
The spec stops at the account
The SCIM spec has a field for roles. Then it says, of that field: "No vocabulary or syntax is specified" (RFC 7643).
SCIM, the standard most connectors use, was built to create users and put them in groups, and that's where most implementations stop. The repo permission, the channel and the approval limit in the finance tool are whatever each app chose to expose, if it exposed anything.
The ticket is where the waiting, the over-granting and the forgotten access start.
The plan stops it sooner
Take a new backend engineer at a software company. On day one they need about a dozen apps. We looked up 12 common ones in the SCIM Tax Index: GitHub, Slack, Jira and Confluence, Figma, Notion, Datadog, Sentry, PagerDuty, Vercel, AWS, Postman and Docker. On the plan most teams buy, 3 of the 12 include SCIM.
The developer-tools company never got as far as depth. They stopped here. A month later, the security engineer at a 77-person SaaS company opened our first call the same way: "We can't afford to pay the SSO tax or the SCIM tax."
An app's own API often goes deeper than its SCIM, and on more plans. GitHub's REST API manages organization members and repository access on Team. Slack's conversations.invite adds someone to a channel on any plan, once the calling app is in that channel. What the database startup's admin was missing was something to call it. We've written up how to provision apps without SCIM as a playbook.
Where we fit
On 11 October, Okta's catalogue listed 8,389 integrations. Filtered to lifecycle management, 955. Every one works for someone, on some plan, to some depth. The page just can't tell you which plan you're on, or how deep the connector goes.
Depth is what we built Iden for. Each connector goes as deep as the app goes: the channel, the repository, the project, the module. It uses SCIM where your plan has it, the app's API where it doesn't, and where there's neither, it works the admin console through our custom automation framework. That's 220+ connectors for apps without SCIM.
The developer-tools IT lead pushed back on that last part, and fairly. Connectors that work through an admin console need an admin account to run as, and in their experience a fresh sign-in every 5 to 7 days. Ops heavy, they called it. It is work. It's also why that maintenance is ours and not the IT team's. And every one of those connectors suspends or deletes a user exactly the way the app allows.
The database startup never needed help getting people into Slack. They needed the channels.
The checks
- Take your last 3 hires and list every access ticket from their first 2 weeks, by app. Every app on that list fails the ticket test.
- For each app, write down 3 things: the plan you're on, what it allows (SCIM, an API, or neither), and the deepest level that's automated today (account, group, or the resource itself).
- In Okta, open each provisioned app's Provisioning tab, then To App, and turn on Deactivate Users. It isn't retroactive, so reconcile anyone unassigned before it was on (Okta).
- In Okta, deactivate leavers rather than suspending them. Suspend sends nothing to the apps (Okta).
- In Entra, open each app's provisioning logs and find your last leaver's Disable event. Entra sends a delete only after a hard delete (30 days after a soft delete by default), or at once if the app doesn't support soft delete, and never if the app was unassigned first (Microsoft Learn).
- For each connected app, provision and then deprovision a test user once, and check the result in the app's own admin console, down to channels, repos and roles. Slack deactivates and never deletes; GitHub's organization SCIM removes the member from the org.
- In your next vendor demo, ask them to give a test user one specific channel, repo or role in a standard-plan app, then remove it, while you watch the app's admin console.
Send us your last 3 hires' access tickets. We'll show you, app by app, which ones Iden would have handled without a ticket, and how deep. No deck. Just the product.