The FBI and CISA recently issued a public warning about a rapidly growing attack technique abusing Microsoft 365 "device code flow" authentication. The advisory explains how attackers are using legitimate OAuth authorization workflows to gain persistent access to enterprise Microsoft 365 environments without stealing passwords or bypassing MFA in the traditional sense. This is an important moment for the industry because it highlights a larger truth: Strong authentication alone is no longer enough.
Modern identity attacks are increasingly targeting authorization workflows, OAuth trust relationships, delegated application access, and token issuance policies rather than simply trying to steal credentials.
The FBI warning is here: FBI PSA on Device Code Phishing Attacks
Enterprises deploying TokenCore devices already have major advantages because biometric FIDO2 authentication dramatically reduces the largest current attack classes including:
AiTM phishing
MFA fatigue
Help desk impersonation
Password reset fraud
Session relay attacks
Spoofed domain attacks
Credential replay
However, the FBI advisory demonstrates that organizations must now evolve beyond “MFA deployment” and begin governing OAuth authorization pathways themselves.
The attack abuses OAuth 2.0 Device Authorization Grant flow, commonly called “device code flow.” This mechanism was originally designed for devices with limited input capability such as conference room systems, smart TVs, IoT devices, printers, and shared meeting hardware.
In legitimate use:
The critical problem is this: The attacker can initiate the request themselves from their own machine, then socially engineer the victim into approving that authorization request.
The victim may authenticate successfully using legitimate MFA, including biometric FIDO2 authentication. But they are authorizing the attacker’s session. This is fundamentally different from credential phishing. The attacker is not stealing authentication secrets. The attacker is obtaining delegated authorization.
For years, enterprise security programs focused heavily on answering one question: Did MFA occur? That is no longer sufficient. Modern identity security must answer:
Which application was authorized?
Which device requested authorization?
Was the endpoint managed?
Was the session local or remote?
Was phishing-resistant authentication used?
Was the authorization high assurance?
Was the device physically present?
Was the OAuth grant expected?
This is where enterprises using TokenCore devices gain an important strategic advantage. TokenCore devices provide extremely high-assurance biometric assured identity verification:
Hardware-bound credentials
Biometric verification
Biometric FIDO2 phishing resistance
Domain binding
Physical proximity enforcement
But organizations must now combine that assurance with modern OAuth governance policy.
Restrict or Disable Device Code Flow Where Possible
Most enterprises do not actually require OAuth device code flow for the majority of users. Security teams should evaluate:
Which applications legitimately require it
Which user groups require it
Which device categories require it
In Microsoft Entra ID, Conditional Access policies and authentication flow policies can restrict device code flow usage.
For most enterprise knowledge workers, device code flow can often be disabled entirely. This immediately eliminates the attack path described by the FBI
Require Phishing-Resistant Authentication Strength
Enterprises should require phishing-resistant authentication strength for all privileged access and all OAuth consent workflows. This means:
Biometric FIDO2 hardware authenticators only
No SMS fallback
No TOTP fallback
No push approval fallback
TokenCore devices fit naturally into this model because they provide hardware-bound biometric FIDO2 assurance with origin verification and proximity requirements. More importantly, organizations should remove legacy recovery paths that bypass hardware assurance. Many breaches still occur because fallback systems remain weaker than primary authentication.
Restrict OAuth Consent Permissions
Many enterprises still allow broad user consent to third-party applications. This is dangerous. OAuth consent should be tightly governed:
Disable unrestricted user consent
Require admin approval workflows
Restrict high-risk scopes
Audit delegated permissions continuously
Monitor unusual OAuth grant activity
Attackers increasingly target OAuth because it provides persistence without malware.
One of the strongest policy shifts enterprises can make is requiring OAuth authorization only from compliant managed endpoints. This means:
Intune compliant devices
Managed laptops only
Device health attestation
Endpoint posture validation
Conditional Access enforcement
Combined with TokenCore proximity enforcement, this creates a much harder environment for remote attackers. Even if a user is socially engineered, the attacker cannot simply authorize arbitrary unmanaged infrastructure.
OAuth access tokens and refresh tokens should not live indefinitely. Organizations should aggressively reduce refresh token lifetime, session persistence duration, and idle session duration.
Continuous Access Evaluation should be enabled so risk changes invalidate sessions dynamically. Stolen delegated authorization becomes far less useful when sessions expire quickly and are constantly reevaluated.
Audit Device Code Events Aggressively
Security teams should begin treating device code flow activity as a monitored high-risk event class. Hunting should include:
Geographic anomalies
Impossible travel
New device registrations
Unusual OAuth grants
Authorization spikes
High-volume token issuance
Suspicious consent patterns
Most SOC teams still monitor passwords more aggressively than OAuth authorizations. That must change immediately.
This is perhaps the most important organizational lesson.Historically, authentication teams managed login security; Application teams managed OAuth; and Cloud teams managed SaaS integrations. Attackers exploit these organizational gaps.
OAuth governance must now become part of core enterprise identity security architecture.
The FBI warning demonstrates a critical evolution in enterprise security thinking. Authentication strength alone is no longer the sole control plane. Enterprises now need biometric assured identity combined with authorization governance, device trust, application trust, and contextual risk evaluation.
Biometric FIDO2 authentication provided by TokenCore devices significantly raises attacker cost because it eliminates many traditional compromise paths entirely:
No phishable shared secrets
No reusable OTP codes
No push fatigue approvals
No spoofed origin authentication
No remote relay authentication
No credential replay
Enterprises must now extend that same rigor into OAuth authorization workflows themselves.
The FBI warning is not merely about Microsoft device codes. It is a signal that identity attacks are evolving beyond credential theft and into authorization manipulation. That distinction matters enormously.
TokenCore devices already shut down many of today’s most dangerous attacks because they eliminate phishable authentication factors and enforce biometric assured identity using hardware-bound biometric FIDO2 verification.
Enterprises must now pair strong authentication with equally strong authorization governance.
The future of identity security is not just: Did the user authenticate?
It is: What exactly did the user authorize, under what assurance conditions, on which device, for which application, and with what level of physical identity verification?
Organizations that evolve their policies around that question will dramatically reduce their exposure to the next generation of identity-based attacks.