Cybersecurity for SaaS Companies: Threats and Controls

A SaaS company holds many customers' data and access in one shared platform, so a single stolen token, mis-scoped query or compromised build pipeline can become every customer's incident at once. That concentration changes the security priorities compared with an ordinary business: customers judge you on assurance reports and secure defaults, regulators increasingly treat cloud services as critical infrastructure, and attackers target the integrations and tokens that connect you to customer systems. This guide covers the threats specific to software providers, the regulations and customer requirements that apply, the controls to prioritise at each stage of growth, how to measure them and the failure patterns behind recent incidents. It is written for CTOs, heads of security and engineering leaders at SaaS providers, from early-stage startups to established platforms. It does not repeat architecture detail covered in the Multi-Tenant SaaS Architecture Security Guide, and buyers securing the SaaS they consume should read the SaaS Security Guide.

Key takeaways

Your blast radius is your customer base. Tenant isolation failures, stolen integration tokens and build compromises affect every customer, so treat them as the top risks rather than generic perimeter threats.
Regulation reaches SaaS through several routes. NIS2 covers cloud computing service providers, including SaaS; GDPR makes you a processor; DORA and sector rules arrive through financial and public sector customers' contracts.
Secure defaults are now a sales requirement. The CISA Secure by Design pledge asks for MFA, no default passwords, manufacturer patching and customer-facing audit logs, and enterprise buyers check for them.
Production access is the crown jewel. Engineers, support staff, CI/CD pipelines and service accounts that reach production need phishing-resistant MFA, just-in-time elevation and full logging.
Customer tokens are your liability. OAuth tokens and API keys you hold for customer integrations must be encrypted, scoped, monitored and revocable at scale, as the Salesloft Drift breach showed.

The SaaS threat picture

SaaS providers inherit every web application threat, but four features make the profile distinct: multi-tenancy, a highly automated delivery pipeline, privileged support and operations access, and deep integrations into customers' other systems. Attackers have learned that compromising one provider can be more productive than attacking its customers one by one, which ATT&CK captures as T1199 Trusted Relationship.

Threat	How it plays out for a SaaS provider	ATT&CK	Priority control
Customer account takeover	Credential stuffing and infostealer credentials against customer tenants that lack MFA	T1078.004 Cloud Accounts	MFA on by default, SSO, bot and credential stuffing protection
Integration token theft	OAuth refresh tokens or API keys you store for customer integrations are stolen and replayed	T1528 Steal Application Access Token, T1550.001 Application Access Token	Encrypted token vault, narrow scopes, anomaly detection, mass revocation runbook
Build and dependency compromise	Malicious dependency, poisoned CI tool or stolen publishing token ships code to all tenants	T1195.002 Compromise Software Supply Chain	Pinned dependencies, isolated build secrets, signed artefacts
Production and support access abuse	Phished engineer or support agent uses admin consoles to read tenant data	T1078.004 Cloud Accounts, T1538 Cloud Service Dashboard	Phishing-resistant MFA, just-in-time access, customer-visible access logs
Cloud credential leakage	Long-lived cloud keys in repositories, container images or tickets	T1552.005 Cloud Instance Metadata API, T1098.001 Additional Cloud Credentials	Workload identity federation, secret scanning, short-lived credentials
Bulk data theft and extortion	Attacker exports tenant data from storage or the application and demands payment	T1530 Data from Cloud Storage	Egress and volume alerting, per-tenant encryption keys, tested recovery

Two further SaaS-specific issues sit outside ATT&CK. Cross-tenant data exposure through authorisation bugs (OWASP API Security Top 10 2023 API1:2023 Broken Object Level Authorization) is the most common way a single defect becomes a multi-customer breach. Abuse of free tiers and trials for spam, crypto mining or phishing hosting harms your reputation and your provider relationships. See the Top 10 SaaS Security Risks and the API Security Guide.

Regulation and customer assurance

Most SaaS companies meet security requirements first through customer contracts and questionnaires, then through law as they grow or enter regulated markets. Confirm status and scope with counsel for your own services; laws in this area are still being implemented.

