SaaS Security for CISOs: Misconfiguration, OAuth Apps, Identity and Ownership

TL;DR: Software-as-a-service (SaaS) security is the work of protecting data, access, connected apps and compliance in applications a vendor hosts and runs for you. The vendor secures the platform, and the customer owns configuration, identity, permissions, data sharing and connected apps. Most failures start on that side: misconfigured settings, over-permissive OAuth integrations and stolen or misused credentials. Each app needs a named owner, regular review and a few counts the board can track each quarter.

What is SaaS security, and which part does the customer own?

Software-as-a-service (SaaS) security is the work of protecting data, access, connected apps and compliance in applications that a vendor hosts and runs for you. The short answer on ownership is that the provider runs the platform and the customer owns what sits on top of it. In Orca Security's framing of the shared responsibility model, the vendor secures the platform; you secure configuration, identity, and data.

That split leaves the customer fewer levers than in other cloud models. You cannot patch the provider's code or harden its servers. Control is limited to configuration, identity, and integration layers rather than application or infrastructure code, so those layers are where a security team does its work.

The customer side covers configuration, identities, permissions, data sharing and connected apps. Each of these can be changed by any administrator on any afternoon, often without the security team knowing.

Public guidance treats configuration as the customer's job. The Cybersecurity and Infrastructure Security Agency (CISA) published, under its Secure Cloud Business Application (SCuBA) project, recommended cybersecurity M365 configuration baselines for Microsoft 365 tenants. The National Institute of Standards and Technology (NIST) control catalog includes AC-2 for account management and CM-6 for configuration settings, both of which a reader can map to SaaS admin consoles.

The three risk areas this guide covers

Orca's summary puts the common failures on the customer side: misconfigurations, over-permissive integrations, and stolen or misused credentials, not platform-level exploits. The rest of this guide takes them in turn.

• Misconfiguration. Settings that expose data, such as public sharing left on after setup.
• OAuth apps and integrations. Third-party tools a user or admin approved once, holding access nobody reviews.
• Identity. Accounts, roles and credentials, including people who left and kept a login.

A closing section deals with ownership: who inside the company answers for each app, since the provider will not.

One tool category comes up throughout. SaaS security posture management (SSPM) is automated software that identifies misconfigurations, unnecessary user accounts, excessive user permissions, compliance risks inside SaaS apps. For other terms, see the glossary.

Where do SaaS breaches start?

Most SaaS breaches start at an ordinary place: a setting, a permission or a credential that sits on the customer's side of the line drawn in the previous section. The cases below show how each one turns into an incident. For a running record of disclosed incidents, see our cyber incident reports.

Settings left open

No stolen password was needed. A guest profile set too wide was enough.

Accounts with more access than the job needs

BetterCloud puts overprivileged account access first on its list of SaaS security challenges. Its reasoning is simple: the more access there is, and the higher it goes, the more risk if an account is compromised. Admin role names differ from app to app, so least privilege is hard to apply evenly.

Files shared too widely

In a 2025 BetterCloud survey, 53% of respondents named sensitive files shared publicly as their top concern out of eight. The everyday version is a user who shares a file publicly for convenience and does not realize it is indexed by Google in real time.

Artificial intelligence (AI) tools add a newer path. BetterCloud's 2025 State of SaaS Report, which surveyed over 600 IT professionals, found that 56% report external data oversharing. The report ties it to shadow AI, meaning unsanctioned AI tools, and unchecked file sharing.

Tokens held by a connected vendor

This path runs around your own login controls.

• Attackers breached Anodot, an AI-powered anomaly detection platform, and stole authentication tokens it held for customer Snowflake environments. They used those tokens to take data from over a dozen Snowflake accounts.
• Attackers abused compromised OAuth tokens from Gainsight-published applications connected to customer Salesforce environments. Salesforce revoked all active access and refresh tokens tied to the apps.

In our reading, the common thread is that the vendor's token carried the customer's trust. After any vendor breach, the first question is which tokens that vendor held and what scopes they carried.

Why are OAuth tokens and connected third-party apps a separate risk?

A user login is checked each time. After that, the connected app holds a token that keeps calling the SaaS platform's application programming interface (API) without a password prompt, a multi-factor challenge or a single sign-on check. If an attacker steals that token, they inherit the standing access and skip every control built around the login page.

That is why we treat integrations as their own risk category, separate from user identity.

The AI integration problem

The Anodot case covered earlier shows the pattern at its sharpest. The attackers also picked their moment, timing the campaign for Good Friday to exploit slower holiday response. Valence Security's analysis adds a design point that matters for any AI rollout: AI tools like Anodot need broad, persistent access to production data by design. Its conclusion is that as more AI tools connect to data infrastructure, "the integration layer becomes the attack surface."

In our reading, this puts every AI pilot that connects to a data warehouse or CRM on the same footing as a third-party vendor with a service account. It should be reviewed that way. The AI governance guide covers the approval side.

Other ways tokens leak

Tokens do not only leak from vendor breaches.

