Why do SaaS misconfigurations cause so many breaches?

Why This Matters for Security Teams

SaaS breaches are rarely the result of a dramatic exploit alone. More often, they happen because the security boundary is defined by configuration, and configuration is easy to get wrong at scale. A permissive sharing rule, an overbroad admin role, or a logging setting left off can expose data immediately. That is why SaaS misconfiguration is so damaging: it turns an ordinary admin task into a direct breach path, without needing malware or zero-days. The pattern shows up repeatedly in NHI incidents too. NHIMG’s The 52 NHI breaches Report and Ultimate Guide to NHIs — Why NHI Security Matters Now both show how overlooked identity and access settings create outsized impact when systems are already connected, automated, and highly permissive. In practice, many security teams encounter exposure only after a shared object, token, or admin path has already been used, rather than through intentional testing of the control plane.

How It Works in Practice

SaaS misconfigurations become breaches because the service often enforces policy in ways that are powerful but not always intuitive. A tenant may have RBAC roles that look narrow on paper but still allow bulk export, app consent, or cross-workspace visibility. A default integration can inherit more privilege than expected. A missing audit trail can delay detection long enough for legitimate access to become an undetected data exfiltration path. The most effective way to think about this is as a control-plane problem, not a malware problem. Current guidance suggests that teams should review:

• default tenant settings, especially external sharing and API exposure
• admin role scope, including delegated and inherited permissions
• logging, alerting, and retention settings for identity and data access
• third-party app consent and service account permissions
• secret handling for integrations, including API keys and refresh tokens

This is where Azure Key Vault privilege escalation exposure and Salesloft OAuth token breach are useful reference points: both illustrate how exposed or overpowered access paths can be abused without a traditional exploit chain. Vendor and sector research also points in the same direction, including Anthropic’s first AI-orchestrated cyber espionage campaign report, which shows how compromised credentials and tool access can accelerate abuse once an attacker is inside a workflow. These controls tend to break down when SaaS estates sprawl across many tenants and teams, because ownership is fragmented and no single group sees the full permission graph.

Common Variations and Edge Cases

Tighter SaaS control often increases operational overhead, requiring organisations to balance breach reduction against user friction and admin workload. That tradeoff is real, especially in fast-moving environments where teams need self-service access, customer-facing collaboration, or rapid application onboarding. Best practice is evolving in a few areas. There is no universal standard yet for how much SaaS telemetry is enough, or how frequently every permission should be recertified across large tenant estates. In some businesses, the bigger risk is not broad access but hidden persistence, such as an old app registration, a stale OAuth grant, or a forgotten backup export path. In others, the issue is over-trusting “safe” defaults from the SaaS vendor and assuming the platform is secure unless a custom setting was changed. NHIMG’s MongoBleed breach is a reminder that exposed data stores and overly open configurations can create immediate impact, even without sophisticated attacker tradecraft. The practical answer is to treat SaaS configuration as a living security control: baseline it, monitor it, and test it continuously. Where organisations skip continuous review, the same few mistakes recur, and those mistakes often become the easiest path from misconfiguration to breach.

Related resources from NHI Mgmt Group

• Why do non-human identities create more risk than many human accounts?
• Why do non-human identities create more remediation risk than many human accounts?
• Why can a single SaaS app create such a large blast radius?
• How can organisations reduce the risk of token-based attacks in SaaS?