Requirement	How it applies to SaaS	Key obligations
EU NIS2 Directive (2022/2555)	Recital 33 places cloud computing services, including SaaS, in scope; cloud providers, managed service providers and online marketplaces fall under the Member State of their main establishment in the Union	Article 21 risk management measures (including supply chain security, incident handling and MFA); early warning within 24 hours, incident notification within 72 hours, final report within one month. See the NIS2 Directive Guide.
EU Cyber Resilience Act (2024/2847)	Recital 12 says SaaS, PaaS and IaaS as such fall under NIS2, not the CRA; cloud functions are in scope only as remote data processing solutions of a product with digital elements	Relevant if you ship installable software, agents, SDKs or devices with cloud back ends. See the EU Cyber Resilience Act Guide.
GDPR and UK GDPR	Usually a processor for customer data, a controller for your own account and marketing data	Article 28 processor terms, Article 32 security of processing, notifying the controller of breaches without undue delay. See the GDPR Compliance Guide for Security Teams.
UK NIS Regulations 2018 and Cyber Security and Resilience Bill	Cloud computing services are covered as relevant digital service providers; the Bill amending the regime was at report stage in the Commons in 2026	Track the Bill's final scope and reporting duties
EU DORA	Applies to financial entities, which must impose contractual terms on ICT third-party service providers; the most critical providers can be designated for direct oversight	Audit rights, incident support, exit plans and subcontracting terms in bank and insurer contracts. See the DORA Guide.
EU Data Act	Applies from 12 September 2025, including rules for customers switching between data processing service providers	Data export, switching support and interoperability. See the EU Data Act Guide.
SOC 2, ISO/IEC 27001, CSA STAR	Market requirements rather than law; the usual price of entry for enterprise deals	Independent attestation or certification of controls. See the SOC 2 Guide and ISO 27001 Guide.
FedRAMP and sector schemes	Needed to sell cloud services to US federal agencies; healthcare and payments customers bring HIPAA and PCI DSS duties	Authorised baselines, continuous monitoring. See the FedRAMP Guide.

The UK NCSC's 14 Cloud Security Principles are a useful self-assessment lens because they are written from the customer's side: principle 3 (separation between customers), 9 and 10 (user management, identity and authentication), 12 (secure service administration) and 13 (audit information and alerting for customers) are where buyers probe hardest. Answer questionnaires once, well, with a trust centre and reusable evidence; see the Security Questionnaires Guide and Cloud Security Alliance CCM and STAR Guide.

Secure by default for customers

The CISA Secure by Design pledge sets seven goals for software manufacturers, including SaaS: increase MFA use, remove default passwords, eliminate classes of vulnerability, make patching easier (for SaaS, the provider patches), publish a vulnerability disclosure policy that authorises good-faith testing, issue CVEs with accurate CWE and CPE fields, and give customers logs to detect intrusions. Translated into product features:

Authentication: MFA on by default for new tenants, passkeys or WebAuthn supported, SAML and OIDC single sign-on available on every plan rather than only the top tier, and an option for tenants to require SSO. See the Phishing-Resistant MFA Guide.
Customer audit logs: sign-in, admin change, API token creation, data export and support access events, retained for a stated period and exportable to customer SIEMs by API or streaming.
Admin controls: SCIM provisioning, granular roles, IP allow lists and session limits so customers can apply their own policy.
API and integration controls: scoped, expiring API tokens with owner and last-used metadata; OAuth apps that request narrow scopes. See the SaaS API Token Security Guide.
Vulnerability disclosure: a published policy and security.txt, with a defined triage SLA. See the Bug Bounty and Vulnerability Disclosure Guide.

The Snowflake breach is the reference case: infostealer credentials worked against around 165 customer accounts that lacked MFA, with no flaw in the platform itself. Snowflake later announced a phased block on single-factor password sign-ins. Customers' responsibility did not prevent the reputational damage landing on the provider.

Protecting production and the delivery pipeline

