SaaS Security Best Practices: Shared Responsibility, SSO, OAuth Tokens, and Offboarding

Most breaches of software-as-a-service (SaaS) customers in the last two years did not involve a flaw in the vendor's code. In 2024, attackers logged in to Snowflake customer accounts with passwords stolen years earlier. In 2025, they used stolen OAuth tokens to read Salesforce records without signing in at all. Both were failures in the customer's half of the deal.

This guide covers securing the SaaS apps your company already uses: the split of responsibility, the two incidents above, identity, third-party app grants, configuration baselines, and an offboarding calculation. Choosing and reviewing vendors is in our SaaS vendor management guide, and reading a vendor's audit report is in our SOC 2 Type II guide. Cloud infrastructure you build yourself is covered in the cloud security posture management guide, and the whole-network design behind these controls is in the zero trust implementation guide.

Who is responsible for what

Microsoft's shared responsibility page states that for all cloud deployment types "you own your data and identities." For SaaS, the vendor manages the network and the platform underneath the application. You remain responsible for application configuration, access controls, and the client devices and endpoints that connect. Other vendors word it differently, but the split is the same.

A SOC 2 report describes the vendor's controls. It does not tell you whether you turned yours on.

Two incidents, two different gaps

Snowflake customers, 2024

In June 2024, Mandiant reported that a group it tracked as UNC5537 had stolen data from about 165 potentially exposed Snowflake customer organizations. It named three causes. The accounts had no MFA, so a valid username and password was enough. Credentials taken by infostealer malware were still valid, some from infections as far back as November 2020, because nobody had rotated them. And the customers had no network allow lists restricting logins to trusted locations. Mandiant also found that some initial infections were on contractors' laptops used for personal browsing and gaming, which gave one stolen credential a route into several client accounts.

Snowflake did not have a hole in its platform to fix. It has since set out a schedule to end single-factor passwords: mandatory MFA for human password users, and a move away from passwords for service accounts, with the last phase estimated for August to October 2026. Check the page for your account's actual dates.

Salesloft Drift, 2025

Drift, a chat tool owned by Salesloft, held OAuth tokens that let it read its customers' Salesforce data. Google's threat intelligence group reported that between August 8 and August 18, 2025 an actor it tracked as UNC6395 used those tokens to run queries against Salesforce objects such as Cases, Accounts, Users and Opportunities, then searched the results for secrets: AWS access key prefixes, Snowflake credentials, passwords and VPN or SSO login URLs. The actor deleted its query jobs but not the logs. On August 28 Google added that the Drift Email integration to Google Workspace was also affected, and that on August 9 the actor had read mail from a small number of Workspace accounts.

Salesloft's trust center reports Mandiant's finding of how it began: the actor had access to Salesloft's GitHub account from March through June 2025, then reached Drift's AWS environment and took the customer OAuth tokens. Salesloft and Salesforce revoked all Drift tokens on August 20. A customer with perfect MFA on every human login would have been affected just the same.

Three lessons apply to every SaaS tenant:

• A token is a credential that skips your login controls. You need an inventory of which apps hold one, and what each can read.
• Support tickets and case notes are a secret store whether or not anyone intended it. Google's advice to affected customers was to search Salesforce for key prefixes and passwords, then rotate anything found.
• Vendor compromise cannot be prevented, only made smaller. Narrow scopes, IP restrictions where the platform supports them, and a tested revocation runbook decide whether an incident like this costs you an afternoon or a breach notice.

IBM's 2026 Cost of a Data Breach study puts the global average cost at $4.99 million, a record, with a 247-day average lifecycle from breach to containment (IBM).

Identity: single sign-on, provisioning, and MFA that phishing cannot beat

Single sign-on (SSO) gives you one place to enforce MFA, one log of sign-ins and one switch to turn access off. Automated provisioning through SCIM extends that switch to accounts inside the app. Without SCIM, disabling a person in your identity provider blocks their SSO login but can leave a local account, API keys or active sessions in the app.

Choose the MFA method by the threat. SMS codes, one-time passwords and push approvals can be intercepted by a phishing proxy or approved by a tired user. The CISA fact sheet on phishing-resistant MFA urges organizations to adopt phishing-resistant methods (security keys and passkeys based on FIDO/WebAuthn, or smart cards) and, where an application cannot yet support them, to add controls such as number matching. NIST's SP 800-63B-4 requires a phishing-resistant authenticator at its highest assurance level (AAL3) and requires services assessed at AAL2 to offer one. It also allows syncable passkeys, which are convenient, at the lower level only.

A sensible order: phishing-resistant MFA first for administrators and anyone who can export data, then finance and engineering, then everyone. Keep two recovery paths for lost keys, and do not let the recovery flow fall back to an SMS code, or an attacker will simply choose that path.

The SSO surcharge

