TL;DR: Provider risk review, inventory, zero trust, VPN restrictions, access reviews, incident response, and automation fit together as a practical control stack, according to Zluri’s overview of seven SaaS security best practices using the Microsoft Midnight Blizzard OAuth compromise to show how they work together. The underlying lesson is that SaaS sprawl and delegated access still outrun manual governance.
At a glance
What this is: This is a SaaS security best-practices article that uses the Microsoft Midnight Blizzard OAuth compromise to show why legacy IAM controls struggle in SaaS-heavy environments.
Why it matters: It matters because IAM, IGA, and PAM teams need to treat SaaS inventory, third-party provider risk, delegated access, access reviews, and incident response as one operating model rather than separate tasks.
Context
SaaS security best practices are controls for governing access, provider risk, and application sprawl across cloud-delivered business apps. In this article, the core problem is not a single broken control but the mismatch between static IAM processes and a SaaS estate built on third-party integrations, delegated authorisation, and fast-changing access.
The Microsoft Midnight Blizzard incident is the article’s evidence point: a legacy OAuth application was compromised, corporate email was accessed, and additional malicious OAuth applications were created to extend reach. For identity teams, that is a familiar pattern, because SaaS governance often depends on manual review cycles and inventory accuracy that lag behind actual access paths.
Key questions
Q: What breaks when SaaS subscriptions are not tied to access reviews?
A: Orphaned subscriptions and stale entitlements start to accumulate because no one revalidates whether the access still matches the job. That creates audit gaps, wasted spend, and higher risk when former users or inactive teams retain access. The result is a control environment that tracks billing better than identity.
Q: Why do OAuth apps and service accounts create more risk than their user-facing setup suggests?
A: They create risk because the visible installation is usually less important than the permissions behind it. A single OAuth grant or service account can silently inherit access to mail, source code, tickets, or cloud resources. If those permissions are broad or poorly tracked, an attacker who steals the token gets immediate operational reach.
Q: How do you know if SaaS inventory governance is actually working?
A: It is working when the inventory matches live usage, ownership, renewals, and exceptions without repeated manual correction. Strong governance produces audit-ready evidence, shows which apps are active or duplicate, and supports timely offboarding. If the record cannot be trusted during a review, the control is not effective.
Q: What should teams do immediately after a compromised SaaS app is discovered?
A: Disable the app’s active tokens and consent paths first, then identify downstream integrations, users, and data flows that depended on it. The aim is to stop the app from acting further on behalf of the organisation before containment work drags on. After that, rebuild the access picture from current state rather than assumptions.
Technical breakdown
Why SaaS inventory becomes an identity control
A centralized SaaS inventory is not just asset management. It becomes an identity control because access decisions depend on knowing which applications exist, who owns them, what data they hold, and which integrations or users still have standing access. In SaaS environments, hidden apps, duplicate apps, and risky apps create blind spots that IGA and access review processes cannot compensate for after the fact. The more fragmented the inventory, the more likely access is to persist outside governance boundaries. Practical implication: treat SaaS discovery and app ownership as prerequisites for access governance, not as an administrative afterthought.
Practical implication: make SaaS discovery, ownership, and app risk classification a control gate before access reviews or entitlement cleanup.
How OAuth and delegated access expand SaaS attack paths
OAuth delegation lets applications act on behalf of users, which makes application trust a first-class security decision. If a legacy or poorly governed OAuth app is compromised, the attacker may not need to steal a user password at all, because the app’s token or authorisation path can provide a valid route into corporate data. Creating additional malicious OAuth apps compounds the problem by turning one trusted integration into multiple footholds. This is why SaaS security is not only about user authentication. It is also about who or what is allowed to hold delegated access, how that access is bounded, and whether it is still needed. Practical implication: govern OAuth apps as privileged access paths, not simple convenience integrations.
Practical implication: review OAuth app registrations, consent, and delegated scopes as privileged access paths with the same rigor as admin accounts.
Why manual access reviews miss SaaS risk
Manual access review is useful, but it is too slow and too brittle when applications, users, and permissions change continuously across SaaS environments. The control assumes reviewers can see the full entitlement picture, understand whether access is still valid, and remove excess rights before misuse occurs. In practice, spreadsheets and point-in-time certification cannot keep up with shadow IT, role drift, or compromised accounts that inherit broad application access. Automation helps, but only when it is tied to current app inventory and accurate access rules. Practical implication: move from periodic cleanup to continuously updated access governance tied to live SaaS state.
Practical implication: replace periodic-only certification with continuously updated entitlement review tied to live SaaS state and role context.
Threat narrative
Attacker objective: The objective was to access and exfiltrate sensitive corporate email and documents while expanding reach through trusted SaaS authorisation paths.
- Entry occurred through password spraying against a legacy test OAuth application, giving the attackers a valid route into Microsoft corporate accounts.
- Credential or authorisation abuse followed when the compromised OAuth application provided access to email accounts, including senior executives and security personnel.
- Escalation continued when the attackers created additional malicious OAuth applications to widen access and deepen their foothold in the corporate environment.
- Impact was exfiltration of sensitive emails and attachments, along with broader exposure of SaaS trust boundaries.
Breaches seen in the wild
- SalesBleed Salesforce Agentforce 2026: Three fixed Agentforce flaws let poisoned web leads make AI agents leak CRM data with zero clicks and send phishing under the agent's identity.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
SaaS governance fails first at the inventory layer: if you cannot enumerate applications, owners, data, and integrations, you cannot govern access at all. The article’s control stack starts there for a reason, because hidden SaaS apps create hidden authorisation paths. That makes discovery and ownership mapping the foundation of any IAM or IGA programme covering SaaS.
Legacy IAM assumes access is mostly user-centric, but SaaS risk is increasingly app-centric: delegated authorisation, OAuth tokens, and third-party integrations create access paths that outlive any single login session. The Microsoft incident shows that a compromised application can become the real identity boundary, not the user account behind it. Practitioners need to reframe governance around application trust, not just user authentication.
Review-based governance alone does not match the speed of SaaS compromise: manual certification can remove excess access, but it cannot reliably keep pace with app creation, consent drift, and shadow IT. The practical consequence is a widening gap between what the access model says should exist and what SaaS systems actually permit. Continuous control beats periodic visibility when access pathways are mutable.
Privileged access is no longer confined to admins and consoles: in SaaS estates, high-risk access often sits inside OAuth consent, app registrations, and integrated workflows. That means PAM thinking has to expand beyond human administrators to include delegated application authority. If a control cannot see the app acting on behalf of the user, it is not covering the true privilege surface.
Identity review processes assume a stable entitlement window, and that assumption is too weak for modern SaaS: the governance premise was designed for access that exists long enough to be observed, certified, and remediated. That assumption fails when SaaS access is created through rapid app onboarding, delegated consent, and fast-moving integrations. The implication is that identity programmes must govern issuance and trust paths, not only recertification.
From our research library:
- 1 in 3 organisations encountered suspicious AI agent activity in 2025, and 99.4% experienced a SaaS or AI ecosystem incident.
What this signals
Delegated access has become the real SaaS privilege surface: many organisations still organise governance around users, but the article shows why app registrations, consent grants, and connected workflows now deserve equal scrutiny. That shift changes how IAM and PAM teams should scope review work across the SaaS estate.
SaaS sprawl turns visibility into a control boundary: if the inventory is incomplete, every downstream action becomes partially blind. Practitioners should expect discovery, ownership, and entitlement refresh to sit closer together in future operating models because the gaps between them are where compromise hides.
For practitioners
- Build a live SaaS inventory Capture application owner, business purpose, data sensitivity, integration paths, and risk score so access decisions are tied to current state rather than stale records.
- Treat OAuth applications as privileged assets Review consented scopes, app registrations, and delegated permissions with the same rigor used for elevated human access, especially for legacy or little-used applications.
- Move access reviews to continuous evidence Use automated review cycles that refresh entitlement data from the live SaaS estate, then revoke or reduce access when permissions no longer match role or business need.
- Separate trusted app access from user trust Restrict sensitive SaaS access by application posture, integration type, and network or device context, not only by user identity and MFA status.
- Test incident response around SaaS delegation Predefine steps for disabling compromised apps, revoking tokens, and identifying downstream integrations before a breach forces the sequence.
Key takeaways
- SaaS governance fails when teams rely on access reviews without first maintaining a live view of apps, owners, and delegated permissions.
- The Microsoft Midnight Blizzard case shows that legacy OAuth applications can become an initial access path and a mechanism for further expansion.
- Practitioners should treat delegated SaaS access as privileged exposure, not as a routine convenience layer, and respond with current-state inventory and faster revocation.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | Third-party SaaS apps and delegated OAuth access are central to the article’s risk model. |
| NHI-05 — Overprivileged NHI | The article repeatedly warns about excessive app and user permissions in SaaS environments. | |
| NHI-07 — Long-Lived Secrets | Legacy OAuth applications and stale access paths can remain usable long after they should be removed. | |
| Recommendation — Assess third-party SaaS integrations as NHI trust paths and remove high-risk delegated access. Reduce standing SaaS permissions to the minimum needed and revoke excess access promptly. Shorten the lifetime of SaaS app credentials, tokens, and authorisations wherever possible. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential and token lifecycle management is central to controlling SaaS app abuse. |
| Recommendation — Manage SaaS tokens and authenticators with lifecycle controls that support revocation and rotation. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about governing who and what can access SaaS resources. |
| Recommendation — Continuously govern SaaS entitlements so permissions stay aligned to role and business need. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The article’s breach example uses compromised access to expand into corporate email and documents. |
| Recommendation — Map compromised SaaS access to credential access and lateral movement detections in your monitoring stack. | ||
Key terms
- SaaS Security Baseline: A SaaS security baseline is the minimum set of controls an organisation requires before trusting a provider or integration. It usually includes MFA, SSO, logging, role separation, and revocation processes, all treated as conditions of access rather than optional hardening.
- Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
- SaaS Inventory: A SaaS inventory is the authoritative record of which cloud applications an organisation uses, who owns them, and how they are accessed. In mature governance, it is more than a list because it supports renewal, certification, offboarding, and security review decisions.
- Access Review: A formal process for confirming whether access is still needed and justified. In IAM programs, the review becomes an evidence-bearing control when decisions are recorded, scoped correctly, and traceable to the right reviewer, application owner, or auditor.
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 building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 11, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org