Microsoft Email Security picks up 13 new Fortune 500 companies in the past 10 months, growing at 11%.  Between Microsoft and Proofpoint, they have captured 76% of the email security market.

Source: Public DNS MX Records

Microsoft Defender for Office 365 now uses purpose-built Large Language Models (LLM) at scale to provide AI-powered email and collaboration security. The solution parses language to understand and identify attacker intent and classifies threats at machine speed.

Microsoft is reporting 99.995% attacker intent detection accuracy and filtering, and is blocking 140,000 Business Email Compromise per day, based on the new LLM model. Source: https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/microsoft-ignite-redefining-email-security-with-llms-to-tackle-a-new-era-of-soci/4302421

At Patriot, we migrated over 40 companies from Proofpoint and Mimecast to Microsoft Defender for Office in the last 12 months. The average migration takes about 90 days, because our process involves a careful examination of the customer configuration to make sure that the migration goes smoothly without a hitch. Contact our account team for a quote and a free detailed comparison between Proofpoint or Mimecast to Microsoft (hello AT patriotconsultingtech.com)

When I meet customers using OKTA as their Identity and Access Management, the following three questions often come up: (1) is Microsoft as good or better? (2) Can I save money by consolidating to Microsoft? and (3) How long does the migration take?

Is Microsoft as good or better than OKTA? Yes.

The table below summarizes the evaluation with a scoring system (1 = Poor, 5 = Excellent) for each criterion. All criteria are equally weighted. Each score is justified by the underlying capabilities and considerations discussed in subsequent sections.

Gartner ranks Microsoft as the vendor with the highest ability to execute features:

(source)

Can I save money by consolidating to Microsoft? Yes.

Okta’s identity services are an additional expense on top of Microsoft 365. For example, Okta charges roughly $2/user/month for basic SSO, plus $3/user for basic MFA; the adaptive security versions are about $5 and $6 respectively​ (source pathlock.com)

This means a full Okta SSO + adaptive MFA solution can cost $11 per user. In contrast, the entire M365 E5 Security bundle is $12/user as an add-on to M365 E3, but you get the full XDR Stack! (EDR, CASB, Email Security, all in a single unified console!) (source infusedinnovations.com)

For instance, one study found a 77% cost savings for a 5,000-user organization using M365 E3 + E5 Security compared to a mix of CrowdStrike, Okta, and Proofpoint for equivalent security coverage (source).

How long does the migration take? Not as long as you think.

How many apps do you have? Divide that by 10, and that is roughly the number of weeks it can take to migrate from OKTA to Microsoft. We have a special tool that Microsoft has provided us to streamline the migration effort, which can help us move even faster. We also qualify for Microsoft funding programs that can pay our consultants to do the work for you.

Security Considerations

Identity Protection & Risk Detection: Both Okta and Microsoft Entra ID provide risk-based authentication, but Microsoft’s capabilities are significantly more extensive. Microsoft Entra ID Protection has 28 built-in risk detection types (such as unfamiliar sign-in properties, impossible travel, leaked credentials, etc.), leveraging Microsoft’s vast telemetry (trillions of signals) and machine learning to assess user/sign-in risk. By contrast, Okta’s risk engine is less transparent about the number of detection signals – it primarily evaluates behavioral anomalies or IP-based reputation. Okta does offer adaptive MFA based on risk scores (e.g. network, device, location contexts) and can integrate with partner tools for enhanced threat signals, but it doesn’t natively match the breadth of Microsoft’s global threat intelligence which handles 78 trillion signals per day. In practice, Microsoft Entra Identity Protection will flag more diverse risk events automatically, while Okta requires additional effort and cost to pull in external partner signals. 

Extended Detection & Response (XDR): Microsoft 365 E5 includes the Microsoft 365 Defender XDR suite, which goes far beyond identity. This suite covers: Defender for Endpoint (EDR), Defender for Identity (monitoring on-prem AD for threats), Defender for Office 365 (email and collaboration threat protection), and Defender for Cloud Apps (SaaS Security)​.

