A Microsoft sign-in code can give someone else access
By Tyler Mayberry · Cirlet. Published . Page updated .
Sources checked November 7, 2026 UTC. The practice example is fictional, not an account of an agency incident.
A real Microsoft sign-in page doesn't prove the request that sent you there is legitimate. If a message asks you to enter a code to open a document or join a meeting, pause. Confirm the request through a phone number or contact route you already know, and ask your IT provider if you weren't expecting to sign a device in.
Microsoft described an AI-enabled phishing campaign in April 2026 that used personalized messages and a legitimate sign-in process to obtain access to organizational accounts. The messages included themes such as invoices and requests for proposals. Microsoft did not say the campaign specifically targeted insurance agencies.
In a separate May 2026 report, incident-response company PacketWatch said most victims in the incidents its team described were in insurance or financial businesses. The report doesn't give a sample size or say how many were independent agencies. It does show why a familiar-looking document request deserves a second look.
What the code does
Microsoft's device-code sign-in lets a person sign an application or device in using another device. There are legitimate uses, including some shared or limited-input devices.
In the attack Microsoft described, the attacker creates a sign-in request and persuades the recipient to enter the attacker's code on a genuine Microsoft page. If the recipient completes the process, the attacker can receive tokens that let them use the account's permissions. A real Microsoft page and a completed multifactor prompt don't establish that the original request was authorized.
Try this example with your team
This is a fictional practice scenario, not an incident at a real agency.
A producer gets a message that appears to be from a familiar carrier contact. It says a document is ready and asks them to copy a code into a Microsoft sign-in page. The producer wasn't setting up a device and wasn't expecting this request.
The producer stops, contacts the carrier using a number already on file and tells the agency's IT provider what they saw. They do not use the contact details in the suspicious message to verify it. The provider can review the request before anyone continues.
An unexpected code request isn't proof of fraud by itself. The point is to check who initiated the sign-in and what device or application is being authorized.
If someone already completed it
Contact your IT provider or security lead immediately using a trusted route. Tell them which account was used, roughly when it happened and what you saw. Preserve the message according to your agency's incident process. Don't send passwords, sign-in codes or client records in a reply to the suspicious message.
Microsoft's response guidance covers investigation of a compromised Microsoft 365 account, including disabling an affected account during investigation, revoking sessions and checking forwarding and inbox rules. Its campaign report warns that existing access tokens may remain usable for a period after standard session revocation. Your provider needs to assess the account and environment; simply changing a password is not a complete investigation.
Ask your Microsoft 365 administrator
Ask your administrator or provider whether your organization uses device-code sign-in, where it is needed and what policy currently applies. Microsoft recommends blocking the flow where possible and using documented, secured exceptions where necessary.
Microsoft documents sign-in logs and report-only Conditional Access policies as ways to assess use before enforcing a change. A change may interrupt devices or applications that depend on the flow, so the provider should check dependencies and emergency access before changing anything. Available controls depend on the tenant and licensing.
Microsoft also says Security Defaults block device-code requests when enabled. Its current documentation says new Microsoft Entra tenants created from July 1, 2026 block the flow as part of Security Defaults. That is not proof of the setting in an existing agency's tenant. Ask the administrator to verify the actual configuration.
Sources
- Microsoft Defender Security Research: AI-enabled device-code phishing campaign, April 6, 2026.
- PacketWatch Team Sixty43: device-code phishing, May 28, 2026. Its insurance/financial observation describes its own incident sample only.
- Microsoft Learn: authentication flows in Conditional Access, checked November 7, 2026 UTC.
- Microsoft Learn: block device-code flow with Conditional Access, checked November 7, 2026 UTC.
- Microsoft Learn: configure Security Defaults, checked November 7, 2026 UTC.
- Microsoft Learn: respond to a compromised cloud email account, checked November 7, 2026 UTC.
Related: Prepare for email fraud · Practice an account recovery decision · Build a provider action plan.