SCIM provisioning for SSO

Manage Strike Graph access and roles directly from your identity provider

Written By Micah

If your organization uses Single Sign-On with Strike Graph, SCIM lets your IT team manage Strike Graph access from the same place they manage everything else: your identity provider (IdP).

When someone leaves the company and IT deactivates them in Okta or Microsoft Entra ID, their Strike Graph access ends automatically. When someone moves from a contributor group into a manager group, their Strike Graph role updates to match. No tickets, no manual roster cleanup, and no waiting on a Manager in Strike Graph to remember to make the change.

For compliance programs, this matters twice over: your user roster stays accurate, and your access provisioning and deprovisioning controls are enforced by the same directory your auditors are already looking at.

What is SCIM?

SCIM (System for Cross-domain Identity Management) is the industry-standard protocol that identity providers use to push user lifecycle changes — activations, deactivations, and group membership changes — into the applications your organization subscribes to.

SCIM is part of Strike Graph's SSO bundle, which is included in Scale and Enterprise plans and available as an add-on module for Certify. Rather than integrating with each identity provider separately, Strike Graph uses your existing SSO connection as the channel: your IdP sends standard SCIM events to that connection, and Strike Graph applies the resulting changes to your organization.

This means SCIM works the same way regardless of which identity provider you use, as long as that provider supports outbound SCIM provisioning.

How SCIM works with Strike Graph

The flow looks like this:

  1. An administrator makes a change in your identity provider — deactivating a user, or adding them to a group.

  2. Your IdP sends a SCIM event to your Strike Graph SSO connection.

  3. Strike Graph receives the event and applies the change to your organization.

Changes are applied as events arrive, so users generally do not need to log out and back in for a deactivation to take effect. Role changes take effect against the user's Strike Graph record immediately, though a user who is already signed in may need to refresh before they see their new permissions.

What SCIM keeps in sync

User deactivation. When a user is deactivated in your IdP, Strike Graph deactivates them, removes them from your organization's roster, and blocks them from signing in again.

User reactivation. When a previously deactivated user is reactivated in your IdP, Strike Graph restores their access.

Role assignment. When you add a user to — or remove them from — a Strike Graph role group in your IdP, Strike Graph updates that user's role to match.

What SCIM does not do: SCIM does not create new Strike Graph user accounts. It does not need to. Strike Graph's SSO login flow already creates an account the first time a new user signs in, so a user who has been provisioned in your IdP simply logs in and gets an account.

This has one practical consequence worth knowing: SCIM events only affect people who have signed in to Strike Graph at least once. If you deactivate someone in your IdP who has never logged in to Strike Graph, there is no Strike Graph account to deactivate, and the event is safely ignored.

Prerequisites

  • The SSO bundle on your plan — included with Scale and Enterprise, or added on to Certify

  • An active enterprise SSO connection with Strike Graph (most customers use SAML)

  • An identity provider that supports outbound SCIM provisioning, such as Okta or Microsoft Entra ID

  • Administrator access to your identity provider

  • Your organization's email domain registered with your Strike Graph organization

If you aren't sure whether SCIM is available for your organization, reach out to your Customer Success Manager or contact support through the in-app messenger.

Setting up SCIM

SCIM is enabled on your SSO connection by Strike Graph, so setup starts with a request rather than a settings page.

Step 1: Request SCIM for your connection

Contact your Customer Success Manager or Strike Graph support and let them know you'd like SCIM provisioning enabled for your SSO connection. It's helpful to mention which identity provider you use, and whether you plan to manage roles through IdP groups.

Step 2: Receive your configuration values

Strike Graph will enable SCIM on your connection and send you two values:

  • A SCIM endpoint URL

  • A SCIM access token

The token is a credential — treat it like a password. Strike Graph will send it to you through a secure channel, and we recommend storing it in your organization's password manager rather than in email or chat.

Step 3: Configure provisioning in your identity provider

In your identity provider, add Strike Graph as a provisioning application (in Okta this is under the application's Provisioning settings; in Entra ID it's under Provisioning for the enterprise application) and enter the endpoint URL and token from the previous step.

Enable the provisioning options that match what you want to keep in sync — at minimum, user updates and deactivations, and group push if you plan to manage roles through groups.

Step 4: Create your Strike Graph role groups

If you want to manage Strike Graph roles from your IdP, create one group per role and follow the naming pattern below. Then assign your users to the appropriate group.

Naming your role groups

Strike Graph determines which role to apply by reading the group's name. A group name has to contain two things:

  1. The word strikegraph

  2. A role token: manager, auditor, or contributor

We recommend the pattern <your-prefix>-strikegraph-<role>, which keeps the groups readable and unambiguous inside your IdP:

  • acme-strikegraph-managers

  • acme-strikegraph-contributors

  • acme-strikegraph-auditors

