Who is accountable when a vulnerable SaaS app can pivot into Microsoft 365?

Accountability is shared across the SaaS vendor, the customer, and the identity governance team. The vendor must implement correct OIDC and OAuth handling, while the customer must assess consent scope, review connected applications, and accept that delegated access expands the enterprise perimeter. If no one owns the full path, the risk persists.

Why This Matters for Security Teams

When a vulnerable SaaS application can pivot into Microsoft 365, the real issue is not just application security. It is delegated identity risk: a third-party app may hold OAuth consent, tokens, or API permissions that extend far beyond the original login boundary. That means a flaw in one SaaS product can become an enterprise-wide identity event. NHI Management Group has repeatedly shown how credential and token exposure turns into broad blast radius, especially when secrets and non-human identities are not tightly governed, as seen in the Salesloft OAuth token breach and the Microsoft Midnight Blizzard breach.

The practical challenge is accountability. SaaS vendors are responsible for secure auth integrations, but customers own consent review, tenant configuration, conditional access, and app lifecycle decisions. Identity teams often inherit the fallout without having designed the original trust relationship. Current guidance from the NIST Cybersecurity Framework 2.0 supports shared governance, but it does not remove the need for a clear owner of delegated access paths. In practice, many security teams encounter the failure only after an app token is abused or mailbox data is accessed, rather than through intentional risk acceptance.

How It Works in Practice

The accountability chain usually begins with an OAuth consent flow or service-to-service integration. A user, admin, or automation grants the SaaS application access to Microsoft 365 resources such as mail, files, calendars, or directory data. If the SaaS product is vulnerable, an attacker may exploit that trust to reuse the granted scope, impersonate the connected app, or exchange a stolen token for downstream access. The critical point is that the Microsoft 365 tenant becomes part of the attack path even when the initial flaw exists outside Microsoft.

Operationally, responsibility is split across three layers:

• Vendor layer: secure OIDC and OAuth handling, validate tokens properly, and prevent token theft or replay.

• Customer layer: review app consent, restrict high-risk scopes, and disable apps that no longer have a business owner.

• Identity governance layer: continuously inventory connected apps, monitor anomalous consent grants, and define revocation procedures for delegated access.

This is where NHI governance becomes practical rather than theoretical. NHI Management Group’s guidance on the Ultimate Guide to NHIs highlights why long-lived credentials, poor rotation, and weak visibility turn routine integrations into persistent access paths. The same pattern appears in the BeyondTrust API key breach, where one compromised integration can expose a much broader environment. Good practice is to treat each SaaS connector as an identity relationship, not just an app approval.

These controls tend to break down when admin consent is broadly delegated in large tenants because the organization can no longer prove who approved which access, or why.

Common Variations and Edge Cases

Tighter consent control often increases operational overhead, requiring organisations to balance developer velocity against exposure from third-party integrations. That tradeoff becomes more pronounced in environments with many business-managed apps, M&A sprawl, or hybrid identity models where app owners are unclear.

There is no universal standard for accountability wording yet. Some organisations assign the control to IAM, others to SaaS governance, and others to the application owner. Best practice is evolving toward named ownership for every high-risk consented app, plus periodic re-certification of its permissions. This is especially important when the app reaches mailbox, SharePoint, or directory scopes, because those permissions can enable lateral movement across collaboration systems.

Two cases deserve extra scrutiny. First, customer-managed conditional access may limit where a token can be used, but it does not fix overbroad consent. Second, vendor certifications do not eliminate customer due diligence; a secure product can still be dangerous if the tenant grants excessive permissions. The underlying lesson is the same as in the Snowflake breach: a valid credential or token is often enough to make a routine integration into a major incident. When delegated access is not inventoried and revocation is slow, accountability becomes diffuse and response becomes reactive.

Related resources from NHI Mgmt Group

• Who is accountable when a SaaS integration token is stolen?
• What is the difference between a disabled app and a deleted app in Microsoft 365?
• Who is accountable when a contractor uses a shadow SaaS app without MFA?
• Who is accountable when former employees still have Microsoft 365 access?