I recently finished setting up SCIM provisioning between our Okta tenant and Vanta. It was mostly smooth, but there were a few configuration details I wish I'd known upfront. I'm writing this up in case it helps anyone else on the team looking to automate user onboarding/offboarding for Vanta access.
The core setup happens in two places: Okta (as the provider) and Vanta (as the application). Here’s the sequence that worked for us:
* **In Vanta:** Navigate to **Settings → Access Management → SCIM**. Generate and copy the SCIM bearer token and tenant URL. Keep this tab open.
* **In Okta:** Add the Vanta app from the Okta Integration Network (OIN). In the app's **Provisioning** tab, click **Configure API Integration**, check the box, and paste the credentials from Vanta.
* **Key step:** Go to the **Assignments** tab *first*. Assign the app to a test user or group. This seems to activate the attribute mappings.
* **Back to Provisioning → To App:** Edit the attribute mappings. The crucial one is `userName`. It must map to the user's primary email in Okta (`user.email` or `user.login`). Vanta uses this for matching.
Once saved, you can push users or groups. A successful test looks like this:
* User appears in Vanta's **Settings → Team** almost instantly.
* The user's status in Vanta shows as "Invited" (they'll get an email to complete setup).
* De-provisioning (unassigning in Okta) should remove the user from Vanta's team list.
A couple of pitfalls we encountered:
* If users aren't syncing, double-check the `userName` mapping format. A typo here is the most common blocker.
* The initial sync can take a few minutes. Don't re-save the configuration immediately; give it a moment.
* Remember, SCIM only manages user accounts and basic attributes. Role assignments within Vanta still need to be handled manually.
Automating this has been a small but solid win for our security team's workflow. If you've gone through this setup and found any other nuances, please share them below.
gh2
ship early, test often
That's a great walkthrough. The point about assigning the app first to activate the mappings is so true, and it's the kind of thing that can waste an hour if you miss it. I'd add one more nuance from our setup: make sure your Okta user's `primaryEmail` attribute is populated correctly, not just `email`. Sometimes they differ, and if the mapping points to `user.email` but the value sits in `primaryEmail`, the push will fail silently. We learned that the hard way.
Also, for anyone setting this up, keep an eye on the de-provisioning action. By default, Okta might be set to "suspend" in Vanta on user deactivation, but your security policy might require full deletion. That's a separate, important toggle in the Okta provisioning settings.
Stay connected
The trick about assigning the app first to activate the mappings is crucial. I've seen that same quirk in other SCIM integrations, not just Vanta. It's like the provisioning backend doesn't fully initialize its schema until it sees an assignment attempt. Good catch on the de-provisioning action too. Our audit policy required full deletion, and that's a separate setting buried in Okta's "Deactivation" action under the To App tab. It's easy to miss, leaving orphaned suspended accounts.
null
Yes! That initial assignment step is such a hidden tripwire. I had the exact same experience - sat there clicking "test" on the API connection over and over, thinking the token was wrong, before I stumbled on that.
One thing I'd add from our migration: after you do that first assignment, go back and double-check the mappings under the "To Okta" tab, not just "To App." Ours auto-populated with a weird `externalId` mapping that was pulling from `user.employeeNumber` (which we don't use), and it caused a bunch of mismatches on profile updates. Had to switch it to map from `user.id` instead.
Also, watch out for rate limiting on Vanta's side if you're pushing a large group all at once. We triggered a 429 error and had to space out our pushes.
Backup first.
The auto-populated mapping to `user.employeeNumber` is a classic example of a vendor's default assumption not aligning with real-world directory structure. It's a schema mismatch that's more common than it should be. In my experience, this often happens when the SCIM app template in Okta is built against a demo directory that uses `employeeNumber` as the immutable ID, while most live deployments rely on something like `userName` or `id`.
Your point about rate limiting is critical, especially for a security tool like Vanta where audit logs of provisioning events are themselves part of the compliance surface. Hitting a 429 during a bulk operation can create a partial sync state that's difficult to reconcile. For large pushes, we ended up writing a small script to use Okta's API and stage the assignments in batches of 20, pausing for two seconds between each. It's extra work, but it prevents the opaque errors that you'd otherwise have to dig through Okta's logs to diagnose.
SQL is not dead.
That makes sense about the de-provisioning setting. Is the "full deletion" option what most security teams actually want? I'm setting this up for my team now and I'm worried if I choose delete, it might remove an audit trail in Vanta. But suspend seems risky too.
If your audit policy is worth the name, deletion won't touch the logs. That's the whole point of an audit log. Suspending is just lazy; it leaves clutter for the next admin to clean up.
The real question is what Vanta actually does. Some systems perform a "soft delete" and retain the record, others truly purge. Ask their support. Don't assume the checkbox in Okta does what you think.
You're right to be wary though. Defaults in these tools are built for the vendor's convenience, not your security requirements.
Your vendor is not your friend.
That's a great point. It sounds like we need to check what Vanta's "delete" action actually does before trusting the Okta setting. Has anyone here already asked support about it? I'd be nervous to pick delete without knowing.
Nice work documenting this, and that initial assignment step you flagged is such a key unlock. I've seen that trip up so many admins.
One small addition from our rollout: when you do that first assignment to activate the mappings, it's also a good time to check the "Sign-On" tab settings for the app in Okta. Sometimes the default is set to "Redirect with SAML" or something else, but you'll want it set to "OpenID Connect" if that's what Vanta expects. It won't break provisioning, but it can cause confusion for users later when they try to log in.
Raise the signal, lower the noise.
The `userName` mapping is critical, but don't just assume it maps to `user.email` and call it a day. In our tenant, `user.login` was correct for some users while `user.email` was correct for others because of our org's wonky directory migration. We set up a transform in Okta to check `primaryEmail` first, then fall back to `user.login`. Without that, you'll get silent match failures on maybe 10% of your pushes.
Data over dogma.