• Consent abuse. Victims entered a code on Microsoft's real login page.
• Developer supply chain. Compromised node package manager (NPM) packages tied to Zapier automation workflows were used to steal API keys, OAuth tokens, and CI/CD secrets, meaning continuous integration and delivery credentials, from developer machines.
• Browser extensions. Researchers found five malicious Chrome extensions aimed at Workday, NetSuite and SuccessFactors that stole tokens and hijacked sessions.

What to ask your team

1. List every connected app with access to each core SaaS tenant, along with its scopes and who approved it.
2. Find out which tokens have no expiry, and who can revoke them quickly.
3. Check whether device code sign-in is restricted. For the Microsoft 365 campaign, the advice was to restrict device code use, tighten consent policies, and monitor for anomalous token activity.
4. Set a regular review of integration permissions. One analysis recommends minimizing long-lived non-human identities to limit damage when a trusted provider is breached.

In our reading, duration matters as much as scope. In the Nikkei Slack incident, long-lived sessions, permissive integrations, and broadly shared channels raised the potential impact.

Why does identity sit at the center of SaaS security?

Every SaaS control comes back to an account: who holds it, what it can do, and whether it should still exist. An attacker who obtains a valid identity inherits whatever that identity is allowed to touch. Misconfigurations and connected apps raise or lower that reach.

AppOmni lists identity management as a core SaaS risk, noting that weak authentication processes or compromised credentials may allow unauthorized access to sensitive information. BetterCloud traces the difficulty to fragmented user stores across hundreds of apps, which without central management produce inconsistent provisioning and permission levels.

Why least privilege is hard to apply in SaaS

The principle is simple: give each user the minimum access the role needs. Applying it across many apps is not. In BetterCloud's account, admin role names vary from app to app, and some apps offer little difference between an admin and an ordinary user. The same guide ties risk to the breadth and height of access held when an account is compromised.

What the Stryker case shows

In March 2026, Stryker said a cybersecurity attack disrupted its Microsoft environment, affecting order processing, manufacturing and shipping. The company found no evidence of ransomware or malware. Valence frames the incident as disruption of a trusted SaaS administration layer that became an operational crisis.

In our reading, the lesson is about dependency. Production and logistics at a manufacturer can rest on the same tenant that runs email and sign-in. When that administration environment stops working, the business stops with it, and no file has to be encrypted for that to happen.

Three steps follow from that, in our view:

• Treat admin accounts in the identity and productivity tenant as the most protected accounts you have. Keep them few, named and separate from daily-use accounts.
• Hold emergency access accounts outside normal sign-in paths, and test them.
• Ask operations leaders which order and shipping steps still run if the tenant is unavailable. Write down the answer.

Identity review belongs on the same calendar as configuration review. It is the layer where least privilege either holds or quietly erodes.

How do SSPM, CSPM and CASB compare?

The three tool types share vocabulary but watch different layers. SaaS security posture management (SSPM) checks how SaaS apps are set up. Cloud security posture management (CSPM) checks the wider cloud estate. A cloud access security broker (CASB) governs how users reach cloud services and what data moves through them.

CSPM also carries a function SSPM tools generally lack: it identifies vulnerabilities attackers can exploit in cloud software. SSPM in turn goes deeper into user permissions inside each app.

The CASB and SSPM lines have blurred. According to Palo Alto Networks, CASBs traditionally focused on user access and data security policies but neglected the security of the app itself. Posture checks were later folded into CASB products. When a vendor describes its product as both, ask which of the three functions in the table it performs in practice.

Why drift favors continuous checks

Configuration drift is the problem SSPM is built for. Security teams often miss setting changes because, as Palo Alto Networks puts it, app audits are infrequent across the hundreds of apps that need assessing. In our reading, a quarterly manual review cannot keep pace with admins changing sharing defaults in between.

Matching the tool to the estate

Where a company's workloads sit should drive the choice. Businesses that rely heavily or exclusively on SaaS, rather than PaaS or serverless computing, may get more value from SSPM than from a broader CSPM tool.

In our reading, the practical test is a simple inventory:

• List where sensitive data lives: SaaS tenants, cloud accounts, or both.
• Note who changes settings in each. Business-owned SaaS admins point toward posture monitoring.
• Check whether access policy is already enforced at the identity provider or needs an inline broker.

In our reading, a company running mostly on SaaS will often find the posture gap larger than the access gap. In our reading, a company building on its own cloud infrastructure needs CSPM coverage first.

What do CISA's SCuBA baselines and BOD 25-01 say?

The Cybersecurity and Infrastructure Security Agency (CISA) runs the Secure Cloud Business Applications (SCuBA) project. In our reading, it is the closest thing to a public, free reference for what a hardened SaaS tenant looks like. CISA established the project in 2022 to address gaps exposed by SaaS intrusions. Its main audience is federal, but all organizations can use SCuBA.

The parts of SCuBA

The project's first guidance set had three pieces, per the 2022 fact sheet:

• Technical Reference Architecture (TRA): a security guide for cloud deployment, secure architecture and zero trust frameworks.
• Extensible Visibility Reference Framework (eVRF): a way to identify visibility data that can mitigate threats, see how far specific products provide it, and find visibility gaps.
• Microsoft 365 (M365) configuration baselines: recommended settings, with Google Workspace (GWS) baselines then under development.