Production access

Phishing-resistant MFA for all staff: FIDO2 security keys or platform passkeys for engineers, support and finance, enforced at the identity provider.
Just-in-time elevation: no standing production admin; time-boxed, approved, logged access with break-glass accounts sealed and monitored. See the Privileged Access Management Guide and Break-Glass Emergency Access Guide.
Support tooling: support consoles should show tenant data only with a ticket reference and, for sensitive tenants, customer approval; log every view and make it visible to the customer.
Separate environments and accounts: production in its own cloud accounts or subscriptions under an organisation with guardrails. See the Cloud Landing Zone Security Guide.

Delivery pipeline

Source control: SSO and MFA for the code host, branch protection, required reviews and no long-lived personal access tokens with organisation-wide scope. See the GitHub and GitHub Actions Security Guide.
Build isolation: CI jobs use OIDC federation to the cloud rather than stored keys; publishing and deployment secrets exist only in the job that needs them.
Dependencies and artefacts: lock files, dependency review, SBOMs for every release and signed images verified at deploy. See the Software Supply Chain Security Guide.
Secure development: threat modelling for tenant boundaries, authorisation tests in CI and verification against OWASP ASVS 5.0. See the Secure Software Development Lifecycle (SSDLC) Guide.

Where identity fits: tokens and machine identities

A SaaS platform runs on non-human identities: service accounts between microservices, CI/CD identities, cloud roles, and the OAuth tokens and API keys customers grant you to reach their other systems. That last group is the most dangerous because it is a store of access to other companies. In the Salesloft Drift breach, an attacker with access to Salesloft's GitHub account reached the Drift AWS environment where customer integration tokens were held, then used them to export Salesforce data from organisations that Google Threat Intelligence Group put at over 700 potentially affected. Controls that follow:

Token vault: encrypt customer tokens with keys held in a KMS or HSM, ideally per tenant, and allow decryption only from the integration service's workload identity.
Least scope: request the narrowest OAuth scopes and document them for customers.
Behavioural monitoring: alert when an integration token suddenly makes bulk queries or calls from unexpected networks.
Mass revocation: rehearse revoking and re-issuing every token for one integration, and notifying affected customers, within hours.
Secrets out of data: scan support tickets and CRM records for pasted credentials and redact them.

See the Startup Identity and Secrets Security Guide and Secrets Management Guide.

Priorities by company stage

Stage	Focus	Do first	Can wait
Early stage (under about 50 staff)	Avoid fatal mistakes	SSO and phishing-resistant MFA for staff, no long-lived cloud keys, secret scanning, tenant authorisation tests, backups, MFA available to customers	Formal certification, 24x7 SOC
Growth (first enterprise customers)	Prove it	SOC 2 Type II or ISO 27001, customer audit logs, SSO on all plans, VDP, incident response plan with customer notification, vendor risk process	Dedicated red team
Scale (regulated customers, several regions)	Operate it	NIS2 and DORA contract readiness, just-in-time production access, per-tenant keys, 24x7 detection, regular penetration testing and threat-led exercises	Nothing on this list

Implementation phases

Assess (weeks 1 to 4): inventory production access paths, CI secrets, stored customer tokens and tenant isolation tests; map gaps against the CISA pledge goals and NCSC principles.
Close the fatal gaps (months 1 to 3): enforce staff MFA, remove standing production admin and long-lived cloud keys, turn on secret scanning with push protection.
Customer features (months 2 to 6): ship MFA by default for new tenants (pilot with new sign-ups first, keep an admin override during rollout), customer audit logs and SSO on all plans.
Assurance (months 3 to 12): run a SOC 2 or ISO 27001 readiness assessment, then the audit; publish a trust centre.
Operate and test: 24x7 alerting on production access and token anomalies, an annual penetration test, tabletop exercises for a multi-tenant incident.

Rollback and safety: roll out customer-facing changes such as default MFA or SSO enforcement behind feature flags per tenant cohort, so you can pause a cohort if support tickets spike without reverting the policy for everyone.

