Why do SaaS breaches still happen even when the vendor has built security controls into the platform?

Why the platform can be secure while the tenant still gets breached

SaaS vendors usually secure the platform, but they do not fully control how each customer configures access, sharing, authentication, or connected apps. That means the breach often happens in the tenant’s usage layer: a stolen login, an overbroad role, a missed MFA setting, or a risky third-party integration can expose data even when the vendor’s core controls are sound.

The practical distinction is between product security and customer execution. A vendor can ship strong defaults, logging, and policy options, yet the customer still has to turn those options into an enforced operating model. When the tenant leaves gaps, attackers target the path of least resistance rather than the platform design itself.

This is why SaaS incidents so often look like account compromise, excessive privilege, or OAuth abuse instead of a classic software exploit. The platform remains intact, but the attacker uses legitimate access or legitimate-looking delegation to reach data and actions the customer did not intend to expose.

What usually fails in SaaS environments

The most common failures are control execution failures, not control absence. Credentials are reused or stolen, MFA is not consistently required, admin roles are wider than necessary, and old sharing or integration grants remain active long after the business need has changed. That creates a large attack surface even in a well-built SaaS product.

Connected apps and automations are especially important because they often inherit trust. A single approved integration can move data across services, expand the blast radius of a compromised account, or persist after the original owner has left. NHIMG’s SaaS-to-SaaS and OAuth App Governance Guide is a useful reference for understanding why consent, scopes, token revocation, and ownership matter so much in these environments.

Manual handoff gaps are another recurring issue. When access is approved in one team, configured in another, and reviewed by a third, responsibility becomes diffuse. The result is usually stale access, inconsistent enforcement, or a false assumption that the vendor or platform owner is handling a control that actually belongs to the customer.

Why this creates real breach exposure, not just compliance noise

Once a SaaS tenant account or integration is compromised, the attacker often behaves like a normal user. That makes the incident harder to detect than a noisy exploit, because the activity can blend into ordinary business use. Vendor controls may log the event, but if the tenant has weak alerting, poor review cadence, or broad standing privilege, the compromise can continue long enough to exfiltrate data or alter records.

Third-party and OAuth-driven compromise is a particularly common pattern. NHIMG’s Klue OAuth Supply Chain Breach and Vercel Context.ai OAuth Supply Chain Breach show how trusted SaaS-to-SaaS connections can become the access path even when the primary platform is not broken. The weakness is the delegated trust model, not necessarily the SaaS application itself.

For broader context on how stolen credentials and exposed tokens turn into downstream access, NHIMG’s The 52 NHI Breaches Report illustrates the same pattern across real-world cases: attackers tend to abuse identity material and trust relationships because they are efficient, scalable, and difficult to distinguish from legitimate operations.

Practitioner Guidance

What to verify: Treat SaaS security as a tenant control problem first. Verify that MFA is enforced everywhere it matters, that admin and privileged roles are genuinely minimal, and that connected apps have an owner, a purpose, and a revocation path.

What to prioritise: Focus first on the access paths that can reach production data or sensitive workflows. If a token, role, or delegated app can read, export, or modify critical records, it deserves faster review than lower-value configuration hardening.

What good looks like: Good SaaS hygiene means you can explain who can access what, why the access exists, when it was last reviewed, and how quickly it can be removed. If any of those answers depend on tribal knowledge, the control is weaker than it appears.

Practitioner takeaway: SaaS vendors can reduce risk, but they cannot absorb the customer’s responsibility for access governance. The strongest security posture comes from treating every tenant, role, token, and integration as an enforceable control boundary.

Related resources from NHI Mgmt Group

• Why do weak identity controls still lead to breaches even in mature security programmes?
• Why do Mac security controls still depend on user behaviour even when the platform is strong?
• Why do DDoS attacks still disrupt modern services even with strong security controls?
• Why do SaaS CRMs create compliance risk for PHI even when the platform has basic security features?