Topic starter
16/01/2026 2:20 pm
TL;DR: Zero Trust SaaS depends on continuous visibility into apps, identities, tokens, and third-party integrations, because fragmented SaaS estates make access policies theoretical when discovery is incomplete, according to Wing Security’s analysis. Without that inventory, least privilege, RBAC, and monitoring cannot reliably govern NHI and SaaS-to-SaaS risk.
Editorial analysis by NHI Mgmt Group, based on content published by Wing Security: “Zero Trust starts with SaaS visibility and control”.
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.
Key questions
Q: What breaks when SaaS visibility is incomplete in a Zero Trust model?
A: Zero Trust breaks at the point of enforcement.
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.
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.
Practitioner guidance
- 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.
Bottom line: SaaS Zero Trust fails when discovery is incomplete, because access policies cannot govern apps, identities, tokens, and integrations that remain unseen.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
08/10/2026 4:29 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Zero trust SaaS needs visibility before access control can work