Workday breach points to a wider SaaS trust failure in 2025

At a glance

What this is: This is an analysis of the 2025 SaaS breach wave and the finding that attackers are exploiting human trust and OAuth-connected SaaS paths rather than traditional network flaws.

Why it matters: It matters because IAM, IGA, and security teams need visibility into SaaS consent, connected apps, and identity behaviour before social engineering turns into data loss.

By the numbers:

• In Q3 2024, organizations saw a 75% year-over-year increase in cyberattack volume, averaging 1,876 attacks per week.
• Australia saw data breach reports jump 25% in the second half of 2024 compared with the first half.
• Unit 42 reported that social engineering now plays a role in over a third of major intrusions.

👉 Read Grip Security's analysis of the Workday SaaS breach wave and OAuth abuse

Context

The primary governance gap here is not a missing firewall rule, but an identity trust problem across SaaS, OAuth, and user behaviour. Attackers are not trying to outmuscle hardened infrastructure when they can persuade a person to approve a malicious app, install a fake update, or share access through a trusted workflow. For IAM and NHI teams, that shifts the control boundary from the network edge to the connected application layer.

The article frames Workday as part of a broader 2025 breach wave that also includes Google, Cisco, Allianz Life, and Qantas. That pattern is especially relevant to identity programmes because SaaS connectivity expands the effective access surface far beyond what SSO alone can see. Human identities, delegated app access, and third-party integrations now behave as one chain, which means governance has to follow the chain rather than the login event.

Key questions

Q: How should security teams handle OAuth consent risk in SaaS environments?

A: Treat OAuth consent as an access control event, not a simple user choice. Review app scopes, owner approval, and token lifetime before allowing access. Then monitor the resulting API activity for data exfiltration, mailbox rule changes, and unauthorized automation. Consent without governance becomes persistent access, especially when the app can act outside the user’s normal session controls.

Q: Why do SaaS attacks often bypass MFA?

A: Because MFA only protects the login event, while a valid session token or OAuth bearer token can remain trusted after authentication. Once the attacker has the token, they may not need another prompt. That is why token lifecycle controls matter as much as sign-in policy.

Q: What breaks when organisations cannot see shadow SaaS and third-party integrations?

A: Access reviews lose their value because they only cover what is visible. Hidden tenants, unmanaged apps, and missed OAuth connections create a blind spot where data can move through approved-looking channels without effective oversight. In that situation, the organisation is certifying a partial picture, not the real access estate.

Q: Who is accountable when a user approves a malicious SaaS integration?

A: Accountability is shared across identity governance, application owners, and the business team that allowed the integration to exist without adequate review. The user may have clicked the approval, but the control failure sits in how the organisation manages consent, app onboarding, and ongoing recertification of connected access.

Technical breakdown

OAuth consent abuse in SaaS environments

OAuth is an authorization protocol that lets users grant apps access without sharing their passwords. In practice, that makes consent screens, token scopes, and app publisher trust the key control points. When attackers combine phishing, voice calls, or fake support with malicious OAuth apps, they can obtain durable access that looks legitimate to the platform. The failure is not authentication alone, but the absence of governance over consent, app registration, and scope creep across SaaS tenants.

Practical implication: monitor OAuth grants and app scopes as first-class identity events, not just as application telemetry.

Why SaaS connectivity expands the blast radius

SaaS ecosystems are built from managed apps, shadow tenants, third-party integrations, and delegated permissions. That creates a trust graph rather than a simple perimeter. Once an attacker gets into one app or approves one malicious integration, they can pivot through connected services, export data, or blend into routine administrative actions. The architecture problem is that access is distributed across many small trust decisions, each of which may be invisible in isolation but dangerous in aggregate.

Practical implication: map the SaaS trust graph so you can see which integrations can move data laterally.

Human trust as an identity control failure

These breaches exploit the point where human decision-making meets technical permissioning. Users are asked to act quickly, often under the guise of IT, HR, or a vendor, and the platform then converts that moment into durable access. MFA helps, but it does not stop a user from approving a malicious integration or authorizing a data export. The deeper failure is that many identity programs treat user authentication as the end of the control chain, when in SaaS it is only the beginning.

Practical implication: extend IAM governance beyond sign-in to include consent, support impersonation, and export approvals.

Threat narrative

Attacker objective: The attacker’s objective is to convert human trust into SaaS-level data access that can be used for quiet exfiltration and broader account compromise.

1. Entry begins with voice phishing, SMS lures, or impersonation of IT, HR, or a trusted vendor to obtain a user decision that opens the SaaS path.
2. Escalation occurs when the attacker uses malicious OAuth apps, deceptive updates, or approved exports to turn that trust event into durable application access.
3. Impact follows as customer or business data is quietly siphoned from SaaS systems and connected apps without touching the traditional network perimeter.

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