Two assessment tools turn the baselines into checks. ScubaGear covers M365 tenants and ScubaGoggles covers GWS. Both evaluate tenant controls against CISA's baselines and generate visual reports. ScubaGear is a no-cost assessment tool, and CISA reported it passed more than 30,000 downloads. Users include the private sector, critical infrastructure and state and local governments.

CISA's case for the tools rests on misconfiguration. It cites a cloud vendor report that, in the first half of 2024, misconfigurations were the initial access point for 30% of cloud environment attacks.

What BOD 25-01 requires

CISA issued Binding Operational Directive (BOD) 25-01 on December 17, 2024. It requires Federal Civilian Executive Branch agencies to comply with a defined set of the baselines, deploy automated assessment tools, and remediate deviations. The directive binds only those agencies, though CISA strongly recommends all stakeholders implement these policies.

How a private-sector CISO can use it

We think the practical value is a neutral yardstick. Run ScubaGear or ScubaGoggles against a test or production tenant, then compare the report with what your SaaS posture tool already flags. Gaps in either direction are worth a ticket.

Treat the required list as a floor, not a full program. Record each deviation you accept, with an owner and a reason, so the exception survives staff turnover. A federal mandate does not transfer to you, but a documented comparison against it gives the board a reference point it can understand.

Who owns SaaS security inside the company?

Ownership is where SaaS programs tend to stall. The tools and baselines covered earlier only help if someone is named to act on what they find.

One model: the CMS SaaS Governance program

At CMS, SaaS Security Posture Management (SSPM) runs as an initiative of a central SaaS Governance program. The program provides the tooling, and all CMS SaaS teams are encouraged to onboard; tooling is free. The platform sends an alert to the appropriate stakeholders when potential issues are identified.

The remediation burden stays with the teams that run each app. CMS tells them they will need to analyze and remediate any security gaps that are discovered, as well as maintain proper SaaS configurations. The central team helps with analysis, but each application team should come prepared with its own resources to fix findings.

Two practical details carry over to any company. Onboarding takes about 1 to 2 weeks per app. An app only qualifies if its vendor can provide visibility into system settings via Application Programming Interface (API). That second point belongs in procurement, before a contract is signed.

A split we think works

In our reading, the CMS pattern of central tooling with local remediation scales well. We would add explicit roles for information technology (IT) and for the chief information security officer (CISO).

The app owner row is the one most often left blank. We think every app above a set data sensitivity needs a named person in the business, and that a company running many business units can route this through a business information security officer (BISO).

The CISO row matters most during an incident. A compromised SaaS tenant can raise a disclosure question quickly, and the CISO should be the person who brings the facts to the group that decides. Our Item 1.05 materiality decision guide covers that handoff, and CISO accountability covers where the line of responsibility sits.

What to check this quarter

• Pull the list of sanctioned SaaS apps and confirm each one has a named business owner.
• Confirm IT holds administrator rights, and that those rights are not shared across business teams.
• Agree on a time window for remediating findings, by severity, and record who signs off on exceptions.
• Check that SaaS incidents have a written path to the CISO and onward to the disclosure group, consistent with your reporting structure.

What a security leader can do this quarter

The thresholds are ours to suggest, not rules from any framework. Pick a figure for each, write it down, and apply it the same way to every tenant.

1. Build one inventory. Pull sanctioned apps from single sign-on (SSO) and procurement records. Then find the unsanctioned ones in expense reports and browser or network logs. Tag each app with the data it holds. Also record whether the vendor exposes settings through an application programming interface (API), because that decides whether posture tooling can watch the app. CMS says its SaaS security posture management (SSPM) platform is compatible with over 40 SaaS applications.

2. Review OAuth grants and integration tokens. Then check whether device code sign-in is open to users who have no need for it. Export every third-party grant and revoke any grant that has no owner or no recent use. For each integration that remains, set a maximum token lifetime and a rotation date.

3. Remove standing admin rights. Move administrators to time-bound elevation wherever the platform supports it, and recount admin accounts every month. That is a vendor claim. Treat it as a direction to aim for, not a benchmark. Set a dormant-account cutoff as well: disable accounts with no sign-in past that date, then delete them.

4. Restrict external sharing. Make internal-only the default, and require external links to expire. In BetterCloud's 2025 research, 53% of respondents named sensitive files publicly shared as their top concern. Run a one-time sweep of existing public links before the new defaults take effect.

5. Name an owner for every app. Each app needs two people. A business owner accepts the risk, and a technical owner fixes the findings. Any app still without an owner at quarter end goes on the removal list.

Four counts for the board

Report the same four counts every quarter so the trend matters more than any single figure. For a wider plan, see the first 90 days guide. For how directors use counts like these, see board cybersecurity oversight.

What this guide does not cover

This guide does not cover how providers secure their own platforms. Treat the suggested thresholds and targets as starting points to adapt, not requirements. For the rules and the record behind it, see What Does a CISO Do? Responsibilities, Reporting Lines and Required Skills.