These tools work together to correlate threats across domains (identity, devices, email, cloud). Okta does not provide endpoint or email security – it would rely on third-party XDR solutions for those. In other words, with E5 you get an integrated XDR that can identify, for example, a malware-infected device and automatically prevent that device’s user from accessing corporate apps, something Okta alone cannot do. Okta’s contribution to security is mainly identity-centric (preventing unauthorized access via SSO/MFA and de-provisioning access quickly), but it doesn’t monitor for malware, phishing, or lateral attack patterns. The Defender XDR capabilities in E5 significantly bolster an organization’s security posture beyond authentication alone.

Automated Attack Disruption: Because Microsoft’s tools cover multiple attack vectors, they can also coordinate automated responses. Microsoft’s Automatic Attack Disruption feature (in preview/ignite 2024 announcements) is designed to contain active attacks in real-time by isolating compromised identities or devices across the ecosystem. For instance, if a user account is suspected to be compromised as part of a ransomware attack, the system can automatically suspend the account and isolate the device to stop the attacker’s progress. Okta’s platform, on its own, can lock an account after detecting anomalous behavior (zero-trust approach to suspicious logins​), but it lacks the device-side response. It cannot quarantine a machine or cut off email phishing internally – those would require separate solutions. Thus, Microsoft E5 provides a more comprehensive active defense, automatically disrupting attacks across identity and devices, whereas Okta’s response is limited to identity containment (which, while important, addresses only one piece of an active threat).

Security Copilot (AI-Assisted Security): Microsoft has introduced Security Copilot, an AI-driven assistant for security analysts (available to customers of the Microsoft security stack for an additional fee). This tool uses generative AI on top of the aggregated data from Microsoft’s XDR and SIEM, helping to summarize incidents, suggest remediation, and even craft KQL queries. Okta currently has no equivalent AI security assistant. (Okta has begun integrating AI for threat protection in specific ways, but nothing like a broad incident copilot.) This means organizations on E5 can leverage cutting-edge AI to accelerate threat investigations and response, a capability missing from Okta’s offering.

Device Management (Intune vs. Okta): Microsoft 365 E5 (and E3) includes Microsoft Intune (part of Microsoft Endpoint Manager) for mobile device and PC management. Intune is tightly integrated with Windows – Windows 10/11 devices can be Azure AD joined and automatically enrolled in Intune without needing any third-party agent. Intune also manages iOS, Android, and macOS devices using native OS management frameworks. This means policy enforcement (like requiring compliant devices for access) works end-to-end with Azure AD Conditional Access. By contrast, Okta’s device management capabilities are limited. Okta did offer Okta Mobility Management (OMM), but that product has been end-of-lifed as of 2023 (Okta now encourages integrating with other MDMs like Intune, MobileIron, etc., for device compliance)​

Okta’s current approach to device security is via Device Trust – ensuring that only devices managed by a trusted MDM or with Okta Verify can access certain apps. This still requires a separate device management solution (such as Intune itself or another MDM) to actually manage the device’s health and compliance. Also, for desktop devices, Okta’s device trust often requires installing an agent or certificate on the device to validate it, whereas Intune management is part of the OS onboarding. The key takeaway: Intune (with M365) provides a full-fledged, integrated device management and is built into Windows, whereas Okta alone cannot manage devices and must be paired with an MDM – introducing additional complexity and cost if one isn’t already in place. In our scoring, Microsoft gets full marks for integration largely due to Intune’s presence and the Windows integration, plus things like Windows Hello and Azure AD Join which create a smooth authentication experience. Okta, while it can integrate with Intune and even automate some device context via its APIs, is not an out-of-the-box device management solution.

Need help? We can move the first few apps and train your team how to move the rest! Contact us at Hello At PatriotConsultingTech.com

Mitigating MiTM Token Theft in 2025: Why It’s Time to Adopt Passkeys

Introduction: Rising Threat of Token Theft Attacks

