SaaS security is the set of practices that protect your data, users and configuration in applications you rent from a provider over the internet. The provider runs the infrastructure. You decide who has access, how it is configured and what is shared, so the security work is mostly identity, settings and visibility.
What counts as SaaS?
NIST SP 800-145 defines the cloud model with three service models. In Software as a Service, the capability given to the consumer is to use the provider's applications running on a cloud infrastructure. They are reachable from various client devices through a thin client such as a web browser, or a program interface. Web-based email is NIST's own example.
The definition also draws the boundary. The consumer does not manage or control the underlying cloud infrastructure, including network, servers, operating systems and storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.
Compare that with the other models. Platform as a Service lets you deploy your own applications onto the provider's infrastructure, and Infrastructure as a Service gives you more control of lower layers. In SaaS you control the least, which makes the few controls you do have more important.
What is inside SaaS security?
Think in four areas.
Identity and access. Who can sign in, how, and with what privileges. This includes single sign on, multi-factor authentication, role design, and removing access when people leave.
Configuration. The limited settings the definition mentions. Sharing defaults, retention, external access and integration permissions all sit here. CISA's SCuBA project exists because misconfiguration and visibility gaps were behind SaaS intrusions, and it publishes secure configuration baselines for Microsoft 365 and Google Workspace.
Data. What information goes into the app, who can export it, and whether it is classified before it goes in. A tool that only holds public marketing copy needs less than one holding customer records.
Visibility. Logs of sign-ins, sharing and administrative changes, and a list of which apps your people actually use.
How is it different from securing your own software?
You cannot install an agent on the provider's servers, patch their operating system, or inspect their code. You depend on their assurances: independent audit reports, contract terms and published security documentation. You gain a provider who patches the platform for every customer at once, which many small teams could not match.
So the discipline changes from "harden my server" to "choose carefully, configure tightly and watch access." Vendor due diligence, such as asking for audit reports and reading breach notification terms, becomes part of security, not only procurement.
A constructed example
A company stores sales contacts in a CRM service. The provider keeps the platform patched and available. Meanwhile the company's administrator account has no second factor, a former contractor still has an active login, and a reporting integration holds broad read access to every contact. If any of those leads to a breach, the platform was never at fault. The security failure belongs to the customer side of the line that NIST's definition draws.
How to check or apply this
- Classify each app by the data it holds and its business criticality.
- Read the provider's security documentation and any independent audit reports before you adopt it, and again at renewal.
- Enforce single sign on and multi-factor authentication for every user, with extra protection for administrators.
- Use secure configuration baselines where they exist, and record exceptions with an owner.
- Review third-party integrations and remove stale ones.
- Turn on audit logs and decide who reviews them and how often.
- Document how to revoke access and export data for each app.
Quick check
What is the difference between SaaS and PaaS security?
In SaaS you use the provider's finished application and control only identity, settings and data. In PaaS you deploy your own application on the provider's platform, so you also secure that code.
Who is responsible when a SaaS tenant is misconfigured?
Usually the customer, because configuration is the part of SaaS that the customer controls.
Sources
- NIST SP 800-145, The NIST Definition of Cloud Computing, fetched 18 October 2026.
- CISA: Secure Cloud Business Applications (SCuBA) Project, fetched 18 October 2026.
Last reviewed: 18 October 2026.