SaaS trust debt is now an identity governance problem, not a single-app security problem. The article’s pattern shows that attackers are exploiting the accumulated trust relationships between users, apps, vendors, and delegated permissions. That is a governance failure because the access chain outlives any individual login event. Practitioners need to treat connected SaaS as a governed identity fabric, not a collection of isolated tools.

OAuth consent is becoming the new approval surface for enterprise compromise. Traditional IAM assumes authentication is the main gateway, but SaaS attacks now turn consent dialogs, app authorizations, and data export permissions into the real control plane. That shifts security review from passwords and MFA alone toward lifecycle control of third-party app access. The practical conclusion is that consent governance must sit inside IAM, not beside it.

Shadow SaaS and unmanaged integrations create a visibility gap that existing access reviews do not close. If security teams cannot see every tenant, app, and delegated connection, then recertification becomes a paperwork exercise rather than control assurance. This is where the named concept matters: identity trust graph sprawl describes the growing mesh of app-to-app and user-to-app dependencies that attackers now exploit. Practitioners need to govern the graph, not just the account.

Human identity controls now determine the security posture of non-human access. The article makes clear that the breach path begins with people, but the damage flows through machine-mediated permissions. That means IGA, PAM, and SaaS governance must be coordinated, because a user’s approval can instantly create non-human access with a wider blast radius than the original account. Identity programmes that separate human and NHI governance will miss the way these incidents actually unfold.

Response speed matters because SaaS attacks compress the window between lure and exfiltration. The post describes compromises that move from social engineering to data theft inside hours, which leaves little room for retrospective detection. That is a strong case for continuous monitoring of consent, app behaviour, and anomalous exports. The practitioner implication is simple: if your controls only review access after the fact, they are already too late.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared with nearly 1 in 4 for securing human identities.
• For a wider view of how OAuth exposure, over-privilege, and lifecycle gaps combine, see The 52 NHI breaches Report.

What this signals

Identity trust graph sprawl: SaaS security is now determined by the quality of the relationships between users, apps, and vendors, not just by sign-in policy. When connected services can approve access or move data without a clear owner, IAM becomes a visibility and lifecycle problem as much as an authentication problem.

With 85% of organisations lacking full visibility into third-party vendors connected via OAuth apps, per The State of Non-Human Identity Security, most programmes are still governing only the top of the trust chain. That leaves the real compromise path in delegated access, unmanaged apps, and export permissions.

The next control maturity step is to connect SaaS consent reviews, shadow app discovery, and identity governance into one operating model. Teams that keep human identity, NHI access, and SaaS application oversight in separate workflows will continue to miss the chain that attackers are already using.

For practitioners

• Map the SaaS trust graph Inventory every managed app, shadow tenant, and third-party integration that can access business data, then identify which identities can approve exports or grant consent across them.
• Tighten OAuth consent governance Require administrative approval for high-risk OAuth scopes, review new app grants in near real time, and revoke tokens when the connected business need is no longer valid.
• Add identity checks to help-desk and vendor workflows Treat urgent IT, HR, and vendor requests as identity events, with callback verification and policy checks before users install software or approve access.
• Correlate anomalous SaaS behaviour Alert on unusual data export patterns, new app approvals, and changes in access routes so security teams can contain abuse before records leave the environment.

Key takeaways

• The Workday breach story is less about one company than about a repeatable SaaS trust failure that attackers are using across industries.
• The strongest evidence in the article is that social engineering, OAuth abuse, and unmanaged SaaS connections now move faster than many access review cycles.
• Identity teams need governance over consent, connected apps, and delegated access, because authentication alone no longer contains SaaS risk.

Key terms

• OAuth Consent: The approval that allows an application to access resources on behalf of a user or tenant. In practice, consent can create durable access paths that outlive the original interaction if permissions are broad, unmanaged, or never reviewed. For security teams, it is both an access decision and a lifecycle event.
• Shadow SaaS: Shadow SaaS is the set of unauthorised or unreviewed software-as-a-service tools used outside central security governance. These applications often bypass normal identity controls, making them difficult to inventory, monitor, and harden against credential-based abuse.
• Identity Trust Graph: An identity trust graph is the network of relationships between users, applications, vendors, tokens, and delegated permissions that defines real access in a SaaS environment. It is more useful than a login-centric view because attackers exploit the links between identities, not just the identities themselves.
• Delegated SaaS access: Delegated SaaS access is permission granted to one application, connector, or service account to act on behalf of another identity or data owner. It is often necessary for automation, but it becomes a governance risk when the grant is broad, stale, or poorly owned.

What's in the full article

Grip Security's full webinar covers the operational detail this post intentionally leaves for the source:

• Step-by-step examples of how malicious OAuth consent gets approved and abused across SaaS environments
• Operational guidance on identifying shadow tenants, unmanaged apps, and risky third-party connections
• Specific response ideas for revoking dangerous app grants and containing suspicious SaaS behaviour
• The webinar framing around the Workday breach and the wider 2025 SaaS attack wave

👉 Grip Security's full webinar covers the Workday breach context, the SaaS attack pattern, and the operational response details.

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.