Adversary-in-the-middle (AiTM) phishing attacks have evolved to target even multi-factor authentication (MFA) in the cloud. Phishing kits like Evilginx2, Mamba 2FA, Rockstar2FA, Sneaky2FA, Tycoon 2FA, and operate as proxies that intercept user logins and steal session tokens. For example, the Mamba 2FA phishing-as-a-service kit uses well-crafted proxy login pages to capture victims’ authentication tokens and bypass MFA protections on Microsoft 365 accounts (New Mamba 2FA bypass service targets Microsoft 365 accounts). Similarly, Sneaky2FA has been observed intercepting Office 365 session cookies to give attackers full account access despite MFA (Your MFA Is No Match for Sneaky2FA). I first wrote about 7 methods of mitigating Evilginx2 back in 2019 (here).

These token theft proxy tools enable attackers to impersonate users by replaying stolen session cookies or tokens, effectively negating OTP codes or push notifications. In 2025, the prevalence of such kits has made phishing-resistant authentication a top priority for enterprises.

Passkeys – the new consumer-friendly term for FIDO2/WebAuthn credentials – have emerged as a robust defense against these threats. Unlike passwords or legacy MFA (which can be phished via proxy), passkeys use asymmetric cryptography tied to the authentic login domain. This means a phishing site cannot trick users into generating a valid credential for the attacker. Until recently, however, deploying phishing-resistant methods to all users (especially on mobile devices) was challenging. Physical FIDO2 security keys were effective but difficult to roll out at scale due to cost and user inconvenience. In 2025, that landscape is changing: passkeys are now generally available in Microsoft Authenticator as of March 3^rd 2025 (MC920300), offering organizations a practical way to eliminate phishing and MiTM token theft on every device without costly new hardware.

One thing I appreciate about the GA milestone is that key restrictions are no longer required to enable passkeys in Authenticator. This will make it so that organizations don’t have to run a script to gather all their GUIDs if they had previously deployed physical passkeys.

Another reason why the GA milestone is a big deal is because some orgs do not deploy features in Preview because they want the peace of mind knowing that Microsoft Support will fully back the solution if there is a major issue.

Documentation: https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-register-passkey-authenticator?tabs=iOS

My organization quickly adopted passkeys in Authenticator when they first reached public preview in May 2024. The initial struggle was the Android experience, which I’ll discuss later. Since then, things have gotten a lot better. It’s still always good to review the documentation, because as of this writing on March 16^th, Support for same-device registration in the Edge browser on Android is not yet available.

Passkeys in Microsoft Authenticator: A Phishing-Resistant Milestone

