SCIM provisioning for SSO

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 Strike Graph user accounts directly. Strike Graph's SSO login flow creates an account the first time a user signs in, so a user who has been provisioned in your IdP simply logs in and gets an account.

Roles for users who haven't signed in yet. If you add someone to a Strike Graph role group before they've ever signed in, Strike Graph holds that role for them as a pending invitation, which appears in your organization's pending invitations list. When they sign in through SSO for the first time, their account is created with the role from their group — no manual step needed. No invitation email is sent, so your IdP stays in charge of who gets access. Removing them from the group before they sign in cancels the pending role.

Existing users moving to SSO. If someone already has a Strike Graph account (for example, they previously signed in with a password) and starts signing in through SSO, Strike Graph keeps their existing account and applies their group role to it. They're matched by email address, as long as the email's domain belongs to your SSO connection.

Deactivation works differently: if you deactivate someone in your IdP who has never signed 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

Starting with v2.119.0, group naming rules are changing. Group names must follow the exact pattern StrikeGraph-<Role>-<OrgExtId> (for example, StrikeGraph-Manager-8b1c2d3e-4f50-4a6b-9c7d-0e1f2a3b4c5d). The flexible naming convention described below will no longer work: the organization ID is now a required part of every group name. If you are already using SCIM role groups, update your group names in your IdP before or shortly after this release to avoid role sync interruptions.

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 used to resolve the role and, if you have more than one Strike Graph organization, the organization (see below). Otherwise they don't need to match anything else in Strike Graph.

If you have more than one Strike Graph organization

Starting with v2.119.0, the organization ID is required in every group name, not just for multi-org setups. All groups must follow the StrikeGraph-<Role>-<OrgExtId> pattern. Additionally, for organizations with the multi-org users feature enabled, adding a user to a role group for an organization they don't yet belong to will automatically add them to that organization with the group's role. This means your IdP groups can fully control which organizations a user has access to, not just their role within an organization.

If your company has more than one Strike Graph organization — for example, a parent organization and one or more subsidiaries — each role group should name the organization it applies to. Add that organization's Strike Graph ID anywhere in the group name, and create one group per organization and role:

• acme-strikegraph-managers-8b1c2d3e-4f50-4a6b-9c7d-0e1f2a3b4c5d

• acme-strikegraph-contributors-8b1c2d3e-4f50-4a6b-9c7d-0e1f2a3b4c5d

Your Customer Success Manager can give you the ID for each of your organizations.

When a group name includes an organization ID, Strike Graph applies that group's role changes only in that organization, so a person who holds roles in several organizations is never affected in the others. As a safeguard, a change is applied only when every group member who already has a Strike Graph account belongs to the named organization. If a member doesn't, if the ID doesn't match one of your organizations, or if the name contains more than one ID, the change is skipped.

Group names without an organization ID keep working as before, which is the right choice when you have a single Strike Graph organization.

How role changes are applied

Starting with v2.119.0, removing a user from a role group that includes an organization ID can now fully remove that user from the named organization, rather than just demoting them to Contributor. If the user is not in any other Strike Graph role group for that organization, they are deactivated from it (the same effect as a Manager removing them). If they are still in another role group for the same organization, they take that group's role instead. This only applies to groups whose name includes an organization ID.

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:

• Each role group applies its role in one Strike Graph organization: the one named by the organization ID in the group's name or, without an ID, the organization its members belong to. A role group should only contain users who belong to that 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

Starting with v2.119.0, a deactivated user who is explicitly added back to a role group (with an organization ID in the name) is automatically reactivated in that organization with the group's role. Their role no longer defaults to Contributor after reactivation through a group. Reactivation through a full-state group sync (where the user is simply still listed) does not reactivate them, so an intentional deactivation is not undone by routine IdP sync cycles.

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 directly. First-time access still happens through SSO login, and a role assigned through a group before then is applied when the user first signs in.

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

• Put each user in at most one Strike Graph role group per organization. If a user is in two groups for the same organization with different roles, their role follows whichever group changed most recently.

• The SCIM userName your IdP sends must match the SAML NameID exactly, including capitalization. In Microsoft Entra ID both use the user principal name by default — don't add a transformation (such as lowercasing) to only one of them, or the same person can end up with two separate identities.

• 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. If you have more than one Strike Graph organization, also confirm the name includes exactly one organization ID, that it's the right one, and that every member of the group belongs to that organization. If the user hasn't signed in yet, that's expected — the role is applied on their first SSO sign-in.

If role changes were missed in the past, restart provisioning for the Strike Graph application in your IdP. Your IdP will resend full group membership, and Strike Graph will bring roles back in line.

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.