Zero trust SaaS needs visibility before access control can work

At a glance

What this is: This analysis argues that Zero Trust for SaaS depends on continuous visibility into apps, identities, tokens, and integrations before access control can be enforced reliably.

Why it matters: It matters because IAM, NHI, and SaaS security teams cannot govern what they cannot inventory, and blind spots turn least privilege into policy theatre.

By the numbers:

• 30% of all breaches involved third-party relationships, up from 15% the previous year, often through credential exposures or misconfigurations.
• 22% of organizations had an attack path identified in the cloud, while 40% of attack paths include lateral movement based on non-interactive remote code execution.

Context

Zero Trust in SaaS is an identity and telemetry problem before it is an access policy problem. The article argues that fragmented SaaS estates, third-party integrations, service accounts, and OAuth-connected apps make enforcement unreliable when discovery is incomplete.

For identity programmes, the issue is not whether controls such as least privilege, RBAC, or token rotation exist in theory. The issue is whether they are anchored to a live inventory of apps, identities, and data flows across the SaaS stack.

The article also makes clear that unmanaged SaaS connectivity creates governance blind spots across both human and non-human identities, which is why visibility has to precede any meaningful Zero Trust enforcement.

Key questions

Q: What breaks when SaaS visibility is incomplete in a Zero Trust model?

A: Zero Trust breaks at the point of enforcement. If teams cannot see the full set of apps, identities, tokens, and integrations, they cannot apply least privilege, validate access continuously, or detect misuse reliably. The result is policy that looks rigorous but cannot be enforced across the real SaaS estate.

Q: Why do third-party SaaS integrations increase identity risk in CRM environments?

A: They connect external applications directly to customer data, making the integration itself part of the identity attack surface. If scopes are broad, ownership is unclear, or revocation is slow, a compromised connector can expose contact data, business context, and downstream trust relationships.

Q: What are the signs that SaaS access controls are not strong enough?

A: Common warning signs include dormant accounts that remain active, inconsistent MFA enforcement, broad privileges that exceed job needs, and limited visibility into activity across SaaS and integrated apps. If teams cannot quickly explain who has access, what data they can reach, and which non-human identities are still active, the control environment is likely too weak.

Q: How should teams respond when a SaaS token or integration becomes suspicious?

A: Containment should focus on the identity path, not only the application. Revoke the session or token, quarantine the integration, confirm whether related accounts or connected apps expanded scope, and investigate whether the activity indicates lateral movement or data exfiltration. Response needs to happen while the access path is still live.

Technical breakdown

Why SaaS discovery is the control plane for Zero Trust

Zero Trust assumes every access request is continuously verified, but SaaS environments fragment that assurance across many independent identity stores, permissions models, and sharing paths. Continuous discovery creates the control plane that tells security teams what applications exist, which identities can touch them, and where tokenised access or third-party integrations bypass normal review. Without that inventory, policy engines are making decisions against an incomplete dataset, which is why enforcement can look strict while remaining ineffective. In SaaS, visibility is not an observability add-on. It is the prerequisite for trust decisions that can actually be enforced across the estate.

Practical implication: build a continuously updated SaaS inventory before you tighten access rules or automate revocation.

How OAuth, service accounts, and API tokens widen the attack surface

SaaS environments rely heavily on non-human access paths such as OAuth grants, service accounts, API keys, and machine identities. These credentials often outlive the human context that created them, and they can retain broad scopes even when the original workflow changes. That makes entitlement review harder than in a user-only model, because a token may be active, valid, and invisible from the perspective of standard user access reports. The article’s core point is that untracked machine-to-machine and app-to-app access can create durable entry points for lateral movement and data exfiltration, especially when token scope and actual usage diverge.

Practical implication: inventory tokenised access and compare granted scope with actual use, not just owner approval.

Why SaaS-native telemetry beats generic SIEM coverage

Traditional SIEM and EDR tooling often miss the context that matters in SaaS, such as permission changes, OAuth grant activity, unusual session behaviour, and suspicious data movement inside the application layer. SaaS-native telemetry adds the missing context by correlating audit logs, identity signals, API activity, and sharing events in real time. That is how teams separate a routine bulk export from a service account suddenly querying data outside its expected role. In Zero Trust terms, telemetry is not just about detection after compromise. It is the evidence stream that allows access decisions to adapt before access patterns harden into abuse.

Practical implication: correlate SaaS audit events with identity signals before relying on broad detection coverage.

Threat narrative

Attacker objective: The objective is to turn legitimate SaaS trust relationships into durable access for data theft, lateral movement, or stealthy persistence.

1. Entry begins when a third-party relationship, OAuth grant, or machine identity provides a legitimate foothold into the SaaS environment.
2. Credential exposure or overbroad token scope then enables access that is valid on paper but excessive in practice, which is difficult to see without inventory and telemetry.
3. Escalation occurs through lateral movement across SaaS applications, app-to-app integrations, or expanded token use that remains inside authorised channels.
4. Impact is realised through undetected data access, exfiltration, or prolonged persistence in the SaaS stack.

