SaaS security best practices expose the limits of legacy IAM

At a glance

What this is: A SaaS security best-practices guide that uses a Microsoft OAuth compromise and several control patterns to argue for stronger visibility, access review, and incident readiness.

Why it matters: It matters because SaaS sprawl, delegated access, and stale permissions create identity risk across NHI, human IAM, and increasingly autonomous workflows.

By the numbers:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.

👉 Read Zluri's seven SaaS security best practices and the Microsoft OAuth case

Context

SaaS security is really an identity governance problem as much as it is an application security problem. Once SaaS apps are linked through OAuth, role assignments, and delegated admin access, weak inventory and access review practices create an identity surface that attackers can move through faster than manual controls can respond.

The Microsoft Midnight Blizzard incident is a useful example because it shows how one legacy OAuth application can become a gateway into corporate email and adjacent data. The broader lesson for NHI, human IAM, and cross-platform governance is that access paths often outlive the assumptions behind them.

Key questions

Q: How should security teams govern OAuth-connected SaaS apps that retain broad access?

A: Treat every OAuth-connected app as a governed identity with a clear owner, approved scopes, and an expiry or review point. If the app can reach mail, files, or other sensitive SaaS data, enforce least privilege and remove anything no longer tied to an active business need. Inventory is only useful when it drives revocation and reapproval decisions.

Q: Why do SaaS access reviews often miss the most dangerous permissions?

A: Because access can drift between review cycles. If teams review only on a calendar basis, they may miss newly expanded OAuth scopes, repurposed apps, or dormant integrations that still carry high privilege. Event-driven review, tied to ownership and scope changes, is more effective than relying on static certification windows alone.

Q: What breaks when third-party SaaS visibility is incomplete?

A: Least privilege breaks first, because teams cannot limit what they cannot see. Then incident response slows down, because responders waste time discovering which apps exist, who owns them, and what data they can reach. Incomplete visibility turns every downstream control into a partial control.

Q: Who should revoke a compromised SaaS integration during an incident?

A: The business owner, identity team, and security operations function should have pre-assigned authority to disable the app, revoke tokens, and remove risky scopes without waiting for a lengthy approval chain. In SaaS incidents, containment depends on fast, role-defined action before the attacker completes further access.

Technical breakdown

Why legacy OAuth apps become a SaaS control blind spot

Legacy OAuth applications are difficult to govern when they were created for older trust models or limited authentication paths. In practice, they can still hold broad access into mail, documents, or adjacent SaaS resources even when the original business need has changed. That creates an authorisation gap rather than a pure authentication problem. The risk increases when security teams cannot clearly see which apps exist, who approved them, and what scopes they retain over time.

Practical implication: inventory every OAuth-connected app, classify its scopes, and retire legacy apps that retain broad access without an active owner.

How zero trust changes access decisions across SaaS apps

Zero trust in SaaS environments means access is continuously verified, not assumed because a user or app is already inside the perimeter. That usually combines MFA, RBAC, and least privilege with conditional access decisions tied to context such as device trust or network path. For SaaS, the hard part is not the policy language but keeping those policies aligned to the actual apps, accounts, and integrations that exist today. If the inventory is stale, the zero-trust model is only partially enforced.

Practical implication: bind SaaS access policies to live app inventory and revalidate scopes whenever a provider, role, or integration changes.

Why access reviews fail when entitlements drift faster than review cycles

Access review is meant to catch privileges that no longer fit the user's role or the application's purpose. But in SaaS environments, entitlement drift can happen faster than scheduled review cycles, especially where app permissions are granted through automated workflows or delegated approvals. If reviews rely on static spreadsheets or periodic exports, they miss the moment when access becomes excessive. The control failure is not review in theory, but review that arrives too late to matter.

Practical implication: shorten review intervals for high-risk SaaS apps and connect review triggers to changes in role, ownership, or OAuth scope.

Threat narrative

Attacker objective: The objective was to turn delegated SaaS trust into durable access to sensitive corporate communications and supporting documents.

1. Entry began with compromise of a legacy test OAuth application that still had reach into Microsoft corporate email accounts.
2. Escalation followed when the attackers used that foothold to access sensitive mail and then created additional malicious OAuth applications.
3. Impact included exfiltration of sensitive emails and documents, plus broader exposure across the corporate environment.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Legacy OAuth trust is the central SaaS governance failure mode here. The Microsoft incident shows that an application can remain trusted long after the business context that justified its access has changed. That means access reviews and provider assessments are not enough if they do not capture the living scope of delegated SaaS trust. Practitioners should treat dormant OAuth applications as standing identity risk, not as configuration debris.

