When your SaaS security posture management (SSPM) platform is compromised, the attacker inherits admin-grade API access into every SaaS tenant it monitors, a map of their misconfigurations and, where remediation is enabled, the power to change their settings. An SSPM typically connects to the identity provider, collaboration suite, CRM, code platform and dozens of other SaaS applications through OAuth apps, service accounts and API tokens, many with directory-wide read scopes. The incident can start in your tenant of the platform (a stolen admin login, a leaked API key), in a browser extension or collector it deploys, or at the vendor, where one breach exposes the connector tokens of every customer. This playbook is for SaaS security, identity and incident response teams. It is vendor-neutral; the containment steps sit in each SaaS application, so confirm exact names in their documentation. Rollout and hardening are covered in the SSPM rollout playbook.
Key takeaways
- Contain in the SaaS tenants, not the SSPM console. The platform's power is a set of OAuth grants and tokens inside each application; disabling those stops the attacker even if the console is still exposed.
- Delegated and app-only grants need different actions. App-only connectors are stopped by disabling the app and removing its credentials; connectors that acted as an admin user also need that user's sessions and refresh tokens revoked.
- The posture report is a target list. Weak MFA policies, public sharing and over-privileged third-party apps it lists are the attacker's next step; close the worst during the incident.
- One vendor breach reaches many tenants. Rotate every connector the SSPM held across all applications, not only the one where misuse was seen.
- Reconnect read only, app by app. Restore with dedicated service identities, minimum scopes and remediation off until the review is done.
What the SSPM holds
This is our view of the common connection types and what each one gives an attacker.
| Connection | What an attacker gains | First containment action |
|---|---|---|
| Identity provider read access (users, groups, policies, apps) | The full identity map, MFA gaps and admin list (ATT&CK T1087.004 Cloud Account discovery) | Disable the integration app or revoke its API token |
| Collaboration suite app with directory and settings scopes | Tenant configuration, sharing settings, sometimes file and mail metadata | Disable the service principal or revoke the app's tokens |
| CRM, support and code platform connectors | Org configuration, connected apps, profile and permission set data | Revoke the connected app's tokens; block the app |
| Admin API tokens created by a person | Everything that admin can do; often far more than posture reads | Revoke the token; review the creator's other tokens |
| Remediation or write scopes | Ability to change policies, sharing and app approvals under a trusted name | Remove write scopes or the whole app first |
| Browser extension or endpoint collector (if deployed) | Visibility of SaaS use on endpoints and a code delivery path | Block the extension or collector through endpoint management |
| Ticketing, chat and SIEM outputs; platform admin and SSO | Webhook secrets, a trusted alert channel, control of every connector | Rotate secrets, disable admins, reset SSO trust |
How the compromise shows up
| Signal | Where you see it | What it can mean |
|---|---|---|
| The SSPM's app or service account signs in from unexpected IP ranges or at unusual times | Identity provider sign-in logs for service principals and API tokens | Connector credentials used outside the vendor's path (ATT&CK T1550.001 Application Access Token) |
| Data reads that posture checks do not need: file contents, mail, CRM records, bulk exports | SaaS audit logs, API event logs | Collection using posture scopes (ATT&CK T1213 Data from Information Repositories) |
| Write calls from a connector that should be read only | SaaS admin audit logs | Abuse of remediation scopes; check for new admins, apps and policy changes |
| New OAuth apps, consent grants, API tokens or admin role assignments | Identity provider and SaaS audit logs | Persistence across tenants (ATT&CK T1098.001, T1136.003) |
| Alerts suppressed, checks disabled or applications disconnected in the SSPM | The platform's own audit log | Hiding activity, in line with ATT&CK T1685 Disable or Modify Tools |
| Vendor notice asking customers to rotate integration credentials | Vendor status page, trust centre | Connector tokens exposed at the vendor |
Triage: the first hour
- Where did it start? Your platform tenant, a deployed extension or collector, or the vendor's shared service.
- List every connected application with the identity used (OAuth app, service account, personal admin token), its scopes, and whether it is app-only or delegated.
- Find the write scopes. Remediation, auto-fix and app approval features come first.
- Identify personal tokens. Tokens created by a human admin inherit that admin's privileges; identity platform documentation, for example, states that an API token carries the same permissions as the user who created it.
- Export the posture view the attacker could see: failing checks, risky third-party apps, users without MFA.
- Check for ongoing use in the last hours across the identity provider and the three most sensitive applications.
Containment by priority
- Remove write capability in every application: revoke remediation scopes, or disable the whole connector where scopes cannot be split.
- Disable app-only connectors. A major cloud identity provider's compromised application playbook recommends disabling sign-in for the service principal (
accountEnabledset to false) to give responders time to judge the impact of deletion or key rolling, and coordinating this with any wider eviction if admin accounts may also be compromised. - Revoke issued tokens. Use each platform's admin API or console to delete all tokens a user has issued to the connector's client ID. Revoking a connected app's access means it can no longer reach your data; revoke all tokens for the app, because platform documentation notes it can appear more than once. Revoke API tokens directly in applications that use them.
- Revoke delegated sessions. If a connector acted as an admin user, revoke that user's sessions; in documented cases this invalidates the user's refresh tokens and browser session cookies, and revocation can take a few minutes. It does not stop app-only access, which is why step 2 comes first.
- Block re-consent. Block the SSPM's apps in each application's third-party app controls so tokens cannot simply be reissued.
- Lock the platform tenant and remove extensions or collectors through endpoint management.
- Fix the top findings. Close the riskiest gaps the attacker saw: admins without phishing-resistant MFA, public sharing, high-privilege third-party apps.
Rollback: record every app, scope, token and block with its prior state. Reconnection uses new identities, so rollback never means re-enabling the old ones.
Credential rotation and trust reset
| Credential | Action | Check afterwards |
|---|---|---|
| Identity provider application secrets and certificates | Identity provider guidance: add the new credential, then immediately remove every old password and key credential on the application and on each service principal | No unexpected credential additions in the audit log |
| OAuth client secrets for connected apps | Reissue the secret, revoke all tokens for the old client | Token use for the old client stops |
| Admin API tokens | Revoke; replace with a dedicated service identity holding a read only admin role | No tokens tied to personal admin accounts |
| Service account keys and domain-wide delegation | Delete keys; remove and re-add delegation with minimum scopes | Old key IDs fail |
| Admin accounts used to authorise connectors | Reset credentials, revoke sessions, re-check MFA methods | No sign-ins from attacker ranges |
| Webhooks and SIEM keys | Rotate on both ends | Old signatures rejected |
For deeper per-platform steps see the Microsoft 365 Tenant Compromise Playbook, the Google Workspace Compromise Playbook and the Salesforce Org Compromise Playbook.
Eradication and rebuild
- New apps and grants: search every tenant for OAuth apps, consent grants, connected apps and API tokens created in the window.
- Admin changes: new admins, role assignments, MFA method changes and conditional access or sign-on policy edits.
- Sharing and forwarding: external sharing changes, public links, mail forwarding rules (ATT&CK T1114 Email Collection) and new domains allowed.
- SSPM tenant: remove unknown admins, tokens, integrations, exceptions and disabled checks; compare with the last reviewed policy set.
- Extensions and collectors: reinstall only from a verified source, or not at all until the vendor's root cause is known.
Recovery and reconnection
- Start with one application of lower sensitivity, using a new dedicated service identity and read only scopes.
- Verify behaviour for one full scan cycle: source IPs, API calls and volume should match the vendor's documentation.
- Add the identity provider and core suites next, then the long tail, once the pattern holds.
- Restrict by network where the application supports IP restrictions for the integration.
- Re-enable remediation last, for named actions with approval, after the post-incident review.
Where identity fits
An SSPM compromise is a non-human identity incident. Each connector is a machine identity: an OAuth client, a service principal, a service account with delegation, or an API token that should belong to a service but often belongs to a person. Three identity questions decide how bad it is.
- Who owns each connector? Connectors without a named owner are the ones nobody rotates; use the incident to assign an owner to every one that is reconnected.
- Is the grant app-only or delegated? App-only grants act on their own authority and keep working when users sign out; delegated grants depend on a user's refresh token and fail when that user's sessions are revoked. Record the type in the register so the next responder knows which lever to pull.
- Is the scope proportionate? Directory-wide read scopes are normal for posture tools, but mail, file content and full CRM data scopes rarely are. Each scope removed at reconnection shrinks the next incident.
The same register supports the wider programme: see the SaaS and OAuth App Governance Guide for ongoing review of third-party grants.
Scoping questions by application type
| Application type | Question to answer | Log to check |
|---|---|---|
| Identity provider | Did the connector read or change policies, admins or app assignments? | System or directory audit log, service principal sign-ins |
| Mail and collaboration suite | Were mailbox, file or chat contents read, or sharing changed? | Unified or admin audit logs, file access events |
| CRM and support | Were records queried or exported in bulk? | API event logs, export history, connected app usage |
| Code platform | Were repositories cloned or settings changed? | Organisation audit log, git access events |
| HR and finance applications | Were employee or payment records read? | Application audit trail, report runs |
Evidence to preserve and notification
- Identity provider logs: service principal and admin sign-ins, consent and app events for the window.
- SaaS audit logs: export from each connected application; retention differs widely by product and licence.
- SSPM audit trail: admin, token, check and integration history.
- Vendor communications: notices, case numbers and the vendor's scope statement.
SaaS tenants usually hold personal data, so if records were read the GDPR Article 33 rule may apply: notify the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware. See the Cyber Incident Reporting Requirements Map for other regimes, and your contract for the vendor's duties to you.
Decision guidance
| Situation | Choose | Trade-off |
|---|---|---|
| Vendor breach, no misuse seen in your tenants | Rotate every connector, keep monitoring on new credentials | Brief gap versus trusting the vendor's scope |
| Misuse seen in one application | Disconnect all applications, investigate each, reconnect in stages | Loss of posture visibility for days; use native admin reports meanwhile |
| Remediation scopes were enabled | Treat each tenant as compromised and run its full tenant playbook | High effort, but write access makes anything possible |
| Small estate, under 20 applications | Manual revocation and review per app | Quick, but needs a written list to avoid misses |
| Large estate, hundreds of applications | Prioritise identity provider, mail, files, CRM and code; script token revocation | Long tail may stay disconnected for weeks |
Detection and measurement
- Time to cut access: from declaration to all connectors disabled across applications.
- Connector inventory accuracy: connected applications with documented identity, scopes and owner.
- Personal tokens remaining: connectors still using tokens tied to human admins, target zero.
- Write scope count: connectors with write or remediation scope.
- Source alerting: alerts on connector sign-ins from outside the vendor's documented ranges, tested yearly.
Framework mapping
| Framework | Reference | Where it applies |
|---|---|---|
| NIST CSF 2.0 | RS.MA-01, RS.AN-03, RS.MI-01, RS.MI-02, RC.RP-05 | Response with the vendor, root cause, containment, eradication, verified restore |
| NIST SP 800-53 Rev. 5 | IR-4, IR-6, AC-2, AC-6, IA-5, SA-9, AU-6 | Incident handling, accounts, least privilege, authenticators, external services, log review |
| CIS Controls v8.1 | Control 5, Control 6, Control 8, Control 15, Control 17 | Accounts, access, audit logs, service providers, incident response |
| ISO/IEC 27001:2022 Annex A | 5.19, 5.22, 5.23, 5.24 to 5.28 | Supplier and cloud service security, incident management and evidence |
| MITRE ATT&CK | T1199, T1550.001, T1528, T1087.004, T1213, T1098.001, T1685 | Trusted relationship, token use and theft, discovery, collection, persistence, defence impairment |
Common failure patterns
- Revoking in the application where misuse was seen, and nowhere else. In the Salesloft Drift breach stolen OAuth tokens from one integration opened hundreds of customer tenants; integrations that span many applications need revocation everywhere.
- Forgetting old or unused connectors. The Klue OAuth breach turned on a forgotten integration credential.
- Revoking user sessions only. Session revocation does not stop app-only grants; the app itself must be disabled.
- Personal admin tokens as connectors. They inherit the admin's full rights and vanish or break when the person leaves.
- Restoring remediation by default. Write scopes recreate the most damaging path.
Practitioner checklist
- Keep a connector register: application, identity, scopes, grant type, owner.
- Remove write scopes first, then disable app-only connectors.
- Revoke tokens per client ID in every application, not just where misuse was seen.
- Revoke sessions for admins whose delegated grants the SSPM used.
- Block the apps from re-consent until reconnection.
- Hunt for new apps, grants, admins and sharing changes in each tenant.
- Fix the top posture gaps the attacker could see.
- Reconnect one application at a time with new read only identities.
- Export identity provider, SaaS and platform logs before retention expires.
Standards and references
- NIST: SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
- Microsoft: Compromised and malicious applications investigation
- Microsoft Graph: user revokeSignInSessions
- Google Workspace Admin SDK: Method tokens.delete
- Salesforce Help: Revoke access to connected apps
- Okta: Manage Okta API tokens
- MITRE ATT&CK: Use Alternate Authentication Material: Application Access Token
Related NHI Mgmt Group resources: SSPM integration security guide · SSPM health check · SaaS and OAuth App Governance Guide · Identity Provider Tenant Compromise Playbook