Detection, measurement and framework mapping

Log at three levels: cloud control plane (CloudTrail, Azure Activity, Google Cloud Audit Logs), identity provider and code host, and the application itself (tenant ID on every event, support access, data exports, token use). See the Cloud Logging and Audit Trail Guide.

Staff phishing-resistant MFA coverage: target 100% of accounts with production or code host access.
Standing production admin accounts: target zero outside sealed break-glass accounts.
Customer MFA or SSO adoption: percentage of active tenants and of admin users protected.
Long-lived secrets: count of cloud keys and integration tokens older than policy, trending down.
Cross-tenant authorisation test coverage: share of API endpoints with automated tenant boundary tests.
Time to revoke: measured time to revoke all tokens for one integration in an exercise.

Control area	NIST CSF 2.0	NIST SP 800-53 Rev. 5
Supplier and customer contract requirements	GV.SC-05, GV.SC-07	SA-9, SR-3
Staff and customer authentication	PR.AA-03	IA-2
Least privilege for production and integrations	PR.AA-05	AC-6
Secure development and tenant isolation	PR.PS-06	SA-8, SA-11, SC-7
Data protection and per-tenant encryption	PR.DS-01	SC-7
Monitoring of platform and tokens	DE.CM-09	SI-4, AU-6
Customer and regulator notification	RS.CO-02	IR-6

Common failure patterns

Security features behind the top price tier: SSO, audit logs and MFA enforcement sold as upgrades, leaving most tenants exposed and attracting criticism from enterprise buyers.
Customer tokens stored like configuration: integration OAuth tokens in a general database or environment reachable from development tooling, the pattern in the Salesloft Drift case.
Tenant ID trusted from the client: authorisation that accepts a tenant or object ID from the request without checking it against the session.
Code host as the soft entry: engineers' source control accounts with weaker controls than production, giving access to secrets, workflows and deploy keys.
No multi-tenant incident plan: incident response that assumes one victim, with no way to determine which tenants were affected or to notify hundreds of controllers within contract and NIS2 timelines.
Certification as the goal: a SOC 2 report obtained with controls that only exist for the audit window.

Lessons from incidents

Snowflake (2024): customer accounts without MFA turned infostealer logs into a mass data theft. Make strong authentication the default rather than an option.
Salesloft Drift (2025): a code host compromise led to the store of customer OAuth tokens. Isolate and encrypt customer tokens, and be able to revoke them all quickly.
LiteLLM (2026): a compromised security scanner in CI stole a package publishing token. Keep publishing credentials out of jobs that run third-party tools. See the LiteLLM PyPI package breach.

For response, see the Vendor SaaS Breach Response Playbook and OAuth Token Theft Incident Playbook.

Practitioner checklist

Enforce phishing-resistant MFA for every staff account with production, code host or support console access.
Remove standing production admin; use just-in-time, logged elevation and sealed break-glass accounts.
Replace long-lived cloud keys in CI with OIDC federation and keep publishing secrets out of scan jobs.
Encrypt stored customer integration tokens under KMS-held keys and rehearse mass revocation.
Ship MFA by default, SSO on all plans and exportable customer audit logs.
Run automated cross-tenant authorisation tests on every API endpoint.
Confirm whether NIS2, DORA contract terms, GDPR processor duties and sector schemes apply, and record the decision.
Publish a vulnerability disclosure policy and security.txt.
Write and exercise a multi-tenant incident plan with customer notification templates.
Track the six metrics above monthly and report them to leadership.

Standards and references

Related NHI Mgmt Group resources: Multi-Tenant SaaS Architecture Security Guide · SaaS and OAuth App Governance Guide · SOC 2 Guide · Startup Identity and Secrets Security Guide · Open Source Cloud Security Tools Landscape Guide. This guide summarises NIS2, the Cyber Resilience Act, GDPR, DORA and the Data Act as they apply to SaaS providers and is not legal advice.

Cybersecurity for SaaS Companies Guide: Threats, Regulation and Priority Controls