The Identity Layer Is Failing Us: It's Time for SaaS-Layer Controls
- Martin Snyder
- 2 days ago
- 4 min read
SSO and MFA are necessary—but not sufficient. Identity providers protect front doors, while modern SaaS creates side doors: OAuth grants with offline_access, duplicate tenants, public links, browser extensions, and AI plug-ins. Waldo Security closes those gaps—we discover every SaaS app, tenant, account, and OAuth connection in minutes, flag SSO/MFA bypasses, right-size risky scopes, and export audit-ready evidence. Start with Instant SaaS Discovery, then operationalize proof with our SaaS Compliance Overview.
Executive Summary (TL;DR)
Identity layers assume users come through the IdP. SaaS doesn’t.
The biggest breaches still start with credentials, and “supports SSO” ≠ “enforces SSO.” (Verizon)
Public guidance tells you to start with inventory → least privilege → logging at the SaaS layer—not just at identity or network. (CISA)
You need SaaS-native guardrails: consent controls, token hygiene, guest governance, link-sharing policy, and continuous evidence (not screenshots).
A Short Case: “We Mandated SSO… So Why Did Data Leak?”
A product team connects a doc-automation app using “Sign in with …”. It requests broad write scopes plus offline_access and starts syncing files. Months later, the engineer leaves; HR closes accounts and resets passwords. The sync continues—because refresh tokens outlive the password change. This didn’t bypass identity; it bypassed only using identity. That’s a SaaS-layer failure. Microsoft’s own guidance: restrict end-user consent to verified publishers and only selected permissions; push other requests to admins. (Microsoft Learn)
Why the Identity Layer Alone Falls Short
Credential-centric attacks target appsIn the Verizon DBIR 2025, ~88% of Basic Web Application Attacks involved stolen credentials. If an app allows local passwords—or if access persists via tokens—identity controls won’t see it. (Verizon)
Zero Trust was never “IdP-only”NIST SP 800-207 moves trust from networks to users, assets, and resources, demanding continuous evaluation at the application/resource plane. IdP gates are one control point, not the only one. (NIST Publications)
The playbook says inventory firstCISA’s Cloud Security Technical Reference Architecture is blunt: get visibility of services, enforce least privilege, and ensure logging—specifically for cloud/SaaS. Identity data alone is a partial map. (CISA)
Costs reward speed and visibilityIBM pegs the global average breach at ~$4.44M, with lower costs tied to faster identification/containment—the exact outcomes continuous SaaS-layer evidence enables. (IBM)
Myth vs. Fact
Myth: “Our apps support SSO, so we’re safe.”Fact: You’re safe when SSO/MFA is enforced and alternate paths (passwords, tokens, guests, links) are governed. DBIR’s numbers show attackers still ride credentials right through web apps. (Verizon)
Myth: “Consent is basically a smaller approval.”Fact: End users can grant durable access. Tighten Entra user-consent to verified publishers + selected permissions; require admin approval for high-privilege scopes. (Microsoft Learn)
Myth: “Our SIEM would catch this.”Fact: You only log what you’ve integrated. TRA guidance: inventory first, then collect SaaS telemetry and drift. (CISA)
The SaaS-Layer Control Set (What to Add on Top of SSO/MFA)
1) Consent Guardrails (stop silent SSO bypasses)
Restrict end-user consent to verified publishers and low-impact permissions.
Require admin approval for tenant-wide or write scopes.
Review/revoke grants with offline_access and broad *.ReadWrite.All-style scopes. (Microsoft Learn)
2) Token Hygiene (kill persistence)
Enumerate refresh tokens, PATs, and app keys; revoke idle and rotate routinely.
On departures, remove app grants and invalidate refresh tokens—not only passwords.
3) SSO Enforcement Reality Check
Alert on password logins to apps listed as “SSO-only.”
Close suite-specific loopholes (guest exclusions, unmanaged tenants).
4) Sharing & Guest Governance
Default-deny public links in sensitive spaces; restrict external domains.
Time-box elevated roles for guests/contractors; assign an internal owner to each external identity.
5) Continuous Evidence (audit, insurance, customers)
Stream SaaS audit logs; ship monthly packets: SSO coverage, admin changes, OAuth diffs, offboarding timestamps, and sharing exceptions. That’s how you cut dwell time and show operation. IBM’s findings reward exactly this. (IBM)
Field Guide: 30 Days to a Working SaaS-Layer Posture
Week 1 — Map
Correlate IdP sign-ins, email/collab logs, DNS/proxy, browser extensions, and expense data into a deduped inventory of apps, tenants, accounts, and OAuth grants. Tag auth method, admin count, scopes, sensitivity. (TRA: visibility.) (CISA)
With Waldo, this map appears in minutes—shadow, AI, and extensions included.
Week 2 — Enforce
Make SSO/MFA real for high-risk apps; alert on password logins; remove stale admins. (DBIR reality.) (Verizon)
Week 3 — Contain
Apply consent guardrails; bulk-revoke idle refresh tokens; lock down link sharing; time-box guest roles. (Microsoft Entra model.) (Microsoft Learn)
Week 4 — Prove
Wire SaaS logs to SIEM; export the first evidence pack for leadership/auditors (coverage, changes, revocations). (TRA logging + IBM cost angle.) (CISA)
KPIs That Show the Shift
Unknown → Known: % of SaaS usage tied to inventoried apps/tenants
SSO Coverage: % of high-risk apps enforcing SSO/MFA
OAuth Health: # of high-privilege grants with offline_access; % reduced MoM
Guest Hygiene: External identities with admin/export roles; % time-boxed
Evidence Freshness: % of artifacts updated in last 30 days
Bottom Line
Identity layers stop a lot—but SaaS is where access lives. Zero Trust expects controls at the resource plane: visibility of services, least privilege in scopes/roles/links, and continuous logging. That’s SaaS-layer security, and it’s how you shrink blast radius, pass audits, and lower breach cost.
Want the fast path? Begin with Instant SaaS Discovery and keep proof repeatable with the SaaS Compliance Overview.
Comments