Some vendors sell SSO only on their top tier. The community-run SSO wall of shame lists price jumps for adding it, some more than triple the base plan (Canva, for one, lists $10 to $40 per user per month in an entry dated June 2024). Ask for SSO and SCIM pricing before you sign, since our SaaS contract negotiation guide covers what you can ask for at renewal. If the premium is out of reach, put the app on your short list for manual review and shorter offboarding checks, as the illustration below shows.

Third-party apps and OAuth grants

Every "sign in with Google" or "allow access" click creates a token that can outlive the user's password and their MFA enrolment. Set consent policy at the tenant level so the default is to ask an administrator:

• Microsoft Entra offers an admin consent workflow, so users who cannot consent themselves send a request to a reviewer instead.
• Google Workspace's API controls let you mark each app Trusted, Limited, Specific Google data or Blocked, and restrict which Google services unconfigured apps can reach.
• Salesforce began restricting use of uninstalled connected apps for end users from September 2025, with a new permission for administrators who approve them, as described in the Salesforce Admin blog.

Then keep an inventory: app name, who approved it, scopes granted, last activity, and a named business owner. Remove apps with no activity in 90 days. Make a revocation runbook for your top ten integrations that says exactly which admin console page to open and which secrets to rotate.

Misconfiguration: start with free baselines

CISA's Secure Cloud Business Applications (SCuBA) project publishes secure configuration baselines for Microsoft 365 and Google Workspace, plus no-cost assessment tools (ScubaGear for Microsoft 365 and ScubaGoggles for Google Workspace). CISA built them for federal agencies, but says any organization can use them. Binding Operational Directive 25-01 made the Microsoft 365 baselines mandatory for federal civilian agencies. For other SaaS tools with no published baseline, the vendor's own hardening guide and the admin audit log are the sources.

Typical findings: public or "anyone with the link" sharing left on, guest accounts that never expire, legacy authentication still enabled, mailbox forwarding to external addresses, and admin roles held by too many people. Rank them the way you would rank cloud findings, by whether the resource is exposed to the internet and whether it holds sensitive data, as the CSPM guide explains. Data classification and retention rules come from your cloud data governance program, and privacy obligations for SaaS-held personal data are in our SaaS data privacy compliance guide.

Offboarding: an illustration

Illustration: a company with 1,000 employees and 15% annual turnover, so 150 leavers a year. It uses 60 SaaS apps. All numbers below are assumptions we chose to show how the exposure adds up, not measured data.

In scenario A, the 8 missed apps produce 83% of the exposure although they are 13% of the apps. Moving 12 apps behind SSO cuts exposure by 54%. Shortening the review cycle for the remainder brings the total cut to 74%. The result depends heavily on the number of missed apps, so an inventory of accounts outside SSO is the first measurement to take.

Offboarding also covers what the departing person created: OAuth grants they approved, API keys they issued, and shared documents they own. Transfer ownership first, then revoke.

Where SSPM and CASB tools fit

SaaS security posture management (SSPM) products connect to your tenants through APIs and check settings against a baseline; cloud access security brokers (CASB) add traffic inspection and data loss prevention rules. They are useful when you run many tenants, when apps change settings faster than you can review, or when an auditor wants continuous evidence. They cannot fix a missing decision: someone must still decide who may approve OAuth apps and who gets phishing-resistant keys. Before buying, run ScubaGear or ScubaGoggles once and see how many findings you can close yourself. Vendors in this space also change quickly, so ask for a trial on your own tenant and verify the list of apps they support.

A 60-day order of work

1. Week 1: export the list of SaaS apps from your identity provider, expense reports and OAuth consent logs, and mark which sit outside SSO.
2. Weeks 1 to 2: require phishing-resistant MFA for administrators and turn off any admin account without MFA. Rotate credentials for any service account whose password has not changed in a year.
3. Weeks 2 to 4: switch tenant consent to admin approval, review existing grants, and remove unused ones. Write the revocation runbook for the top ten integrations.
4. Weeks 3 to 6: run the SCuBA baseline checks, or the vendor hardening guide, on your two most sensitive tenants and fix the exposed findings first.
5. Weeks 5 to 8: measure offboarding for the apps outside SSO, then decide app by app whether to pay for SSO, add SCIM or automate through a workflow tool.

Insurers ask about MFA and vendor access when you apply for cover, so this work has a policy side too; see our cyber insurance guide. For attacker tactics that use AI, including credential theft and impersonation, see the AI cyber threat intelligence guide.

Limits of this advice

The Snowflake and Drift accounts here come from vendor and incident-response reports, and later investigations may refine them. Drift's total number of affected organizations was reported differently by different sources, so we do not give one here. Product features and default settings change often; confirm them in the vendor's console before acting. Nothing here replaces advice from a qualified security architect who knows your systems.

This guide is for general information only. Consult qualified security and compliance professionals before changing your production configuration.