Picture a fictional Sarasota closing: an assistant receives a “closing documents ready” invitation with a code and instructions to verify through Microsoft. The page really is Microsoft's. Before entering anything, the useful question is not just “Is this website genuine?” It is “Did I initiate this sign-in, and which device am I authorizing?”
Our recommended staff rule: enter a device code only for a sign-in you deliberately initiated on an approved device or app. Stop unsolicited document-access or “IT verification” requests and call your known technical contact independently. Build that pause into your real estate IT workflow, including assistants, closers, and shared-inbox delegates—not only the owner.
How a real Microsoft page can authorize the wrong device
The FBI's May 21, 2026 alert describes Kali365, a phishing kit first identified in April 2026.[38] This is an existing advisory, not an announcement of a new Sarasota outbreak this week.
In the FBI's account, an email supplies a device code and directs the recipient to a legitimate Microsoft verification page; entering it unknowingly authorizes the attacker's device.[38] The resulting access and refresh tokens—digital credentials used to access an account and renew access—can open Microsoft services including Outlook, Teams, and OneDrive.[38] This is abuse of account authorization, not merely a counterfeit password page.
Device-code sign-in also has legitimate uses, including shared devices and digital signage that lack local input devices.[53] The goal is not to teach staff that every code is malicious. It is to make deliberate, approved sign-ins distinguishable from someone else's request.
Give staff a pause, verify, and report handoff
We recommend a short rule card beside the closing checklist. A rushed team member should not have to interpret a technical alert:
- Pause: Do not enter an unsolicited code, continue an unexpected authorization, or forward the request to a colleague to “try it.” A document deadline is not approval.
- Verify: Contact the designated technical lead through a saved office number or approved channel, not contact details in the message. Explain which task you were trying to complete and whether you initiated any sign-in.
- Report: Preserve the message for the response lead through the approved reporting route. Record when it arrived and what you did. Do not copy passwords, active codes, or client financial details into a general help request.
For a Bradenton title office with rotating closing assistants, name a backup contact and an approved way to obtain documents while the request is checked. Practice with a fictional invitation, without real codes or customer files. Make reporting easy and blame-free.
What IT should document before restricting the flow
Microsoft recommends getting as close as possible to a unilateral block on device-code flow, retaining only necessary, documented and secured use cases.[51] The FBI also advises auditing legitimate dependencies before creating a restriction.[38] Our implementation checklist below turns that guidance into a controlled change; it is not a mandate to enable a policy immediately.
- Find actual use. Review sign-in logs with the Authentication Protocol filter set to device code; Microsoft also describes report-only policies as an audit method.[53] Record the users, applications, devices, business owners, and workflows that need investigation. Ask staff about shared equipment rather than assuming an empty sample proves no dependency exists.
- Check scope and licensing. Conditional Access requires Microsoft Entra ID P1.[44] Have the administrator verify licensing and coverage for the intended population. Buying a subscription is not evidence that this policy is configured or enforced.
- Design and observe. Microsoft's block-policy guidance targets all users and all resources, selects the device code flow condition and Block access, and starts in Report-only.[51] Report-only observes policy impact; it does not block access.[51] Deliberately exclude and monitor emergency-access accounts, and regularly audit exclusions as Microsoft directs; do not turn necessary emergency access into a blanket staff bypass.[51]
- Test, review, then enable. Protocol-tracked sessions can affect subsequent resource access.[53] Our recommendation is to test Outlook, Teams, closing-document workflows, and device registration where relevant; resolve failures and document any narrowly justified exception before the authorized administrator enables the controlled block. Name the approval and rollback owners in advance.
- Verify and retain evidence. Record policy scope, state, approved exceptions, test results, and review dates. Verify that intended restrictions work and approved work remains usable. Label observations honestly: a report-only result is not proof of enforcement. Schedule an exception review and keep the rollback procedure available.
Keep multifactor authentication (MFA) enabled. CISA recommends aiming for phishing-resistant MFA, starting with administrators and staff handling sensitive data.[16] Pair that work with flow restrictions and intentional approvals; do not promise that stronger MFA alone prevents someone from approving an attacker-controlled device on a real sign-in page. Our Microsoft 365 security services address the configuration and evidence behind those controls.
Keep account security separate from payment authorization
ALTA's outgoing-wire checklist calls for an independently sourced phone number, never the number included in an email, alongside verification of outgoing details and delivery.[48] Keep that independent verification step even when an email looks familiar or the sender uses Microsoft 365.
Our recommendation: an MFA badge, secure-score result, or familiar domain must never become authorization to release escrow funds. Follow the agency's approved payment controls and underwriter instructions. Our ALTA wire fraud prevention guide covers the broader technical and procedural layers; account protection and wire approval are separate checks.
If someone already entered an unsolicited code
Our recommended response handoff: immediately contact the designated incident-response lead through a known channel. Say what happened, which account was involved, and the approximate time and time zone. Retain the original message and relevant times in restricted evidence storage without spreading live codes or credentials.
Have trained responders contain account access and review sign-ins, sessions, mailbox rules, and connected app access. Do not treat a password reset alone as a completed investigation, delete evidence indiscriminately, or ask staff to experiment with the request again. The response lead should coordinate business continuity and any counsel or insurer involvement.
If funds have moved, contact the originating bank immediately through a known number and use our real estate wire fraud response plan. Do not wait for the account investigation to finish. Recovery is not guaranteed, and this website's audit-request form is not an emergency response channel.
Three things you can do this week
- Rehearse the pause. Give assistants, closers, and delegates a fictional document invitation. Have each person identify the known technical contact and explain why a real Microsoft page does not establish who initiated the code.
- Request an evidence review. Ask your administrator for actual device-code usage, licensing and policy scope, a report-only review, documented exceptions, and a tested approval/rollback plan—not just “MFA is on.”
- Check the payment handoff. Confirm where independently verified phone numbers are stored and who owns outgoing-wire approval. Keep the bank's fraud contact available outside the closing mailbox.
Make the next closing's handoff clearer
We help Sarasota and Manatee businesses review systems and access responsibilities. Our Free Systems Audit is free and on-site at your business. Visits usually take 45–60 minutes within a 60-minute reserved calendar slot. Every completed visit includes a full, customized Client Threat & Architecture Report with prioritized practical findings.
Gregory Mathews, Systems Architect, Suncoast MIS LLC
Source Notes and Scope
The FBI advisory supplies the attack description; Microsoft documents the authentication flow, policy, and licensing; CISA addresses MFA; ALTA supplies outgoing-wire guidance. Our staff handoff, testing sequence, response recommendations, and weekly tasks are implementation advice, not requirements prescribed verbatim by those publishers. This article makes no tenant changes and is technical education, not legal advice or a compliance certification. The title agency retains responsibility for escrow authorization, underwriter instructions, and applicable legal and contractual duties.
Sources
- [16] Require Multifactor Authentication | CISA
- [38] Internet Crime Complaint Center (IC3) | Kali365 Phishing-as-a-Service Kit Hijacks Microsoft 365 Access Tokens
- [44] Overview of Conditional Access Authentication Strengths - Microsoft Entra ID | Microsoft Learn
- [48] ALTA Information Security Committee — Outgoing Wire Preparation Checklist
- [51] Block authentication flows with Conditional Access policy - Microsoft Entra ID | Microsoft Learn
- [53] Authentication flows as a condition in Conditional Access policy - Microsoft Entra ID | Microsoft Learn
Author & technical scope review
Gregory Mathews
Gregory is the Systems Architect and founder of Suncoast MIS, with 15+ years of practical IT and systems architecture experience. He authored this article and reviewed its technical scope. Compliance, legal, and insurance conclusions remain with each organization and its qualified advisors.