By Ryan Windt | Head of Growth Marketing | Updated April 2026
Most businesses now run on SaaS. Email, CRM, HR, finance, project management, collaboration, and customer support all live in cloud-hosted platforms that employees access from anywhere on any device. The operational benefits are real. So is the attack surface, and it is significantly larger than most organizations realize.
The 2025 Verizon Data Breach Investigations Report found that third-party involvement appeared in roughly 30% of all breaches, double the rate from the prior year. A significant share of those incidents trace back to SaaS environments: compromised OAuth tokens granting attacker access to connected platforms, misconfigured sharing settings exposing sensitive data, help-desk workflows manipulated to reset MFA factors, and legitimate application credentials used to authenticate to production systems without triggering a single alert.
The attacks that originate in SaaS environments are not exotic. They are predictable, repeatable, and in most cases preventable with controls that are well understood and practical to implement. What creates the persistent vulnerability is the gap between what organizations think they have configured and what the configuration actually allows.
This post covers why SaaS risk accumulates even in well-run organizations, the specific attack patterns that are generating claims, what the controls look like in practice, and how all of it connects to your cyber insurance posture.
Why SaaS Risk Keeps Growing
The core problem is that SaaS environments change constantly and the security implications of those changes are rarely visible to the people responsible for security.
A platform ships a new feature that creates a new sharing permission. An employee grants an OAuth consent to a productivity app that requests broad scopes. An integration is built that creates a service account with more access than it needs. A contractor is given guest access for a project and the access is never removed. None of these events generates an alert. None of them looks like an attack. But each of them expands the attack surface in a way that persists indefinitely unless someone actively looks for and closes it.
The shared responsibility model compounds the problem. SaaS vendors are responsible for the security of their platform infrastructure. You are responsible for identity configuration, data governance, application permissions, and third-party integrations. That boundary is clear in vendor documentation and almost never clear to the employees making configuration decisions in day-to-day operations.
The result is configuration drift: a gradual accumulation of permissions granted, integrations connected, and defaults left unchanged that collectively create an environment where a compromised credential or a malicious OAuth consent can propagate much further than it should.
The Four Attack Paths Generating Claims
Understanding which attack patterns are actually driving losses in SaaS environments matters because the controls that stop each one are different. The 2025 DBIR and claims data from carriers writing cyber coverage point consistently to four patterns.
Credential and session abuse. An attacker obtains valid credentials through phishing, infostealer malware, or a prior breach and uses them to authenticate to the victim’s SaaS environment directly. If MFA is not enforced, or if the attacker can bypass app-based MFA through a real-time phishing proxy or MFA fatigue attack, they are inside the environment with a legitimate session. From email, they can access connected applications, exfiltrate data, create forwarding rules to monitor future communications, and use the account to conduct business email compromise against the victim’s own clients or partners.
The Snowflake campaign of 2024 is the clearest recent illustration of this pattern at scale. Approximately 165 organizations had data stolen through their Snowflake environments. The vector in virtually every case was a customer account where MFA was not enforced. Attackers used stolen credentials purchased from infostealer malware markets to log in directly. No Snowflake vulnerability was involved. The attacker had valid credentials and the platform accepted them.
Malicious or over-scoped OAuth consent. OAuth allows third-party applications to access a user’s account data with that user’s permission. The problem is that users routinely grant consent without understanding what they are authorizing, and those grants persist indefinitely until someone explicitly revokes them. An application with read access to email and the ability to manage calendar events has access to sensitive communications and can monitor scheduling. An application with mail send permissions can send email impersonating the account holder. Many organizations have hundreds of OAuth grants across their tenant, the majority of which were authorized by individual employees without IT review and have never been audited.
Attackers distribute malicious OAuth applications through phishing campaigns, marketplace listings, and compromise of legitimate developer accounts. Once a user consents, the attacker has persistent access that survives password changes and, in many configurations, MFA resets.
Help-desk and identity manipulation. Attackers research target organizations, identify employees by name, and call IT support posing as that employee to request a password reset or MFA factor enrollment. When help-desk verification procedures rely on information that is publicly available (name, employee ID, department, manager), the verification is not actually verification. This is the attack vector that drove the MGM and Caesars breaches, the CDK Global follow-on attacks, and a significant share of the identity-based intrusions documented in CISA advisories since 2023. The MGM/Caesars post covers the full mechanics and what stopped similar attacks elsewhere.
Supply chain and integration compromise. Every third-party app connected to your SaaS environment inherits some level of your trust and your access. A compromised automation platform, a vulnerable connector, or a malicious update to a legitimately installed application can use those inherited permissions to exfiltrate data, move laterally, or establish persistent access. The MOVEit Transfer exploitation in 2023 affected hundreds of organizations through a shared file transfer platform. The attack did not require any vulnerability in the victims’ own environments. It exploited a trusted integration.
The Playbook: What to Actually Do
The controls below map directly to the attack patterns above and to what underwriters are now verifying in cyber insurance applications. They are organized by the order in which most organizations find it practical to implement them.
Inventory, tiering, and ownership
You cannot govern what you have not catalogued. The starting point is a living inventory of every SaaS application in use across the organization, every integration connecting those applications, and every high-risk data store. Assign a clear owner to each application and tier them by blast radius.
Tier 0 covers identity and email infrastructure (your IdP, SSO platform, email provider), RMM and PSA tools for MSPs, and any platform with administrative access to multiple downstream systems. A compromise of a Tier 0 application gives an attacker access to everything connected to it. Tier 1 covers core business data platforms: CRM, HRIS, finance systems, document repositories. Tier 2 covers ancillary applications with limited data access or connectivity.
The tiering determines how much scrutiny each application receives and how quickly gaps get addressed. A stale OAuth grant in a Tier 2 productivity tool is a different risk than a stale grant in a Tier 0 identity platform.
Identity hardening
Identity is the control plane for SaaS. If authentication and authorization are weak, every application connected to the environment is weak.
Enforce phishing-resistant MFA for all administrator accounts and all remote access. FIDO2 security keys and passkeys cannot be intercepted by adversary-in-the-middle phishing proxies. Standard app-based TOTP and push notification MFA can be. For Tier 0 systems and any account with the ability to modify authentication configuration, the standard matters. Our MFA implementation guide covers what carriers now require and how to document compliance for underwriting purposes.
Remove standing global administrator accounts. Replace them with just-in-time privileged access that requires an approved ticket, assigns time-limited elevation, and logs every action taken during the elevated session. No standing admin means no standing target for an attacker who obtains a credential. The PAM and cyber insurance post covers the implementation and what underwriters verify.
Configure conditional access policies to enforce device posture requirements, block access from high-risk geographies and anonymizing proxies, and require step-up authentication for sensitive actions. Block legacy authentication protocols entirely. Legacy auth bypasses modern MFA and continues to be a documented attack vector years after most organizations believe they have addressed it.
OAuth and app-consent governance
Disable end-user consent for third-party OAuth applications. Require all new integrations to go through an admin approval workflow with documented review. Allow only publisher-verified applications or those your team has explicitly reviewed and approved. Restrict application assignment to the users who actually need the integration rather than allowing tenant-wide access.
Inventory existing OAuth grants. Most organizations find dozens or hundreds of grants accumulated over years, many of which are over-scoped, unused, or connected to applications the company no longer uses. Revoke stale and over-scoped grants quarterly. Alert on new high-risk grants and unverified publisher applications in real time.
This is not a one-time exercise. OAuth governance requires an ongoing review cycle because the grant landscape changes every time an employee connects a new tool, and because legitimate applications are regularly updated with new permission requests that expand their effective access.
Platform-specific hardening
The specific configuration controls differ by platform, but the principles are consistent: disable defaults that allow oversharing, lock down inbox rules and mail forwarding, enforce modern authentication, and monitor for configuration changes.
For Microsoft 365: disable legacy authentication protocols, enforce modern auth, restrict mailbox permissions and external sharing defaults, monitor inbox rules and transport rules for changes, and protect against MFA factor enrollment without proper identity verification. For Google Workspace: block less-secure app access, enforce OAuth and app allowlists, govern external sharing and domain-wide delegation carefully. For major SaaS platforms in CRM, HRIS, finance, and development: define a hardening baseline per application and audit against it quarterly and after major releases.
Email security controls
Email is the entry point for phishing, BEC, and credential theft, and it is the most common first target once an attacker is inside a SaaS environment because of the forwarding rules, access to sensitive communications, and OAuth grants typically associated with email accounts. The email security controls post covers the full set of technical controls, specifically DMARC, DKIM, SPF, anti-phishing tooling, and mailbox rule monitoring, and how underwriters evaluate email security posture.
Logging, detection, and response
Centralize identity logs, email admin and audit logs, SaaS application audit trails, and API usage logs. Retain approximately 12 months where feasible. The 12-month retention window is not arbitrary: it reflects the median dwell time for slow-moving attacks and the investigation horizon that incident response firms routinely need to reconstruct an intrusion timeline.
Alert on specific high-signal events: new OAuth consent grants, mailbox rule and forwarding rule changes, privilege elevation, external sharing of sensitive documents, anomalous sign-in locations, and new MFA factor enrollments. These are the events that appear in the timeline of virtually every SaaS-based intrusion, and they are detectable in real time if logging is in place and alert policies are configured.
Maintain SaaS-specific incident runbooks. When a compromised account is identified, the response sequence is specific: revoke active sessions and tokens, disable the OAuth consent, snapshot logs before they roll off, cut external shares, notify data owners, and preserve evidence for forensic review. A generic IT incident response plan does not address this sequence. For a practical template, see the incident response plan post.
Backup and recovery for SaaS data
Recycle bins and version history are not backups. They are managed by the SaaS vendor, subject to the vendor’s retention policies, and accessible to an attacker who has compromised a sufficiently privileged account. For critical SaaS applications, add a third-party backup solution that creates independent, immutable copies of data that an attacker with access to your tenant cannot delete or encrypt.
Test restores against real recovery time objectives and document the results. Underwriters increasingly ask for restore test evidence as part of the backup verification process. A backup configuration that has never been tested is treated as a gap. The immutable backups post covers what the 3-2-1-1-0 standard looks like for SaaS data specifically.
MSP-specific guardrails
For MSPs, SaaS security controls apply to their own environment and to every client environment they manage. The aggregation risk is distinct: a compromise of an MSP’s PSA, RMM, or identity console can cascade across every client simultaneously. This is the scenario that drives the elevated underwriting scrutiny and premium that MSPs face.
Treat PSA, RMM, and identity platforms as Tier 0 with no exceptions. Enforce SSO with phishing-resistant MFA to all admin tools. Restrict access by IP or VPN where possible. Maintain separate service accounts per client tenant rather than universal credentials that span multiple environments. Rotate secrets automatically. Require approvals and dual control for high-risk RMM actions including mass script deployment, registry edits, and EDR uninstall. Codify help-desk verification with callback procedures to pre-verified numbers and multi-person approval for any privilege elevation.
The RMM hardening post and the MSP cyber insurance guide cover the full set of controls underwriters now verify for MSP submissions and how to document them for a renewal application.
What This Means for Your Cyber Insurance
SaaS-based intrusions generate the full range of cyber insurance losses: business interruption from compromised operational systems, data breach notification costs when customer data is exposed, BEC and funds transfer fraud losses from compromised email accounts, and third-party liability from client data exposed through a vendor’s environment.
Whether those losses are covered, and at what limits, depends on three things in your policy.
Whether your controls match your application. Cyber policies are underwritten based on the security posture you represent at application. If you stated that end-user OAuth consent is disabled and it is not, or that phishing-resistant MFA is enforced for administrators and it is not, a carrier can use that misrepresentation to dispute or deny a claim. The cyber insurance application and claim denial post covers how this plays out in practice and what documentation closes the gap.
Whether the incident trigger matches the policy language. A SaaS-based breach that originates from a compromised OAuth token or a misconfigured sharing setting may not fit neatly into the “unauthorized computer access” trigger that some policy forms use. Understanding how your policy defines covered causes of loss matters before you need to invoke it. The cyber insurance exclusions post covers the definitional limits that most commonly affect SaaS-origin claims.
Whether BEC and social engineering losses are covered at adequate limits. Many SaaS intrusions ultimately generate funds transfer fraud losses when an attacker uses a compromised email account to redirect wire transfers or authorize fraudulent payments. This coverage sits in the eCrime insuring agreement and is frequently sublimited well below the overall policy limit. The social engineering and funds transfer fraud post explains what to verify and what sublimits to check.
The Evidence Pack Underwriters Want
Carriers have moved from checkbox attestations to documentation. Here is what an underwriter reviewing a SaaS-heavy organization wants to see at application or renewal.
A current SaaS application inventory with tiering, showing ownership assignment and review dates. MFA enforcement reports from the identity provider showing enrollment status and method across all user accounts, with phishing-resistant methods documented for administrator groups. Conditional access policy screenshots showing device posture requirements, legacy auth blocking, and risk-based step-up rules. An OAuth consent policy showing that end-user consent is disabled and an admin approval workflow is in place, with a recent grant audit showing stale tokens revoked. Backup configuration documentation and a restore test result from the last 90 days. An incident response plan that includes SaaS-specific runbooks, with evidence of a tabletop exercise in the last 12 months.
Bringing this documentation to a renewal conversation is the difference between being priced on generic industry averages and being priced on your actual demonstrated posture. The cyber insurance requirements checklist maps each of these documentation requirements to the underwriting criteria carriers are applying in 2026.
The Bottom Line
SaaS is your business operating system. The controls that secure it are not optional extras applied on top of a basic security posture. They are the security posture, because identity and configuration are now the perimeter that everything else depends on.
The organizations consistently getting the best cyber insurance terms are the ones that have treated SaaS governance as a documented, repeatable program rather than an ad hoc collection of settings. They have app inventories that are current. They have OAuth grants that are audited. They have MFA enforcement that is provable. And they have logging that would let them reconstruct what happened if something goes wrong.
That documentation serves two purposes simultaneously: it reduces the likelihood of a claim, and it ensures coverage performs if a claim does occur.
SeedPod Cyber specializes in cyber and Tech E&O coverage for businesses of all sizes. Contact us for a coverage review or quote.