Microsoft’s support for passkeys in the Authenticator app reached general availability (GA) in January 2025, marking a critical milestone for enterprise security. This update “extends strong, device-bound passkeys from physical security keys to user mobile devices” (MC920300 – Microsoft Entra: Enablement of Passkeys in Authenticator for passkey (FIDO2) organizations with no key restrictions | Microsoft 365 Message Center Archive). In essence, every modern iOS or Android phone with Microsoft Authenticator can function as a FIDO2 security key. This is achieved by storing a cross-device FIDO credential securely in the app, bound to the phone hardware. Users can register a passkey for their Entra ID account right from inside the Authenticator app, or in the MFA setup portal (https://mysignins.microsoft.com/security-info), and the credential is backed by the phone’s biometric/PIN unlock.

Why is this so significant? Mobile devices historically lacked a simple, phishing-resistant auth method. Previously, the only option to get FIDO-level security on a phone was to use a physical security key (e.g. NFC or Lightning) in conjunction with the phone – an impractical solution for most users. By contrast, Microsoft Authenticator’s passkey feature delivers the same asymmetric, origin-bound authentication “on a device that people almost never lose” (their smartphone). This closes the strong-authentication gap that existed when only external security keys provided phishing-resistant login. Now, even a BYOD mobile phone can serve as a secure second factor that defeats MiTM proxies. In short, GA of passkeys in Authenticator means organizations finally have a ubiquitous, easy-to-deploy solution to stop phishing attacks from stealing login tokens on mobile devices.

Why Passkeys Outperform Traditional MFA

Passkeys offer several advantages over one-time passwords (OTP), push notifications, and other traditional MFA methods. Security professionals should consider the following benefits when planning their 2025 authentication strategy:

1. Phishing-Resistant on All Devices (No Special Hardware Needed): Passkeys use the FIDO2/WebAuthn standard, which cryptographically binds the authentication to the genuine website or application. This makes them immune to phishing/MiTM proxy attacks – an Evilginx-style reverse proxy can’t trick a passkey into signing in to the wrong domain. Crucially, users can get this protection via their existing smartphone. Unlike older approaches that required NFC tokens or smartcards for phishing resistance, passkeys work with the phone’s built-in secure enclave or authenticator app. There’s no need to distribute physical tokens to every user, or ensure all phones have specialized hardware or SIM-based PKI. By leveraging devices people already carry, passkeys make strong MFA far more accessible. Microsoft’s implementation even supports cross-device scenarios (using Bluetooth) to sign in to new devices, so users aren’t locked to one phone.
2. No Additional Hardware Costs or Logistics: Physical FIDO2 security keys are effective but can be expensive and cumbersome for large organizations. Users tend to lose physical keys, and backups are required – effectively doubling the cost per user. Buying and managing thousands of tokens (and dealing with replacements) posed a major barrier to broad FIDO2 adoption. Passkeys eliminate this cost by turning the smartphone into the security key. Every employee’s phone becomes a second factor device with strong cryptographic auth, at no extra per-user expense. This lowers the entry barrier for phishing-resistant MFA. The need for multiple hardware keys meant FIDO2 was often limited to privileged accounts, but passkeys on phones allow extending strong MFA to the entire workforce. Organizations can achieve passwordless, phishing-proof auth without budgeting for new gadgets.
3. Stronger BYOD Security with Minimal Friction: Many enterprises enforce device identity and management for corporate PCs (Windows Hello, Entra ID Join, etc.) but have a more lax policy for mobile BYOD. It’s common to allow employees’ personal phones for email and Microsoft 365 access with only a basic MFA (like an authenticator app OTP) and no device compliance requirement. Attackers have noticed this gap. If an organization doesn’t require the mobile device to be enrolled or “trusted,” a stolen session token from a phished mobile login can be reused by an attacker on any device. Passkeys help solve this by raising the security of mobile authentications to match that of managed PCs. Even if the phone is not MDM-enrolled, the authentication itself is device-bound and phishing-resistant. In effect, passkeys on BYOD phones deliver a level of assurance closer to a corporate-managed device login. This dramatically reduces the risk of an attacker exploiting a BYOD phone login with tools like Mamba or Evilginx. By deploying passkeys, organizations add a strong layer of defense for mobile users without forcing onerous device management or smartcard distribution.

How Attackers Exploit Gaps in Conditional Access Policies

Attackers are not only phishing users – they’re also exploiting weaknesses in how authentication policies are configured. Conditional Access (CA) in Entra ID is a powerful tool to enforce device compliance, locations, or app restrictions at login. But misconfigurations or inherent limitations can create loopholes that attackers abuse. Security teams need to be aware of these tactics when designing policies:

• Spoofing Device Platform to Bypass Restrictions: Conditional Access can target specific device platforms (Windows, iOS, Android, etc.) to apply different requirements. However, platform identification relies solely on the client’s user agent string, which is easily spoofed (The Attackers Guide to Azure AD Conditional Access – Daniel Chronlund Cloud Security Blog). If CA policies aren’t uniformly applied to all platforms, an attacker can simply fake a different user agent to slip past a policy. For instance, if an organization requires Intune compliance for Windows PCs but has no equivalent rule for iOS/Android, an attacker using a proxy like Evilginx can set their agent to “Safari on iPhone”. Entra ID will treat the session as a mobile browser and not enforce the Windows-specific policy – granting access when it should have been blocked. As one guide puts it, “modifying a device’s user agent is a trivial task… unless all platforms have similar CA policies, it’s an opportunity to bypass security controls.” (The 5 Most Common Conditional Access Misconfiguration | Practical365) In practice, weak platform-specific policies or missing “block” rules for unknown platforms are a common oversight that adversaries leverage.
• Lack of Device Identity on Mobile Sessions: Even with Microsoft Intune or other MDM, enforcing device compliance on personal mobile endpoints remains challenging. Many organizations hesitate to require full device enrollment on employee-owned phones due to privacy and usability concerns. At most, they might use app-level MAM (Mobile Application Management) or conditional launch for Outlook mobile, which doesn’t give the device a trusted identity in Entra ID. This means that when a user authenticates from a personal phone, Entra ID often sees it as an unmanaged device. Conditional Access can enforce “require device to be marked as compliant” for that session – but if the user isn’t enrolled, they simply cannot sign in (which may break business needs). As a result, some admins soften policies: they enforce device compliance on Windows/macOS, but allow mobile devices with just MFA as a compromise. Attackers are quick to exploit this gap between desktop and mobile security. By phishing a user’s mobile authentication (which only had a weak OTP), the attacker obtains a token that appears valid to Entra ID without any device ID or compliance claim. There is nothing to distinguish this stolen token when the attacker replays it from a new device. In essence, the lack of a device-bound factor on mobile creates an opening for token theft to succeed. This is exactly why passkeys on mobile are so valuable – they introduce a device-bound, phishing-resistant factor where previously the defense was weakest.
• Conditional Access Applied Only at Initial Sign-in: Another limitation is that CA policies are primarily evaluated during the authentication flow, not on every API call. Once a session token or refresh token is issued to a user, that token can often be reused until it expires. Attackers capitalizing on this will complete a compliant authentication on their proxy (tricking the user into satisfying MFA/CA), then extract the tokens. Subsequent use of those tokens might not trigger conditional access again until a new login is required. Microsoft has recognized this issue and introduced features like Continuous Access Evaluation and Token Protection to mitigate it. Token Protection (in preview) can enforce that a refresh token can only be used on the device it was issued to, by requiring proof-of-possession of a key tied to the device (Public Preview: Token Protection for Sign-In Sessions | Microsoft Community Hub). Token Protection is limited to Exchange Online and SharePoint Online, and can prevent administrators from connecting with PowerShell, so it needs to be carefully tested before rolling out. Microsoft Entra Security Service Edge (part of the new Entra Suite) offers broader protection: When users access internet or SaaS resources through Internet Access, Entra ID authenticates them and issues tokens. A Conditional Access policy with token protection can ensure these tokens are bound to the user’s device. The Global Secure Access Client or network policies route internet-bound traffic through Microsoft’s security infrastructure, where identity-based controls (including token validation) are applied. Token binding, when enabled via Conditional Access, ensures that access tokens or PRTs used for SaaS apps (e.g., Microsoft 365) are tied to the device, preventing token theft from compromising internet-facing services.
• Without such measures, a token stolen via an AiTM attack can be replayed from an attacker’s server without raising further MFA prompts. This is why purely relying on one-time MFA at sign-in is insufficient against modern phishing — you must assume session tokens can be compromised and design CA policies that account for token reuse (more on this in the next section).

In summary, misconfigured or incomplete Conditional Access rules (e.g. platform-specific policies without catch-all blocks, or inconsistent device requirements) can undermine the security of your MFA. Attackers can masquerade as different devices or locations to bypass policies. And if a token is issued to an unmanaged device, it can be replayed elsewhere unless additional controls are in place such as Entra ID Identity Protection, which has 28 risk detections.

Recognizing these gaps is the first step; the next is to close them with stronger authentication methods and smarter policies.

Strategies for Organizations hesitant about Phone-Based Passkeys

Some organizations are wary of relying on users’ personal phones for authentication, whether due to policy or compliance reasons. While the recommended path in 2025 is to enable passkeys (to gain phishing-resistant MFA across all device types), there are alternative mitigations if phone-based auth is a non-starter. Security teams should consider a combination of the following strategies to protect against token theft attacks:

• Enforce Token-Binding or Device Authentication on Tokens: Entra ID Conditional Access offers token protection for sign-in sessions to EXO and SPO, which essentially binds the session token to a particular device. When this is enabled, any attempt to reuse a token from a different device will fail proof-of-possession and be blocked (Public Preview: Token Protection for Sign-In Sessions | Microsoft Community Hub). In practice, this means even if an attacker phishes a session cookie or refresh token, they cannot use it on their own machine to access corporate resources. Organizations resistant to phone-based MFA should at least enforce device-bound tokens for EXO and SPO. This requires modern OS versions and might currently apply mainly to Windows 10/11 and specific clients, but it’s a powerful defense against replay attacks. Think of it as forcing a device check on every token use, not just at initial login. While not as user-friendly as a passkey, it significantly raises the bar for attackers – they can no longer simply steal a token and log in from anywhere.
• Tighten Conditional Access – Include Device Compliance in ALL Scenarios: If deploying passkeys or token binding isn’t feasible for some user populations, you can fall back to stricter Conditional Access policies – with careful configuration. Specifically, require device compliance or domain join for any device accessing sensitive apps, including mobile devices. This might involve mandating Intune enrollment for BYOD phones or using App Protection Policies that register the device in Entra ID. If a device cannot be brought into compliance, block it from accessing critical services except via alternate secure methods. Additionally, review your CA conditions to ensure there are no gaps: avoid relying on just “Device Platform == Mobile” conditions, as those can be spoofed. Instead, combine signals like compliant device, approved client app, or certificate authentication to verify the device’s identity. Always include a catch-all block policy for any device/platform that isn’t explicitly trusted. Microsoft’s guidance is to “not rely on the User Agent string to be present or accurate– so have a default deny for unknown or unsupported device types. The goal is to prevent an attacker from pretending to be a different device to bypass policy. This might inconvenience some users (e.g. personal devices now need MDM setup or can’t be used for certain applications), but it will harden your environment against the common bypass techniques used by PhaaS kits.
• Restrict Authentication to Corporate Network (Last Resort): Some organizations consider limiting cloud logins to only when on a corporate network (or connected via a full VPN) to stop remote phishing. For example, a Conditional Access policy could allow authentication only from trusted IP ranges (your office egress IPs) and block all other locations. This approach can indeed thwart many external phishing attempts – an Evilginx server in a foreign country won’t be on your allowlist. However, the trade-offs are significant. For one, it forces remote and mobile users to connect through a forced-tunnel VPN, impacting user experience and productivity. It also contradicts modern zero-trust principles by implicitly trusting the internal network. If an attacker gains a foothold on an on-premises system or the VPN, they could still launch attacks from “inside”. Relying on corporate IP addresses is risky because you should treat all networks as compromised (assume breach). Therefore, use this strategy sparingly. If you must restrict by network, pair it with other controls (like device compliance and user risk checks) and have a plan to monitor internal traffic for suspicious activity. Remember that internal-only access is a band-aid, not a long-term solution – it may stop basic phishing but won’t help if an insider’s device is infected or if credentials are stolen in other ways. It’s far better to fix the auth method (e.g. deploy passkeys or certificate-based auth) than to rely purely on network isolation. In my experience, organizations that rely on this method don’t realize they are just punting the ball to the VPN service, which often is vulnerable to MFA fatigue attack if it is not secured properly. I recommend integrating VPN with Entra ID so that you can close that gap too (or replace your VPN with Entra Private Access).
• Block Device Code Phishing. Imagine you do all this security and then someone comes along and gets your user to enter a device code. Read about how Storm-2372 used this technique to logon as the user:

https://www.microsoft.com/en-us/security/blog/2025/02/13/storm-2372-conducts-device-code-phishing-campaign/

Conclusion: Adopt Passkeys for a Phishing-Resistant Future

2025 can be the year we turn the point in the fight against credential phishing. With the general availability of passkeys in Microsoft Authenticator and broad industry support for FIDO2, organizations finally have the tools to eliminate phishing and MiTM token theft at the authentication layer. Phishing-resistant MFA is no longer a luxury reserved for admin accounts or those with special hardware – it’s a practical option for your entire user base on every device. By transitioning to passkeys, enterprises can stop attacks from Evilginx, Mamba 2FA, and similar kits cold, as these tactics simply cannot steal what the user never types or sees (a private key).

For security professionals, the path forward is clear: begin planning a passkey rollout now. Start with privileged users and high-risk applications, pilot the technology, and educate users on the new login experience. Leverage Conditional Access authentication strength policies to require passkey or FIDO2 for sensitive operations. Simultaneously, shore up your Conditional Access configurations to close the gaps: ensure no device or location is implicitly trusted without verification, and consider enabling token protection for an added safeguard, and block device code flows.

By the end of 2025, organizations that embrace passkeys will be far better positioned against sophisticated phishing than those clinging to OTP-based MFA. The cost and user experience barriers have been lowered dramatically, while the threat of session token theft has never been higher. It’s time to retire phishable factors and enforce modern, phishing-resistant authentication enterprise-wide. Adopting passkeys now will mitigate one of the most pernicious attack vectors plaguing organizations – and take you a big step closer to a passwordless, zero-trust security model. Your users (and their session tokens) will be safer for it.

Actionable Recommendations:

• Enable Passkeys in Authenticator: If you have Microsoft Entra ID, turn on the passkey (FIDO2) authentication method policy and inform users to add a “Passkey in Microsoft Authenticator” via My Sign-Ins. Pilot with a tech-savvy group, then expand. Ensure users’ devices meet requirements (Android 14+/iOS 17+ for passkey support). This will immediately neutralize most phishing proxy attacks for those users.
• Audit Conditional Access Policies: Identify any CA policies that rely on device platform or location alone. Add fallback rules to block unknown platforms (e.g. any device not marked compliant). Remove any broad exclusions that aren’t absolutely necessary. If you have separate policies for mobile vs desktop, verify that an attacker can’t simply claim to be the other type and avoid stronger checks.
• While you are auditing your CA Policies, make sure you have excluded break glass administrator accounts from each policy. Why? As a human, you sometimes make a mistake while configuring CA Policies. I’ve met many such humans who have locked out their entire organization for 1 to 2 weeks, as that is the length of time it takes the Microsoft Data Protection team to get you back into your tenant after you’ve deployed a “Block All” with no exception policy. These breakglass admin accounts should have a passkey enrolled on them, as that is the new best practice for break glass admin accounts.
• Consider Phishing-Resistant Alternatives if Not Using Phones: If policy forbids using personal phones as authenticators, invest in FIDO2 security keys for your users or smartcards for certificate-based auth. The cost is higher, but these are equally phishing-resistant and can be used alongside or instead of passkeys. Weigh this against the user experience of carrying a key. In either case, avoid SMS and phone-call MFA for any high-value accounts – telephony-based MFA is highly vulnerable to social engineering and should be replaced with hardware/cryptographic methods wherever possible.
• Enable Token Protection (Preview): For EXO and SPO. This ensures that even if an attacker somehow steals a token, it cannot be replayed on an unauthorized device. Monitor the Entra ID sign-in logs for token protection failures, which could indicate attempted token theft or misuse. Be prepared to exclude your administrators, as this control disrupts administrative access to EXO Powershell and probably other shells.
• Educate and Drill: Run simulated phishing exercises that specifically test for AiTM scenarios. For instance, a fake login page that actually proxies to Microsoft – so the user goes through real MFA but on a suspicious URL – can reveal who might fall victim to a real Evilginx attack. Use these teachable moments to show how passkeys or FIDO2 login prompts would differ (e.g. the browser or Authenticator will display your organization’s name or legitimate domain, which is a clue to users). Make sure your helpdesk is prepared to support users setting up passkeys and to answer questions about why the organization is moving away from SMS or OTP codes.

By following these steps, enterprise security teams can drastically reduce the risk of MitM token theft attacks. The technology to defeat modern phishing is here – implementing it thoughtfully is the task at hand. Transitioning to passkeys in 2025 will strengthen your defenses where it matters most: at the point of login, before attackers can turn a stolen token into a full-blown breach. The sooner you start, the sooner you can shut down one of the most vexing threats to cloud security today.

Additional References/Resources:

· Jan Bakker wrote a great article here: https://janbakker.tech/things-you-should-know-before-rolling-out-device-bound-passkeys-in-microsoft-authenticator-app/

· AADInternals.com

· CA Optics – Conditional Access Gap Analyzer

· ROADrecon is a tool for exploring information in Entra ID from both a Red Team and Blue Team perspective

· MSFTRecon is a reconnaissance tool designed for red teamers and security professionals to map Microsoft 365 and Azure tenant infrastructure. It performs enumeration without requiring authentication, helping identify potential security misconfigurations and attack vectors.