Identity provider compromise — the Entra ID / Okta incident-response playbook

Use this playbook when there are credible indicators that the identity control plane itself is compromised — not a single phished end-user, but the directory that issues everyone's tokens. Triggering conditions include:

• An administrative account in your Entra ID tenant, Okta org, ADFS, or Ping deployment is confirmed or strongly suspected taken over.
• A help-desk MFA or password reset is confirmed to have been social-engineered (the Scattered Spider pattern — voice phishing the IT help desk to reset MFA, documented in CISA advisory AA23-320A).
• Anomalous federation or application changes appear in the audit log: a new federated identity provider, a new app registration or service principal with fresh credentials, a new admin role assignment, or an illicit OAuth consent grant.
• Token theft or replay is observed — including the CVE-2025-55241 Actor-token class of abuse that bypasses MFA and Conditional Access.
• Mass SSO application enumeration from a single principal.

Do NOT use this playbook for: a single end-user account compromise with no IdP-plane access (run standard account-compromise IR), endpoint malware with no identity pivot, or an on-prem-only Active Directory compromise with no cloud IdP exposure (overlapping but distinct — AD tiering and DCSync hunting dominate there).

An IdP compromise runs against two independent clocks, and you must drive both from minute zero.

The containment clock. While the attacker holds the identity plane, dwell time converts directly into lateral expansion — every minute is a new app entered, a new token minted, a new persistence mechanism planted. There is no statutory deadline here; the deadline is operational. Target: all sessions and tokens for privileged accounts revoked within the first hour, full persistence eviction within 24 hours.

The notification clocks. The moment you establish that personal data was accessible or that an essential/important service is affected, the regulatory clocks attach — and they are shorter than the eradication will take:

• DORA (financial entities): initial notification within 4 hours of classification — see the DORA 4h/72h/1-month playbook.
• NIS2 (essential/important entities): 24-hour early warning — see the NIS2 Title 13 incident timeline.
• GDPR: notification to the supervisory authority within 72 hours of becoming aware, where a personal-data breach is likely.

An IdP compromise almost always qualifies as a personal-data breach, because the attacker held the keys to systems containing personal data — establish the notification posture in parallel with containment, not after it.

Goal: stop token minting and cut the attacker's live access without destroying the evidence you will need for the notification reports.

Preserve before you change. Export sign-in logs (interactive and non-interactive), the directory audit log, and risk detections *first* — mass remediation changes flood the audit log and some telemetry has short retention.

Containment checklist:

• Revoke sessions and refresh tokens before resetting passwords. A password reset alone does not invalidate an already-issued refresh token or an Actor-class token. In Entra, revoke sign-in sessions and lean on Continuous Access Evaluation; in Okta, clear user sessions and revoke OAuth tokens. Do this for the known-compromised accounts *and* every privileged account.
• Reset credentials and re-enrol phishing-resistant MFA (FIDO2 / passkeys / certificate-based) for all privileged accounts. Do not re-trust SMS or push — those are exactly what was social-engineered.
• Freeze high-risk help-desk reset flows. Suspend phone-based MFA and password resets for privileged and VIP accounts; require in-person or manager-verified, out-of-band confirmation for the duration of the incident.
• Disable the obvious persistence added during the window: any newly added federated identity provider (inbound/Org2Org federation), new app registrations or service principals, and new admin role assignments. Note timestamps before disabling.
• Scope the blast radius: which tenant/org, which admin accounts, which applications the compromised principal could reach.

Caveat: revoking sessions does not stop a tenant-level token-issuance abuse (the Actor-token class). If that vector is suspected, remediation has to happen at the tenant configuration and legacy-API level, not at the user-session level.

Goal: remove every backdoor the attacker planted so that revoking sessions actually ends the access. This is the phase teams skip, and it is why IdP intrusions recur within days. An attacker who held the directory does not rely on the account you just reset — they leave self-service re-entry.

Hunt and remove, in priority order:

• Rogue federation. A new federated identity provider or domain federation lets the attacker mint their own valid tokens. Scattered Spider specifically adds a federated IdP and activates account linking to elevate inside the SSO tenant. Review every trust relationship; remove any added during the window.
• App registrations and service principals. Enumerate apps with client secrets or certificates added during the window. A service principal with its own credential is a non-human backdoor that survives every user reset.
• Illicit OAuth consent grants. Hunt newly consented applications, especially high-privilege Graph/API scopes granted to attacker-controlled apps.
• Policy weakening. Diff Conditional Access / sign-on policies — look for new MFA exclusions, trusted-location additions, or disabled policies.
• New privileged identities. New Global Admins, new PIM-eligible role assignments, abused break-glass accounts, new B2B/guest invitations.
• Mailbox persistence (where the compromise pivoted to mail): inbox rules, forwarding, delegate grants.

