Notifications
Clear all
Topic starter
11/08/2026 3:23 pm
TL;DR: Attackers are abusing OAuth device code flow, vishing admins, and chaining access across Salesforce, Google Workspace, and Microsoft 365 as SaaS integrations widen the blast radius, according to Bishop Fox. The real problem is not the initial phish but the assumption that inherited tokens and broad SaaS permissions remain visible long enough to govern.
NHIMG editorial — based on content published by Bishop Fox: OAuth device code abuse and multi-SaaS attacker campaigns
Questions worth separating out
Q: How should security teams detect OAuth device code abuse in enterprise environments?
A: Security teams should correlate interactive approval, token issuance, refresh activity, and downstream app access into a single session view.
Q: Why do SaaS integrations make one compromised account so dangerous?
A: Because a valid token or delegated grant can travel through connected applications without triggering a second authentication event.
Q: What breaks when organisations cannot inventory tokens and service accounts in SaaS apps?
A: Containment breaks first, because responders cannot tell which identities are still valid, where they are used, or which integrations inherit their access.
Practitioner guidance
- Disable unnecessary device code flow Review which applications truly need device code flow and turn it off everywhere else, especially where browser-based or managed-device authentication is already available.
- Treat admin logins as privileged events Apply phishing-resistant authentication, step-up checks, and tighter alerting to every SaaS administrator login and administrative action.
- Inventory delegated access paths Map OAuth grants, service accounts, and integration permissions across SaaS platforms so one compromised token cannot silently reach dozens of downstream systems.
What's in the full article
Bishop Fox's full analysis covers the operational detail this post intentionally leaves for the source:
- Which SaaS admin behaviours attackers are exploiting through LinkedIn reconnaissance and vishing
- Practical guidance for deciding where device code flow should remain enabled and where it should be removed
- The on-demand fireside chat context around how Google Workspace, Microsoft 365, and Salesforce were discussed together
- Specific mitigation examples for privileged admin monitoring and conditional access enforcement
👉 Read Bishop Fox's analysis of OAuth device code abuse across SaaS platforms →
OAuth device code flow abuse across SaaS: are controls keeping up?
Explore further
11/08/2026 3:33 pm
OAuth trust is now an identity control surface, not just an authentication detail. When a login flow can mint a valid token that behaves like normal access, defenders are no longer protecting a password prompt. They are governing the lifecycle and scope of an identity object that can be reused across apps, tenants, and automation paths. That shifts the centre of gravity from user authentication to token governance and delegated access oversight.
A few things that frame the scale:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, with 38% reporting no or low visibility and a further 47% only partial visibility, 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 to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
A question worth separating out:
Q: Who is accountable when a help-desk style phishing attack reaches SaaS data?
A: Accountability usually spans identity, security operations, and application owners because the attacker exploited trust across support, consent, and delegated access controls. The practical answer is to define who can approve app installation, who can revoke it, and who confirms the incident scope before recovery begins. That governance must be explicit.
👉 Read our full editorial: OAuth device code abuse is expanding SaaS compromise across platforms