Matching is case-insensitive, and the two required words can appear anywhere in the name — StrikeGraph Managers (Acme) works just as well. What matters is that both words are present.

Important: if a group name is missing either the word strikegraph or a valid role token, Strike Graph will skip it. The event is not an error and nothing breaks; the role change simply isn't applied. If roles aren't updating the way you expect, group naming is the first thing to check.

A few naming details to keep in mind:

  • If a group name happens to contain more than one role token, the highest-privilege token wins, in this order: manager, then auditor, then contributor.

  • Renaming a group so that it no longer matches the pattern will stop role changes for that group from being applied.

  • Group names are only used to resolve the role. They don't need to match anything else in Strike Graph.

How role changes are applied

Strike Graph roles are mutually exclusive — a user holds one role at a time — so role changes are a replacement, not an addition.

  • Adding a user to a role group assigns that role in Strike Graph, replacing whatever role they held before.

  • Removing a user from a role group moves them to the Contributor role. It does not remove their access. To remove access entirely, deactivate the user in your IdP.

  • Replacing a group's full membership brings Strike Graph in line with the new list: users who were added get the group's role, and users who were removed drop to Contributor.

Two notes on scope:

  • Strike Graph resolves which organization to update from the group's members, so a Strike Graph role group should only contain users who belong to that Strike Graph organization.

  • The Auditor Role has to be enabled for your organization before it can be assigned. If it isn't, users in an auditor group keep their existing role and the change is skipped. Your Customer Success Manager can confirm whether the Auditor Role is available to you.

How deactivation works

When your IdP deactivates a user, Strike Graph does the following:

  • Marks the user inactive and blocks them from signing in again

  • Removes them from your organization's roster, so they no longer appear in your user list

  • Disconnects any integrations they had configured in your organization

  • Clears their ownership of controls, risks, and evidence in your organization

  • Cancels any pending Strike Graph invitation for that email address

That fourth point is the one to plan around. When a Manager deactivates a user inside Strike Graph, they're prompted to reassign that person's items to someone else. A deactivation that arrives from your IdP has no equivalent prompt, so the items that person owned are left without an owner.

Recommended practice: before deactivating a departing employee in your IdP, have a Manager reassign their controls, risks, and evidence in Strike Graph. If that isn't possible — as with an urgent offboarding — a Manager can find and reassign the unowned items afterward.

Reactivating a user

When a user is reactivated in your IdP, Strike Graph unblocks their account and restores their access to your organization.

Two things do not come back automatically:

  • Their role. A reactivated user rejoins as a Contributor. If they should hold a different role, make sure they're in the correct role group in your IdP, or have a Manager set their role in Strike Graph.

  • Their ownership. Controls, risks, and evidence that were unassigned during deactivation stay unassigned and need to be reassigned.

Reactivation through SCIM applies to users who belong to a single Strike Graph organization. If a user belongs to more than one organization, contact support to have their access restored.

Things to know

  • SCIM never creates Strike Graph accounts. First-time access still happens through SSO login.

  • SCIM events only apply to users who already have a Strike Graph account, and whose email domain is registered to your organization.

  • Emptying a role group entirely is not a reliable way to strip roles. Remove users from the group individually, or move them into a different role group.

  • Managers can still change roles and deactivate users inside Strike Graph. If you're managing roles from your IdP, we recommend treating the IdP as the source of truth and avoiding manual changes, since the next group event from your IdP will overwrite them.

  • Repeated events are safe. If your IdP re-sends a change that has already been applied, Strike Graph recognizes the current state matches and does nothing.

Troubleshooting

A role change didn't apply

Check the group's name first. It must contain both strikegraph and one of manager, auditor, or contributor. Then confirm the user has logged in to Strike Graph at least once — role mapping can only update an account that exists.

An auditor group isn't assigning the Auditor Role

The Auditor Role needs to be enabled for your organization. Contact your Customer Success Manager to confirm availability.

A user is still active in Strike Graph after being deactivated in the IdP

Confirm that provisioning and deactivation events are enabled in your IdP's Strike Graph application, and that the user's email address in your IdP matches the one on their Strike Graph account. If the addresses differ, Strike Graph can't match the event to an account.

A user's items have no owner

This is expected after a SCIM deactivation. A Manager can reassign controls, risks, and evidence to a new owner from each item's detail page.

Roles keep reverting

This usually means roles are being set manually in Strike Graph while your IdP is also managing them. Pick one source of truth — for most organizations using SCIM, that should be the IdP.

Need more help?

If you run into issues with SCIM provisioning, or you'd like help planning your group structure before you roll it out, contact our support team through the in-app messenger or reach out to your Customer Success Manager. We're happy to walk through the configuration with your IT team.