Identity inventory is now a security control, not an administrative catalogue. The article correctly points to a centralized SaaS inventory, but the deeper point is that visibility determines whether least privilege can be enforced at all. If owners, scopes, and app relationships are missing, then every downstream control becomes partial. The practitioner conclusion is simple: if you cannot enumerate the identity surface, you cannot govern it.

Zero trust only works in SaaS when it includes third-party application trust paths. The article focuses on MFA, RBAC, and least privilege, but the Microsoft case shows that a trusted application can bypass ordinary user-centric assumptions. Security teams need to see SaaS integrations as part of the access plane, not as an integration detail. The governance conclusion is that zero trust must extend to delegated application access, not just human login events.

Review cadence is a weak defence when access can be weaponised between review cycles. The write-up’s emphasis on periodic access review is directionally right, but the operational problem is that SaaS privilege drift often happens continuously. That makes stale access a predictable outcome in organisations that depend on quarterly certification alone. Practitioners should assume that review lag creates exploitable windows unless it is paired with event-driven revocation.

Ephemeral access is still not enough if the underlying trust model is static. Even when teams shorten access duration, they can still preserve the same broad assumptions about which apps may connect, what scopes are acceptable, and who can approve them. The named concept here is delegated SaaS trust debt: access that remains acceptable on paper after the real business need has faded. The practitioner conclusion is to treat that debt as a governance risk in its own right.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, 38% have no or low visibility, and a further 47% have only partial visibility, according to The State of Non-Human Identity Security.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
• If you are tightening identity governance across SaaS and machine access, start with the NHI Lifecycle Management Guide to connect visibility, rotation, and offboarding into one control loop.

What this signals

Delegated SaaS trust debt is the governance pattern that should worry IAM teams most. Once a cloud app retains access after the original use case fades, the organisation inherits a hidden access path that looks authorised but no longer reflects reality. That is why visibility must be treated as an active control, not a reporting feature.

The practical signal for mature programmes is whether access reviews now trigger on app ownership changes, scope expansion, and vendor relationship changes. If those events do not automatically reopen review, the organisation is still relying on calendar-based governance for a dynamic identity surface.

When SaaS and machine identities converge, the next control boundary is not the login screen but the trusted app-to-app link. Teams that already manage Top 10 NHI Issues will recognise that the same visibility and lifecycle logic applies across OAuth apps, service accounts, and other non-human access paths.

For practitioners

• Build a live SaaS and OAuth inventory Track each app owner, approval source, granted scopes, and last validation date in one governed register so stale delegated access can be removed before it becomes a blind spot.
• Review privileged SaaS integrations on change events Trigger review when an app owner changes, when OAuth scopes expand, when a vendor relationship changes, or when a service account is repurposed, rather than waiting for a scheduled certification cycle.
• Constrain SaaS access with conditional trust checks Combine MFA, device trust, and network controls with app-level scope limits so a verified user still cannot inherit more access than the business role requires.
• Rehearse SaaS incident containment before the next breach Define who can disable an OAuth app, revoke tokens, freeze mailbox access, and preserve logs immediately after suspicious access is detected.

Key takeaways

• The article shows that SaaS security failures often begin with delegated identity trust, not with an obvious application exploit.
• The Microsoft OAuth compromise is a reminder that incomplete visibility and stale permissions can turn one trusted integration into a broad access path.
• Practitioners should move from periodic review to event-driven governance so SaaS access is revoked when trust, ownership, or scope changes.

Key terms

• OAuth-connected SaaS app: A SaaS application that has been granted access to other services through OAuth delegation. In practice, it becomes a non-human identity path because the app can act with scopes that outlast a single user session and may remain valid long after the original approval context has changed.
• Delegated SaaS trust: The access a third-party application receives when an organisation authorises it to act on behalf of users or systems. The risk is not just the initial grant, but the way that trust can persist, expand, or go stale without clear lifecycle controls and ownership.
• Access review: A governance process that checks whether users or applications still need the permissions they hold. For SaaS and other non-human identities, the process must be tied to scope changes, ownership changes, and revocation actions, otherwise it only documents risk instead of reducing it.
• Least privilege: A principle that grants only the minimum access needed to perform a task. In SaaS governance, it only works when teams can see actual scopes, app relationships, and downstream permissions, because hidden integration paths can quietly widen the blast radius.

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.

This post draws on content published by Zluri: 7 SaaS Security Best Practices You Must Follow. Read the original.