Rotate everything the attacker could have reached: admin credentials, application client secrets and certificates, token-signing certificates (ADFS), and API tokens (Okta). A secret that was readable during dwell is a compromised secret.

Goal: confirm eradication, restore normal operations under tightened controls, and close the regulatory loop.

• Confirm eradication by configuration diff. Compare federation, app, service-principal, role, and policy state against a known-good baseline. If you cannot produce a known-good baseline, that gap is itself a finding for the lessons-learned.
• Rotate downstream secrets. Application secrets, keys, and tokens reachable *through* the IdP during dwell must be rotated even if you have no direct evidence they were taken — the attacker had the means.
• Restore help-desk flows under tightened verification. Re-enable resets only with the hardened identity-proofing you stood up in Phase A made permanent.
• Finalise the notification reports. Assess what personal data was accessible to scope the breach, and file or update the DORA / NIS2 / GDPR submissions from the single evidence base.
• Lessons learned and controls: mandate phishing-resistant MFA, harden help-desk identity proofing, alert on every federation/app-registration/consent change, enforce least-privilege admin with PIM, and turn on Continuous Access Evaluation. Then rehearse the scenario as a tabletop so the next response is muscle memory.

Capture each artefact with original timestamps preserved and chain-of-custody intact, because the same evidence base feeds the containment decisions *and* the regulator reports:

• Sign-in logs — interactive and non-interactive — covering the incident window plus 30 days prior.
• Directory audit log — directory changes, app registration and service-principal creation, federation configuration changes, role assignments, consent grants.
• Risk detections / risky sign-in export and any token-issuance telemetry available.
• Conditional Access / sign-on policy change history.
• Help-desk ticket and call records for the reset event that enabled initial access.
• Federation, application, and privileged-role inventory — before/after diff.
• Signed incident timeline — detection, every containment action, eradication completion — with no manual back-edits.

The structural problem a compromised IdP exposes is that the authoritative log is the surface the attacker just controlled. CVE-2025-55241 issued tokens that bypassed MFA and Conditional Access and left minimal audit trace; the Scattered Spider playbook deliberately weakens logging. Once the IdP log is unreliable, the only ground truth left is the traffic on the wire. The engineering position the Zero Hunt team takes here is the AI Traffic Analysis rail: a proprietary deep-learning model with four inference heads — suspicious traffic, malware classification, attack-type identification, application fingerprinting — running on the appliance GPU with no cloud callback, so the anomalous activity an attacker generates once the IdP is theirs (token replay against on-prem applications, unexpected service-to-service authentication, mass enumeration) surfaces independently of whatever the IdP audit log does or does not record.

Five anti-patterns observed across peer organisations responding to IdP compromise:

1. Resetting the password but not revoking sessions. A stolen refresh token or Actor-class token keeps working after a password change. Session and token revocation must come first — the password reset is secondary.

2. Evicting the user, not the persistence. Resetting the compromised account while leaving the rogue federated IdP, the attacker's service principal, or the illicit consent grant in place means the attacker re-enters on their own terms within hours. Phase B is not optional.

3. Trusting the IdP audit log as complete. MFA-bypass and Conditional-Access-bypass token abuse leaves minimal trace, and an attacker with directory control can weaken logging. Corroborate from network traffic and downstream application telemetry; do not declare eradication on the strength of a clean audit log alone.

4. Leaving the help-desk reset path open. If the vishing route that granted initial access is still live, the attacker re-compromises through the same door while you are still cleaning up. Freeze high-risk resets for the duration.

5. Re-trusting SMS or push MFA after the incident. Push-bombing fatigue and SIM-swap defeat exactly the factors that were just abused. Move privileged accounts to phishing-resistant FIDO2 / passkeys before you call the incident closed.

An IdP compromise rarely triggers a single obligation. Because the attacker held the keys to systems containing personal data, it is almost always a personal-data breach, and for regulated entities it stacks with the sectoral and horizontal cyber-incident regimes:

• EU financial entity: DORA Art. 19 4h/72h/1-month reporting, plus NIS2 Title 13 if also an essential/important entity, plus GDPR Art. 33 (72h), plus sectoral notifications.
• EU essential/important entity (non-finance): NIS2 Title 13 24-hour early warning + GDPR Art. 33 (72h).
• Any organisation holding personal data: GDPR Art. 33 (72h) at minimum, with Art. 34 individual notification if high risk to data subjects.

Build one evidence base and export per regime; do not let separate teams draft separate narratives, because supervisors compare them. Finally, expect the IdP compromise to be the *first* stage, not the whole incident — Scattered Spider and peers routinely pivot directory control into data theft and extortion, so run the exfiltration-only ransomware response in parallel once you see staging or bulk egress.