HCP Gets SCIM Provisioning, With Some Sharp Edges

HashiCorp quietly shipped SCIM provisioning for HCP organizations at the end of June and got around to blogging about it this week. If you run HCP Vault Dedicated, Boundary, or Consul for more than a handful of people, this is the feature you've been filing support tickets about: your IdP creates the users, your IdP builds the groups, and when someone leaves, their HCP access dies with their Okta account instead of lingering until somebody remembers to click "remove."

That's the good news, and it's genuinely good. But the docs carry enough sharp edges that "flip it on Friday afternoon" is the wrong plan. And zooming out, the more interesting story is that HashiCorp now has three different SCIM implementations across its product line, none of which talk to each other.

What you actually get

The feature works the way SCIM works everywhere: HCP exposes a SCIM 2.0 endpoint, you generate a bearer token under Organization settings, paste the base URL and token into your IdP's provisioning config, and from then on the IdP pushes user and group changes to HCP. Users assigned to the app get created; profile edits sync; unassigning or deactivating a user removes them from HCP. Groups sync too, including membership.

The officially supported providers are Microsoft Entra ID and Okta (both with step-by-step guides), plus Ping ID and IBM Verify (pointed at vendor docs). IBM Verify getting a spot in a four-item list tells you who signs the checks now. It's available to any organization with SAML SSO on HCP, no separate tier gate.

What this replaces is the old just-in-time flow: configure SAML or OIDC SSO, verify a domain, pick a default organization role (usually Viewer or nothing), and let users appear the first time they log in. That gets people in the door but does nothing for offboarding, and it doesn't create groups at all — someone still has to hand-build HCP groups and drag users into them. SCIM closes both gaps.

The sharp edges

Read these before you enable anything, because several of them change existing behavior.

SAML only. HCP supports both SAML and OIDC for SSO, but SCIM requires SAML. If you set up HCP SSO with Okta's OIDC app or Google Workspace via OIDC, you'll be rebuilding your SSO connection first. That's a bigger change than it sounds: a changelog entry from July 17 notes that deleting an org's SSO connection now deletes every SSO user in it. Plan the migration, don't improvise it.

Enabling SCIM disables SSO default role assignment. Both the Okta and Entra guides say this outright. Under the JIT model, every new SSO user got, say, Viewer at the org level automatically. With SCIM on, a freshly provisioned user has whatever their groups grant them and nothing else. If your groups don't have project roles assigned yet, new hires land in an org where they can see nothing. This is the correct least-privilege behavior, but it means your group-to-role mapping has to be finished before you turn SCIM on, not after.

Group name collisions are resolved in the IdP's favor. If an IdP group named platform-eng syncs and an HCP group named platform-eng already exists, the IdP version replaces it. Any hand-curated membership in the HCP group is gone. Audit your existing HCP groups against the groups you'll push and either rename or accept the overwrite deliberately.

Roles still live in HCP. SCIM moves users and group membership; it does not move authorization. You still assign Admin, Contributor, or Viewer per project to each group inside HCP's IAM settings. Once a group is SCIM-managed you can't edit its membership in HCP — but you can and must edit its roles there. This is the same split Vault and Terraform Enterprise made, and it's the right one, but it means SCIM doesn't give you a single-pane-of-glass for access. It gives you one for identity.

Tokens don't expire. The SCIM bearer token is long-lived until you regenerate it. Put a rotation reminder somewhere real, and remember that regenerating it silently breaks sync until the IdP is updated.

Quotas exist but aren't published in the docs. The troubleshooting page lists "exceeded SCIM quotas for users, groups, or group members" as a failure cause and points you to the support site for the numbers. If you have a large Entra tenant and plan to push every group, find out the ceiling first.

Two IdP-specific gotchas worth writing on a sticky note: Okta needs "Create users," "Update User Attributes," and "Deactivate Users" all enabled, and the token field wants the literal Bearer prefix. Entra needs the tenant URL suffixed with ?aadOptscim062020, and the email must map from the mail attribute, not the UPN — UPN changes don't propagate to HCP.

Three SCIMs, no shared spine

Here's where it gets awkward. HCP-the-control-plane now has SCIM. Vault 2.0, released in April, has its own SCIM endpoint in beta that maps SCIM users to Vault entities and SCIM groups to internal identity groups, with its own limitations (single-field user patches, no bulk ops, HashiCorp explicitly discouraging production use while it's beta). Terraform Enterprise has a third implementation, instance-wide, validated for Okta and Entra request patterns and linking groups to teams.

And HCP Terraform — the SaaS product most HCP customers actually use — has none of them. Team membership there still comes from a MemberOf attribute in the SAML assertion, matched by team name, case-sensitive. That's fine for small orgs and brittle past a couple dozen teams.

So a platform team standardizing on HashiCorp in 2026 may end up with an Okta app for HCP org SCIM, a second SCIM client pointed at each Vault cluster's identity engine, a MemberOf claim wired into HCP Terraform SAML, and possibly a fourth config for a self-hosted TFE. The IdP is "the source of truth" four times over, which is not what anyone means by that phrase.

This isn't unusual — AWS took years to converge IAM Identity Center, and Google Cloud's identity story is still Workspace-shaped. But it's the honest state of play, and the blog post's framing of a single consistent identity workflow undersells the plumbing you'll still own.

Should you turn it on?

Yes, if you're on SAML already and have more than a dozen HCP users. The offboarding win alone justifies it; stale HCP org memberships are exactly the kind of thing that shows up in an audit finding. Sequence it like this: inventory existing HCP groups and rename collisions, define IdP groups with the exact names you want, assign project roles to those group names in HCP first, then enable SCIM, then assign users in the IdP. Test with one group before pushing the directory.

If you're on OIDC SSO, weigh the migration cost against your user count. For a five-person team it's not worth rebuilding the connection. For a fifty-person one it is.

And if you were hoping this would tidy up the Vault entity sprawl or the HCP Terraform team mess: it won't. Those are separate tickets, and one of them doesn't have a product answer yet.