Breaches seen in the wild

• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Canvas Instructure Data Breach: ShinyHunters exploits Canvas LMS platform to expose millions of student records via third-party NHI credential abuse.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Zero Trust SaaS fails first at discovery, not enforcement: The article reinforces that access policy is only as strong as the inventory underneath it. When organisations cannot continuously see apps, identities, tokens, and integrations, they are not operating Zero Trust, they are operating assumptions. The implication is that SaaS discovery must be treated as a prerequisite control rather than a reporting function.

Ephemeral trust debt is now the dominant SaaS governance problem: OAuth grants, service accounts, and third-party integrations accumulate permission faster than most teams can review them. Those permissions often remain active long after the business need has changed, which creates a form of trust debt that conventional IAM reporting does not surface quickly enough. Practitioners need to treat inactive and over-scoped SaaS connections as a governance backlog, not a cleanup task.

Continuous visibility is the only practical boundary for SaaS Zero Trust: Least privilege, RBAC, and ABAC all depend on current state, but SaaS state changes too quickly when users, bots, and integrations coexist. The useful boundary is not the user perimeter or the network perimeter, it is the live identity and token graph across the SaaS estate. Security teams should expect policy drift unless that graph is continuously reconciled.

Third-party SaaS access is a shared governance problem across human and non-human identities: The article shows that user-approved integrations can become machine-operated access paths with little human oversight. That makes offboarding, scope review, and lifecycle governance central to SaaS security rather than adjacent tasks. Programme owners should govern third-party access with the same discipline they apply to privileged identity.

Visibility without response automation is only half a control: Detecting anomalous SaaS behaviour matters, but the article correctly ties that visibility to revocation, quarantine, and session termination. In modern SaaS estates, delayed response leaves too much room for token abuse and app-to-app expansion. The practical conclusion is that identity telemetry and enforcement must be coupled if Zero Trust is to be operational rather than aspirational.

From our research library:

• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to the Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Read next: Identity Security Programme Guide

What this signals

Zero Trust SaaS is really an inventory discipline: if the estate is not continuously discovered, access policy cannot be trusted to reflect real exposure. That means programme owners should measure completeness of application and integration inventory before claiming enforcement maturity.

The trust boundary now extends across user accounts, service accounts, OAuth grants, and app-to-app automation, which means lifecycle governance has to cover all four. If one of those paths is unmanaged, the policy engine is operating on partial truth rather than risk-based access decisions.

SaaS visibility also changes what teams should prioritise operationally. Once the estate is mapped, the highest-value next step is to align granted permissions with actual usage and remove dormant integrations before they become persistent access channels.

For practitioners

• Map every SaaS application and integration Build and continuously refresh a live inventory of sanctioned and unsanctioned SaaS apps, connected OAuth grants, API links, and marketplace integrations.
• Inventory all human and non-human identities Document employees, contractors, service accounts, bots, and machine identities across SaaS platforms so access ownership and review are tied to the actual subject using the permission.
• Harden OAuth scopes and token lifecycles Restrict scopes to the exact actions required, rotate high-risk tokens on a defined schedule, and revoke unused or dormant credentials before they become persistent access paths.
• Correlate SaaS telemetry with identity signals Join audit logs, permission changes, login metadata, and API activity to detect anomalous access, unusual data transfer, and scope drift inside the application layer.
• Automate containment for suspicious SaaS activity Use predefined playbooks to revoke sessions, quarantine accounts, and disable integrations when behavioural thresholds or token misuse indicators are met.

Key takeaways

• SaaS Zero Trust fails when discovery is incomplete, because access policies cannot govern apps, identities, tokens, and integrations that remain unseen.
• The article shows that third-party and app-to-app relationships create durable identity risk when tokens, scopes, and service accounts outlive the business need.
• Practitioners should treat visibility, telemetry, and revocation as one control loop, because enforcement without discovery and discovery without response both leave exploitable gaps.

Key terms

• SaaS Visibility: SaaS visibility is the ability to identify which software services, tenants, and accounts exist in an environment and who controls them. In identity governance, it is the prerequisite for review, offboarding, and cost control because hidden applications cannot be certified or revoked reliably.
• OAuth Grant: An OAuth grant is the delegated permission an application receives to act on a user's behalf without storing the user's password. In NHI governance, it should be treated as a standing identity relationship with scope, ownership, and revocation requirements, not as a one-time setup detail.
• Machine Identity: The digital identity of a machine, device, or workload, such as a server, container, or VM, used to authenticate it within a network. Sometimes used interchangeably with NHI, though NHI is the broader category.
• Normalized SaaS Telemetry: SaaS activity data that has been standardized so events from different applications can be compared and correlated consistently. Normalization reduces schema drift, improves alert quality, and makes it possible to investigate user actions, integrations, and suspicious access patterns across an entire SaaS environment from one operational view.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.