About two weeks after Microsoft published their research on the personal-phone social engineering campaign, I started receiving questions from security leads. They all wanted to know: how do we protect against threats that start outside our perimeter, on devices we don't manage, targeting people who think they're helping?
Here's what I told them.
Understanding the Threat
The campaign Microsoft tracked since May 2026 marks a shift in attacker tactics. Attackers call employees on personal mobile phones, posing as IT staff, and guide them through what seems like a routine passkey or MFA update. This happens outside your managed environment. The phishing page looks legitimate, and the employee believes they're being compliant.
Once inside a Microsoft 365 account, attackers register their own authentication method to maintain access, then use Microsoft Graph to extract files and emails at rates designed to stay under 1,000 items per hour, blending into normal usage patterns. Some intrusions lasted days before detection.
Security leaders are trying to close this gap without creating friction that could worsen the problem.
Training Employees to Recognize Threats
Focus on the channel, not the content. Your training should emphasize one rule: IT will never call your personal phone to fix your work account.
That's the key. Not the urgency, not the professional tone, not the realistic-looking link. The fact that someone called a device your IT team doesn't manage to perform an action on a system your IT team does manage is the red flag.
Build your awareness program around this decision rule. If someone contacts you on a personal device about work credentials, the response should always be: hang up, open a ticket through your normal IT channel, and report the contact to security. No exceptions.
Test this understanding. Your tabletop exercises should include this scenario. Your phishing simulations should use SMS and voice, not just email. NIST SP 800-50 emphasizes testing awareness under realistic conditions, and this threat requires simulating the actual attack vector.
Managing Personal Device Security
While you can require employees to install MDM on personal phones, expect resistance and potential legal issues. More importantly, it won't solve the core problem.
The attack succeeds because the employee believes the call is legitimate and voluntarily gives access. MDM on a personal device won't prevent that. It might provide visibility after the fact, but by then the attacker has already registered their own MFA method and established persistence.
A better approach is to implement Conditional Access policies that require managed devices for access to Exchange Online, SharePoint, and any application with privileged Graph permissions. Microsoft's recommendation is clear: if the employee's personal phone isn't enrolled, it can't authenticate to corporate resources.
This shifts the conversation from "install our software on your personal device" to "use your corporate laptop for corporate work." It's legally cleaner, operationally clearer, and more defensible from a data protection standpoint.
Detecting Suspicious Graph Activity
Individual Graph API calls won't trigger alerts. A single request to /users or /sites looks like legitimate enterprise traffic. The signal comes from behavioral progression: an identity querying user data, then group memberships, then admin roles, and finally moving into file enumeration and email access in a short timeframe.
Your SIEM should correlate Graph activity across event categories, not flag individual requests. Look for:
- Sequential queries moving from reconnaissance (users, groups, roles) to collection (files, mail)
- Access patterns that touch multiple Graph endpoints quickly
- Sustained file or email access at consistent rates just below 1,000 items per hour
- User agents like python-httpx paired with high-volume data access from a single session
The user agent alone isn't significant; legitimate automation often uses python-httpx. It's the combination of that agent, sustained collection activity, and a recently modified MFA configuration that matters.
Auditing for Rogue MFA Methods
Audit your authentication methods now, not after an incident. Every identity in your tenant should have its registered MFA methods reviewed against a known-good baseline.
Microsoft Entra ID logs every authentication method registration. Your audit should flag:
- New phone numbers or authenticator apps added outside your standard provisioning process
- MFA methods registered from IP addresses that don't match your corporate network or approved remote locations
- Multiple MFA methods registered to the same identity within a short window
Automate this process. Build a script that pulls registered authentication methods for all users, compares them against your CMDB or HR system, and flags anomalies for manual review. Run it weekly at minimum.
If you find a rogue method, assume the account is compromised. Reset credentials, revoke all sessions, remove the unauthorized MFA registration, and review Graph API activity for that identity over the past 30 days.
Implementing Phishing-Resistant MFA
Phishing-resistant MFA involves authentication methods that can't be intercepted or replayed through an adversary-in-the-middle attack. NIST SP 800-63 defines this as authentication bound to a specific origin, typically using public-key cryptography.
Examples include FIDO2 security keys, Windows Hello for Business, and certificate-based authentication. These methods verify the authentication request came from the legitimate service, not a lookalike domain.
SMS codes, authenticator app one-time passwords, and push notifications don't meet this standard. An attacker running an AiTM proxy can intercept them and use them to authenticate to the real service while the user thinks they're logging into a fake page.
The campaign Microsoft tracked used passkey-themed lures because employees are being trained to adopt passkeys. The irony is that actual passkey implementation would have blocked the attack, but the social engineering worked because people heard "passkey" and thought "new security requirement I need to comply with."
Defining Access for Personal Devices
You don't need to block all personal device access, but you must define which resources personal devices can reach and under what conditions.
A risk-based approach allows personal device access to low-sensitivity resources like company announcements or training materials. Require managed devices for email, file storage, and anything involving customer data or Personally Identifiable Information.
CIS Controls v8.1 Control 4.1 calls for establishing and maintaining a secure configuration process for enterprise assets. Extend that thinking to access policies. Every resource should have a documented access policy specifying device requirements, authentication strength, and acceptable use conditions.
Enforce it through Conditional Access. Don't rely on policy documents; make the technical controls match the written policy. If SharePoint requires a managed device, configure Conditional Access to block unmanaged device access to SharePoint.
Next Steps
Microsoft's Conditional Access documentation covers the technical implementation for managed-device requirements and phishing-resistant MFA. NIST SP 800-63 provides the authentication assurance levels that underpin these decisions. CIS Controls v8.1, particularly Controls 4, 6, and 14, offer a prioritized framework for asset management, access control, and security awareness.
The broader lesson: your security perimeter now includes every device that can authenticate to your tenant, whether you manage it or not. Design your controls accordingly.
