BIPI

Zero Trust Architecture for SaaS-Heavy Organisations in 2025: Identity as Perimeter and SaaS Security Posture Management

Cybersecurity

When your infrastructure is 90 percent SaaS, the network perimeter is meaningless. This post explains how to implement Zero Trust for SaaS-heavy organisations — identity as the new perimeter, continuous authentication, SaaS Security Posture Management tools, and the controls that actually reduce risk when you cannot touch the server.

By Arjun Raghavan, Security & Systems Lead, BIPI · September 17, 2025 · 11 min read

#zero-trust#saas-security#sspm#identity-security#architecture

The average enterprise uses 130 SaaS applications. Many use more than 200. In that environment, the traditional network perimeter — firewalls, VPNs, on-premise directory servers — protects a shrinking fraction of the organization's actual data and access paths. The SaaS applications hold the sensitive data. The identity layer connects users to those applications. Zero Trust in this context means treating the identity plane as the security perimeter and applying the same rigor to SaaS application access that the old network model applied to VPN access.

SaaS-heavy Zero Trust has two distinct problems. The first is access control: ensuring that every access request to every SaaS application is continuously validated based on identity, device health, and context. The second is configuration control: ensuring that the SaaS applications themselves are not misconfigured in ways that leak data, grant excessive permissions, or allow unauthenticated access. SaaS Security Posture Management addresses the second problem.

130+

average SaaS applications in use per enterprise, per Okta's Businesses at Work report 2025

43%

of SaaS data breaches in 2024 involved misconfigured sharing settings rather than authentication bypass

71%

of IT-approved SaaS apps have OAuth integrations with other apps that IT has not reviewed

In a SaaS-heavy organisation, a data breach is more likely to come from a misconfigured Salesforce sharing rule than from a network intrusion. The perimeter has moved inside the application.

Identity as perimeter — what this means operationally

Identity as perimeter requires an identity provider that acts as the authentication broker for every SaaS application. Okta, Azure Entra ID, and Ping Identity are the common choices. Every application access goes through the IdP; the IdP applies Conditional Access policies before issuing the session token. The network the user is on is one signal, not the gate. Device compliance, authentication method, user risk score, and access pattern are the signals that actually matter.

Continuous authentication means the session is not trusted for its entire lifetime after initial authentication. Risk re-evaluation should trigger step-up authentication or session termination when signals change — the user's device becomes non-compliant, a new IP appears in a different country, or the risk engine flags the session. This is the Continuous Access Evaluation model and similar features from Okta's Continuous Authentication.

SaaS Security Posture Management

SSPM tools continuously audit the configuration of SaaS applications against security benchmarks. They answer questions like: which Salesforce users have edit access to all accounts, which Google Workspace sharing settings allow external access, which Slack workspaces allow external file sharing, which GitHub organizations have 2FA enforcement disabled. The SSPM category is now well-served by commercial tools — Adaptive Shield, AppOmni, Obsidian Security — and is an increasingly standard component of a mature SaaS security program.

Salesforce misconfigurations most commonly found: sharing rules granting broad object access, guest user record access, Einstein Analytics exposed externally.
GitHub misconfigurations: organization-wide 2FA not enforced, legacy personal access tokens with broad scope.
Google Workspace: Drive sharing default set to anyone with link, Calendar sharing showing full event details externally.
Zoom: cloud recording shared to all participants by default, waiting room disabled for meeting links.

OAuth app sprawl — the shadow access problem

Every time an employee authorizes a new SaaS app connection — connect with Google, authorize Slack access — they create an OAuth grant that persists indefinitely, grants the third-party app access to corporate data, and is often invisible to IT. The Verizon 2025 DBIR notes OAuth abuse as a growing attack vector; attackers use phishing sites that mimic legitimate OAuth consent screens to obtain persistent access to Microsoft 365 or Google Workspace.

Controlling OAuth sprawl requires a combination of IdP policy (block OAuth consent for apps not in the approved catalog), SSPM monitoring (alert on new high-privilege OAuth grants), and periodic access reviews. This is an under-addressed risk in most organizations.

The SaaS-native SIEM gap

Traditional SIEMs ingest server logs. SaaS applications produce application audit logs — Salesforce Event Monitoring, Google Workspace Admin Audit, Okta System Log — that are structurally different from network and endpoint telemetry. Many SIEMs support SaaS log ingestion but most organizations have not configured it. Detecting account takeover via compromised Salesforce session or data exfiltration via Google Drive external share requires SaaS log analysis, not network monitoring.

Closing

Zero Trust for SaaS-heavy organisations is not a product purchase — it is an architecture decision and an operational discipline. Start by ensuring that every SaaS application goes through the IdP. Apply Continuous Access Evaluation. Deploy an SSPM tool and triage the highest-severity misconfigurations. Audit OAuth grants and implement approval controls for new grants. The threat model for SaaS data is identity compromise and misconfiguration — the perimeter controls you have built for network attacks do not address either.

Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.