When I talk to home health administrators about MFA, the conversation usually ends the same way: "We have MFA. We are protected from credential theft." That statement was more accurate eighteen months ago than it is today. Since September 2025, multiple threat groups — some financially motivated, some state-affiliated — have scaled a phishing technique that does not steal passwords and does not break MFA. It uses Microsoft's own website to gain access to your staff's Microsoft 365 accounts, and the only visible sign that something has gone wrong is a staff member entering a code on a page that is genuinely, legitimately microsoft.com.
This is OAuth device code flow abuse — a technique that weaponises a legitimate Microsoft authentication workflow to obtain long-lived access tokens that provide full API access to email, files, calendar, and collaboration tools without ever touching the user's password or intercepting their MFA code. The attack kits that automate it — Square Phish and Graphish are the most widely deployed — are available in criminal markets and are increasingly used against healthcare targets, including home health agencies, specifically because healthcare organisations heavily rely on Microsoft 365 for clinical coordination and billing communication.
Understanding this attack is not optional for home health administrators who have invested in MFA as their primary credential protection. MFA does not stop this attack. Conditional Access policies configured correctly do. The difference between those two things — and what specifically needs to be configured to close the gap — is what this article addresses.
What OAuth Device Code Flow Is — And Why It Exists
Before explaining how this attack works, it helps to understand what OAuth device code flow is and why Microsoft built it. The device code flow is a legitimate authentication mechanism designed for devices that cannot display a browser or accept keyboard input — smart TVs, printers, IoT devices, or command-line tools running on servers. These devices cannot complete a standard browser-based login where you type credentials into a webpage. Instead, they display a code and direct the user to visit microsoft.com/devicelogin on a separate device — typically a smartphone or laptop — where they enter the code and authenticate. The authentication happens on the second device; the original device receives the resulting access token.
This is a reasonable solution to a real problem. The workflow is legitimate, the page is genuine, and the process works as designed. The attack exploits the fact that nothing in this workflow looks suspicious to a user — because nothing technically is. The attacker simply generates the device code for their own attacker-controlled application instead of a legitimate device, delivers that code to the victim through a phishing email, and waits for the victim to enter it on Microsoft's real page. When they do, Microsoft issues an access token — to the attacker's application, not the victim's device.
The Attack Sequence: What Your Staff Member Actually Experiences
The abstract explanation of OAuth device code abuse is less instructive than understanding what a home health billing coordinator or clinical supervisor actually experiences when this attack targets them. Here is the realistic attack sequence as it plays out in a home health context.
Step 1: The Phishing Email Arrives
The email appears to come from Microsoft 365 IT Support, from the agency's administrator, or — in the more sophisticated campaigns targeting healthcare — from the agency's EHR vendor requesting re-authorisation of the EHR's Microsoft 365 integration. The subject line might read: "Action Required: Re-authorize Microsoft 365 Access for [EHR Platform] Integration" or "Your Microsoft 365 session has expired — verification required to restore access."
The email is convincing for a specific reason: it does not ask the recipient to click a link to a fake website. It asks them to visit microsoft.com/devicelogin — Microsoft's real website — and enter a provided code. The email may contain a QR code that opens the page on a mobile device, or a direct link to the legitimate Microsoft URL. Advanced versions embed the code in what appears to be a PDF attachment with official Microsoft branding.
Step 2: The Staff Member Visits Microsoft's Real Website
The staff member navigates to microsoft.com/devicelogin — the genuine, legitimate Microsoft authentication page. The browser shows a valid SSL certificate for microsoft.com. The page looks exactly like any other Microsoft authentication page because it is. No security tool flags it as malicious. The browser's phishing protection does not trigger. The staff member feels safe because they are on Microsoft's actual domain.
They enter the code from the email. They may be prompted to sign in to their Microsoft 365 account if they are not already signed in — and they do, completing their normal MFA authentication on the same real Microsoft page. Their MFA code is entered to Microsoft's legitimate authentication system. Nothing about this interaction involves a fake page or a credential-stealing tool.
Step 3: The Attacker Receives the Access Token
When the staff member completes the device code authentication, Microsoft issues an OAuth access token to the application identified in the device code request — which is the attacker's application, not the legitimate EHR integration the email described. The attacker's application receives this token immediately. The token provides full Microsoft Graph API access to the staff member's account: all emails, all files in OneDrive and SharePoint, calendar appointments, Teams conversations, and any other Microsoft 365 data the account can access.
The token also comes with a refresh token — a long-lived credential that allows the attacker to obtain new access tokens without any further user interaction, even if the staff member changes their password later. The refresh token persists until it is explicitly revoked. The attacker now has persistent, authenticated access to everything in the staff member's Microsoft 365 account, obtained through Microsoft's own authentication system, with no stolen credentials and no intercepted MFA codes.
Step 4: The Damage That Follows
With persistent Microsoft 365 access, the attacker's objectives in a home health targeting campaign are specific. The email archive contains years of clinical communication — patient names, home addresses, care coordination correspondence, physician order confirmations, and billing correspondence with Medicare and insurance companies. This data is valuable for both data exfiltration (the HIPAA breach) and for social engineering further targets (using the compromised account to send trusted-looking phishing emails to physicians, referral partners, and other staff). The SharePoint or OneDrive files may contain patient lists, care plans, HIPAA documentation, and financial records. Teams conversations may contain clinical discussions with patient information that are now fully readable by the attacker.
The billing coordinator whose account is compromised through this technique provides the attacker with access to Medicare correspondence, insurance company communications, prior authorisation documentation, and payment-related email threads — precisely the data that enables BEC attacks targeting billing payment redirection. The clinical supervisor whose account is compromised provides access to the care coordination communication that enables targeted social engineering of physicians and referral hospital discharge planners.
Why MFA Does Not Stop This Attack
This is the question that most home health administrators ask when they first understand the OAuth device code attack: if we have MFA enforced, why does this work? The answer requires understanding what MFA actually protects against and what it does not.
MFA protects against an attacker who has stolen a password trying to authenticate with that password. When an attacker enters a stolen username and password into a Microsoft login page, MFA requires a second factor — the authenticator app approval, the SMS code, the hardware token — that the attacker does not have. The authentication fails. The attacker cannot access the account.
The OAuth device code attack does not involve the attacker entering stolen credentials. The victim enters their own credentials, to their own account, on Microsoft's real website, completing their own MFA authentication. MFA succeeds — because the authentication is genuine. The attacker does not need the credentials or the MFA code. They receive the token that Microsoft issues at the end of the successful authentication process. MFA was designed to protect the authentication. The device code attack exploits the token issuance that follows successful authentication. These are different things, and MFA addresses only the first.
What Actually Stops This Attack: The Platform Configuration That Closes the Gap
Option 1: Block Device Code Flow Entirely
The most effective defence against device code flow abuse is to disable the device code authentication flow in your Microsoft Entra ID Conditional Access policy for all users who do not have a documented operational need for it. A Conditional Access policy that blocks the device code flow for all users except a specifically defined group eliminates the attack vector entirely for everyone outside that group.
For most home health agencies, the operational question is: which staff members legitimately use applications that require device code flow? For the vast majority of home health employees — clinical staff using the EHR, billing coordinators using the billing platform, administrative staff using Microsoft 365 — the answer is none. Their applications authenticate through standard browser flows. Device code flow is not required for any of their daily workflows. Blocking it for all home health staff eliminates the attack surface with no operational impact.
Confirm with your IT administrator or managed security provider whether any legitimate applications in your environment require device code flow before blocking it globally. If specific applications require it, create a Conditional Access policy that permits device code flow only for the named applications and only from compliant, managed devices — which eliminates the attacker's ability to use a device code generated for an attacker-controlled application from an unknown device.
Option 2: OAuth App Consent Policy Tightening
As a complementary control, tighten the OAuth application consent policies in your Microsoft 365 tenant. The default Microsoft 365 configuration allows users to grant consent to third-party applications requesting access to their Microsoft 365 data without administrator approval. This default enables the attacker's application to receive the token the victim grants during the device code authentication — because the victim's consent is all that is required.
Changing the app consent policy to require administrator approval for all third-party application consents means that even if a staff member completes the device code authentication for an attacker-controlled application, the token issuance is blocked pending administrator review. This does not eliminate the device code attack entirely — the blocked consent is itself a security event that requires monitoring — but it adds a friction point that interrupts the attack before the attacker receives persistent access.
Option 3: 24/7 Monitoring for OAuth Token Anomalies
When Conditional Access policies are in place, 24/7 SOC monitoring provides the detection layer that catches attack attempts that the policies flag but do not automatically block. Microsoft Entra ID generates sign-in logs and OAuth consent logs that record every authentication event, every token issuance, and every application consent. Anomalous patterns — device code flow authentication attempts from unusual locations, consent grants to unfamiliar applications, access token usage from IP addresses inconsistent with the authenticating user's normal location — are detectable in these logs in real time.
A SOC analyst reviewing these logs continuously can identify an OAuth device code attack attempt within minutes of the token issuance — and initiate token revocation before the attacker has had time to access and exfiltrate email data. Token revocation through Microsoft Entra ID immediately invalidates the access token and all associated refresh tokens, terminating the attacker's persistent access. The window between token issuance and SOC-initiated revocation is the dwell time for this attack variant — and 24/7 monitoring compresses that window from hours or days to minutes.
Staff Training for This Specific Attack Pattern
The three platform controls above stop the attack at the technical level. Staff training addresses the human layer — reducing the probability that staff members complete the device code authentication in the first place.
Standard phishing awareness training does not address OAuth device code abuse because it teaches users to be suspicious of links that lead to fake websites. This attack leads to Microsoft's real website. Staff who have been trained to look for fake domains, check SSL certificates, and verify that the URL is genuine will complete this authentication and feel that they did everything right — because they did everything their training taught them to do.
The specific training content that addresses this attack: "Microsoft will never send you an email asking you to visit microsoft.com/devicelogin and enter a code unless you initiated a device setup process yourself. If you receive any email, text, or notification asking you to enter a code on Microsoft's device login page — regardless of how official it looks or who it appears to be from — do not enter the code. Stop, call IT, and report the message before taking any action." This is a specific, actionable instruction that directly addresses the attack mechanism. It should be added to the annual security awareness training and sent as a targeted communication to all Microsoft 365 users.
The HIPAA Implication: Why OAuth Token Compromise Is a Breach
When an attacker obtains OAuth access tokens to a home health staff member's Microsoft 365 account and accesses emails containing patient information, the HIPAA four-factor breach risk assessment must be initiated. The compromise of OAuth tokens that provide access to PHI is not categorically different from the compromise of a password that provides the same access — both result in unauthorised access to protected health information, and both trigger the HIPAA breach assessment process.
The specific HIPAA implication of OAuth token compromise is that the scope of the potential breach includes everything in the compromised Microsoft 365 account that contains PHI — which for a billing coordinator or clinical supervisor may include years of email correspondence, shared files in OneDrive and SharePoint, and Teams conversation history. The scope assessment for a Microsoft 365 OAuth token compromise is therefore typically larger than the scope for a single EHR credential compromise, because the email platform holds a broader and deeper collection of PHI than any single clinical application.
The OAuth device code attack is live, scaling, and specifically targeting healthcare Microsoft 365 environments. MFA alone does not stop it. The combination of device code flow blocking through Conditional Access, tightened app consent policies, 24/7 monitoring for token anomalies, and targeted staff training specific to this attack pattern is what closes the gap. ShieldForce configures all of these controls as a standard component of every home health Microsoft 365 security deployment. Start with a free assessment and confirm whether your current Conditional Access configuration blocks device code flow.
→ Schedule Your Free HIPAA Risk Assessment — shieldforce.io/hipaa-assessment
→ Explore Home Healthcare Cybersecurity — shieldforce.io/home-healthcare
→ View Transparent Pricing from $35/user/month — shieldforce.io/pricing-comparison