One provisioning push, backdoor accounts in every connected app
Okta is the authoritative source your SaaS apps trust over SCIM. Weaponize that and a single assignment fans backdoor accounts and elevated roles into a dozen apps at once.
SCIM outbound provisioning means your downstream SaaS apps trust Okta as authoritative. That trust is exactly what an attacker with admin access turns into a fan-out.
How the attack works
The attacker creates a user in Okta that matches no HR-sourced identity, then assigns it to a group bound to a dozen SCIM-provisioned apps. Okta pushes the account to each connected app, creating local accounts with no app-side signup or approval, then propagates elevated role attributes the same way. Because the apps trust the source, the backdoor simply appears everywhere at once. This maps to T1136, Create Account, and T1199, Trusted Relationship.
Why it works
Provisioning normally rides an HR-sourced onboarding path, so the tell is an out-of-band provision push for a user with no authoritative source. The apps accept it because they trust Okta, which is the whole point of SCIM and also its weakness when the source is compromised.
How to fix it
Do not chase one app. Deactivate the seeded principal in Okta so SCIM triggers deprovisioning across every connected app at once, then verify removal app by app. Per-app resets miss apps and get re-provisioned on the next sync. For the lasting fix, anchor provisioning to an authoritative HR source, reconcile downstream app accounts against Okta, restrict who can assign users to SCIM apps, and alert on out-of-band SCIM creates. Scope the fan-out from the provision events in the System Log, since exposure is per app under different contracts and jurisdictions.
Practice it
We built this as a GraphLattice Range scenario so responders learn to pull a fan-out back at its trusted source.