TL;DR: SaaS environments create identity and access blind spots through orphaned subscriptions, weak transparency, and uneven control over third-party access, according to Zluri's analysis. The security model fails when teams treat SaaS as vendor-managed infrastructure instead of a governed identity surface that needs continuous oversight.
NHIMG editorial — based on content published by Zluri: Miscellaneous Let’s talk about SaaS security and why you must be proactive
By the numbers:
- By mid-2019, 4.1 billion records were left exposed, with more than 3,800 publicly disclosed breaches.
- 71% of businesses had orphaned SaaS subscriptions.
- 80% of survey respondents worldwide said biometric authentication can be effective for securing identity data, while adoption hovered around 22%.
Questions worth separating out
Q: How should security teams govern SaaS access across many business applications?
A: Security teams should govern SaaS access as a single identity surface rather than as separate app settings.
Q: Why do orphaned SaaS subscriptions create security risk?
A: Orphaned subscriptions create risk because they leave live access paths in place after the organisation has stopped using them.
Q: What do teams usually get wrong about third-party SaaS access?
A: Teams often focus on the app and ignore the identities behind the connection.
Practitioner guidance
- Inventory every SaaS application and owner Create and maintain a complete app register that includes business owner, technical owner, data type, authentication method, and offboarding path.
- Map third-party access paths to concrete identities Document every vendor integration, delegated permission, API token, and service account that can reach SaaS data.
- Enforce continuous access review across the SaaS stack Do not rely on periodic spreadsheets or one-time approval records.
What's in the full article
Zluri's full blog post covers the operational detail this post intentionally leaves for the source:
- The article's full SaaS security checklist for evaluating provider controls before procurement
- The specific examples of common SaaS threats, including credential-sharing, phishing, and weak password behaviours
- The survey comparison between biometric authentication effectiveness and actual adoption rates
- The vendor's suggested framing for internal teams managing data visibility, entry points, and cross-application security
👉 Read Zluri's analysis of proactive SaaS security and identity control →
SaaS security and identity governance: where teams are still exposed?
Explore further
SaaS security is really identity governance for a distributed application surface. The article is right to frame SaaS as a place where control can be lost even when basic vendor security exists. Once data, users, vendors, and app integrations spread across the stack, the real issue becomes who owns access, reviews it, and removes it when business use ends. Practitioners should treat SaaS inventory and access governance as one discipline, not two separate problems.
A few things that frame the scale:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which is why identity inventory and ownership matter before access reviews can be trusted.
A question worth separating out:
Q: How can organisations tell if SaaS governance is actually working?
A: SaaS governance is working when the app inventory is current, every external integration has a named owner, and offboarding removes access without manual chasing. If dormant subscriptions, unclear ownership, or unexplained data paths remain, the programme is measuring policy, not control.
👉 Read our full editorial: SaaS security demands proactive identity governance and visibility