What Is SaaS Security? Risks and Controls

A finance team signs up for an expense tool on a Friday, connects it to the company Google Workspace with an OAuth grant, and shares a folder of receipts with "anyone with the link." No firewall saw it. No endpoint agent logged it. The security team learns the app exists three months later, when a researcher reports the receipts are publicly indexed. Nothing was hacked. The default settings did exactly what they were set to do.

That is the shape of most SaaS incidents. Not a kernel exploit, a misconfigured tenant, an over-scoped token, or an account with no multi-factor authentication. SaaS security is the practice of controlling the parts of a hosted application you are still responsible for, which is more than most teams assume and almost never the parts they instinctively reach for.

This guide defines SaaS security, draws the line the shared responsibility model actually draws, walks the risks that produce real breaches, and lays out the controls that move the number. It stays on SaaS security broadly. The discipline of continuously scoring and remediating one tenant's posture, SaaS security posture management, is its own topic and is deferred here.

What is SaaS security?

SaaS security is the set of policies, controls, and monitoring that protect the data, identities, and configurations inside software-as-a-service applications, the apps your organization uses but does not host or operate. Think Microsoft 365, Salesforce, Slack, Workday, GitHub, Zoom. The vendor runs the code and the infrastructure. You run the tenant: the users, the data, the sharing rules, the third-party app connections, and every setting the vendor exposed to you.

The reason it needs its own discipline is that the traditional perimeter does not apply. There is no network you control between your users and the app. There is no host you can put an agent on. The application lives at someone else's URL, reachable from any browser, anywhere, by anyone holding a valid credential. Your controls are the ones the vendor lets you configure through their admin console and their API, plus whatever identity and monitoring you wrap around the login.

That changes what "securing" means. You are not patching the software or hardening the server. You are deciding who can authenticate, what they can reach once they do, how data is allowed to leave, which external apps get a token, and how you would see an account being abused. SaaS security is configuration and identity work, not infrastructure work. It sits inside a broader cloud security program, but it is the slice where the customer holds the most control and, in practice, takes the most blame.

The SaaS shared responsibility model

Every cloud service splits duties between the provider and the customer. SaaS pushes the split further toward the provider than any other model, which is exactly why customers get caught. The provider carries so much that it is easy to assume they carry the rest. They do not.

In a SaaS arrangement, the provider is responsible for the physical data centers, the network, the servers, the operating system, the runtime, the application code, and keeping the service patched and available. When a vulnerability is found in the application itself, the vendor fixes it. You do not.

The customer is responsible for everything that is specific to their use of the app:

• Data. What you put in, how it is classified, who it is shared with, and how it leaves. The vendor stores it. You decide its exposure.
• Identity and access. Who has an account, how they authenticate, what role and permissions they hold, and whether dormant or departed users still have access.
• Configuration. Every tenant-level setting: default sharing, external collaboration, link policies, admin roles, audit logging. The vendor ships defaults that favor adoption, not security.
• Third-party access. OAuth grants and plugins that connect other apps to this one. A token you approved is a door you opened.
• Endpoint and usage. The devices and sessions that reach the app, and whether your own people use it safely.

The line is consistent across vendors even though the wording differs. The provider secures the application; the customer secures their use of it. Most SaaS breaches land entirely on the customer side of that line, because that is the side where misconfiguration, over-permissioned identities, and unmanaged tokens live. The provider can ship a perfectly secure product and you can still expose every record in it with one sharing setting.

SaaS security risks

The risks that produce real incidents are not exotic. They cluster in a handful of categories, all on the customer side of the responsibility line.

Misconfiguration. The single most common cause. Default-open sharing, public links, guest access left wide, audit logging disabled, overly broad admin roles. Each app has hundreds of settings and a new one ships with every feature release. Configuration drifts as people change settings to get work done, and a tenant that was hardened at go-live is not hardened a quarter later.

Identity and account takeover. SaaS apps are reachable from anywhere, so a stolen credential is a working credential. Accounts without multi-factor authentication, reused passwords, and weak session controls are the most direct path in. Attackers do not break the app; they log into it. Phishing for SaaS credentials and session tokens is a primary technique precisely because it lands them inside trusted apps with no malware to detect.

Over-permissioned access. Users accumulate roles they no longer need, service accounts hold admin rights they never use, and departed employees keep access because deprovisioning lagged. Least privilege erodes quietly. When an account is taken over, its blast radius is whatever it was allowed to reach.

Third-party app and OAuth risk. Modern SaaS is interconnected. Users grant third-party apps OAuth scopes that read mail, files, and contacts, often persistent and often unreviewed. A single malicious or breached integration can exfiltrate data without ever touching a password, because the token is the access. This supply-chain path bypasses MFA entirely once granted.

Shadow IT. Apps adopted by teams without security review. Each one holds company data, defines its own sharing rules, and is invisible to a program that does not know it exists. You cannot secure, monitor, or offboard an app you have never heard of.

Data exposure and exfiltration. The end state of the risks above. A misconfigured share, an abused account, or a rogue integration ends in data leaving. Because the data sits in the vendor's cloud and moves over normal HTTPS, traditional data-loss controls at the network edge see none of it.

SaaS security risks at a glance

Read the table and one thing repeats: the control is almost never a patch. It is identity, configuration, and visibility. That is what a SaaS security program is built from.

How to secure SaaS applications

The controls follow the risks. None of them is the vendor's job, which is the point.

Centralize identity. Put every SaaS app behind single sign-on through one identity provider so authentication, MFA, and deprovisioning are enforced in one place instead of per app. When someone leaves, one offboarding action cuts access everywhere, instead of a checklist of forgotten logins. Strong identity and access management is the foundation of SaaS security, because identity is the perimeter once the network one is gone.

Enforce MFA everywhere, with no exceptions for service accounts or admins. The accounts attackers want most are the ones teams most often exempt for convenience. Phishing-resistant factors beat one-time codes against credential theft.

Harden the tenant configuration to a baseline and keep it there. Set secure defaults for external sharing, link access, guest accounts, and admin roles. Turn audit logging on, on day one, because you cannot investigate what was never recorded. Then re-check the baseline on a schedule, because every feature release adds settings and every busy week adds drift.

Apply least privilege and review it. Grant the minimum role, prefer time-bound and just-in-time elevation for admin work, and run periodic access reviews to claw back the permissions that crept. Kill dormant and orphaned accounts.

Govern third-party access. Inventory the OAuth grants and plugins connected to each app, review their scopes, revoke what is unused or over-scoped, and require approval before a new integration gets a token. Treat an OAuth grant like a key to the building, because it is.

Discover shadow IT. You cannot protect apps you do not know about. Use SSO logs, expense data, and discovery tooling to surface unsanctioned apps, then bring them under management or shut them down. Pair discovery with a fast, sane sanctioning path so people stop going around you.

Monitor and respond. Centralize SaaS audit logs into your SIEM and alert on the abuse patterns that matter: impossible-travel logins, mass downloads, new OAuth grants with broad scopes, admin role changes, audit-logging being disabled. The goal is to see an account being used wrong while it is happening, not at disclosure time.

These controls are mutually reinforcing. SSO makes deprovisioning real, which makes least privilege enforceable, which shrinks the blast radius when an account is taken over, which the monitoring is there to catch. Run them as a system, not a checklist.

Frequently Asked Questions

What is SaaS security?

SaaS security is the practice of protecting the data, identities, and configurations inside software-as-a-service applications your organization uses but does not host, such as Microsoft 365, Salesforce, or Slack. Because the vendor runs the infrastructure and code, SaaS security focuses on the customer's side: who can log in, what they can access, how data is shared, which third-party apps are connected, and how misuse is detected.

Who is responsible for SaaS security?

Both parties, split by the shared responsibility model. The provider secures the application, the servers, the network, and the underlying infrastructure, and patches the software. The customer secures their use of the app: their data, user identities and access, tenant configuration, and any third-party integrations they approve. Most SaaS breaches occur on the customer side, through misconfiguration, weak identity controls, or over-permissioned access.

What are the biggest SaaS security risks?

Misconfiguration is the most common, from insecure default sharing and disabled logging to overly broad admin roles. The others are account takeover from stolen or unprotected credentials, over-permissioned and stale access, risky third-party OAuth grants that can exfiltrate data without a password, shadow IT apps adopted without review, and the data exposure that any of these can cause.

How is SaaS security different from cloud security?

Cloud security is the umbrella over all cloud models, including infrastructure (IaaS) and platform (PaaS) services where you manage operating systems, networks, or runtimes. SaaS security is the slice for fully hosted applications, where the customer manages almost none of the stack and instead controls identity, data, configuration, and integrations. SaaS shifts the most responsibility to the provider, leaving the customer a focused but high-stakes set of controls.

Does multi-factor authentication secure SaaS apps?

MFA is one of the most effective single controls because SaaS apps are reachable from anywhere, which makes a stolen password directly usable. MFA blocks most credential-based account takeovers. It is necessary but not sufficient: it does nothing against a malicious OAuth grant, a misconfigured public share, or an over-permissioned account, so it works alongside SSO, configuration hardening, least privilege, and monitoring.

What is the SaaS shared responsibility model?

It is the agreement that divides security duties between the SaaS provider and the customer. The provider handles physical security, infrastructure, the network, the operating system, and the application code, including patching. The customer handles their data, identity and access management, tenant-level configuration, and third-party app connections. SaaS pushes more onto the provider than IaaS or PaaS, but the customer still owns the controls where most breaches happen.

The bottom line

SaaS security is the work of protecting what you put into apps you do not run. The vendor secures the software; you secure your use of it, and that line is where almost every SaaS breach happens. The risks are mundane and repeatable: a misconfigured share, an account without MFA, a role nobody trimmed, an OAuth token nobody reviewed, an app nobody knew about.

So are the controls. Centralize identity behind SSO, enforce MFA without exceptions, harden the tenant to a baseline and hold it there, apply least privilege, govern third-party access, discover the shadow IT, and monitor for abuse. Run them as one reinforcing system. The perimeter moved to identity and configuration, and so should the defense.