“We have MFA” is no longer an answer to identity risk

In most board meetings the identity question gets a short answer: MFA is rolled out, coverage is close to 100%, next topic. That answer was adequate against password spraying. It is not adequate against the attacks that now hit Microsoft 365 tenants every day, which capture the login and the session together. The question a board should ask is whether the company uses phishing-resistant MFA where it matters, and what happens to a stolen session token.

Microsoft described the technique in detail back in 2022: an adversary-in-the-middle (AiTM) campaign targeted more than 10,000 organizations from September 2021 onward and worked against accounts with MFA enabled. In March 2026 Microsoft wrote that the Tycoon2FA phishing kit alone reached over 500,000 organizations per month before the Digital Crimes Unit and Europol disrupted its infrastructure. This is industrialised, rented tooling, not an exotic capability.

Push and SMS MFA stop password guessing but not a phishing proxy

An AiTM kit puts a reverse proxy between the user and the real Microsoft sign-in page. The user sees the genuine page, types the password, approves the push or enters the code. The proxy forwards all of it to Microsoft in real time, and Microsoft issues a valid session cookie. The kit keeps a copy.

From that point the attacker does not need the password or the second factor. The stolen cookie is replayed from the attacker’s browser. Microsoft notes that access can survive a password reset unless sessions and tokens are explicitly revoked (Microsoft Security Blog). MFA did exactly what it was built to do. The weakness is that the user could be tricked into completing it on the wrong site.

This is why the often quoted MFA numbers need context. According to Microsoft’s 2025 Digital Defense Report, identity-based attacks rose 32% in the first half of 2025, and over 97% of identity attacks are mass password guessing. Phishing-resistant MFA prevents up to 99% of those. The large number describes the volume attack. AiTM is a different category: it passes the very MFA that stops the volume attack, and Microsoft traced it to business email compromise as early as 2022.

Mandatory MFA for the admin portals is a floor, not a control objective

Many executives assume Microsoft has solved this for administrators. It has raised the floor. According to Microsoft Learn, Phase 1 enforced MFA for sign-ins to the Azure portal, the Microsoft Entra admin center and the Intune admin center in the second half of 2024, and for the Microsoft 365 admin center from February 2025. Phase 2 started on October 1, 2025 and covers create, update and delete operations through Azure CLI, Azure PowerShell, the Azure mobile app, infrastructure-as-code tools, the REST API control plane and the Azure SDK. Tenants could postpone Phase 2 to July 1, 2026 at the latest.

The enforcement asks for MFA. It does not ask for a phishing-resistant method, and Microsoft states that tenants with stricter Conditional Access policies keep them. In other words, an admin who approves a push on a proxied login page is fully compliant with the mandate and fully compromised. Workload identities are out of scope, which makes user accounts misused as service accounts the next item to clean up.

Phishing-resistant MFA belongs on privileged accounts first

Phishing-resistant methods bind the authentication to the origin of the sign-in page. A proxy on a lookalike domain cannot complete the handshake, so there is nothing to relay. In Microsoft Entra ID the built-in phishing-resistant MFA strength contains exactly 3 method types: FIDO2 security keys and passkeys, Windows Hello for Business or platform credentials, and multifactor certificate-based authentication. Microsoft Authenticator phone sign-in is passwordless, but it is not in that list.

CISA calls phishing-resistant MFA the gold standard and recommends starting with administrators, help desk staff and users with broad data access (CISA). That order is right for a simple reason: an admin token opens the tenant, a user token opens a mailbox. For admins we recommend device-bound passkeys with attestation enforced. Entra ID supports synced passkeys as well, and Microsoft Learn advises treating them as phishing-resistant but with the security posture of unattested authenticators. Synced passkeys are a sensible step up for the broad workforce. They are the wrong choice for Global Administrators.

Break-glass accounts deserve explicit attention. Microsoft recommends passkeys (FIDO2) or certificate-based authentication for them, and both satisfy mandatory MFA. A break-glass account that still relies on a phone number is a gap in the plan, not a fallback.

Conditional access has to enforce the method as well as the factor

Rolling out passkeys does not help if the same user can still sign in with push. The control that matters is the Conditional Access grant Require authentication strength, set to phishing-resistant MFA. Without it, an attacker simply chooses the weaker method on the proxied page.

Sign-in alone does not cover the session. 3 controls address what happens after it, and each has limits:

• Compliant or hybrid joined device: An AiTM proxy signs in from infrastructure the attacker controls. A policy that requires a managed, compliant device stops that sign-in before a token exists. Microsoft listed this as a mitigation in its 2022 analysis.
• Token protection: This session control accepts only device-bound tokens. Microsoft Learn lists it as generally available for native apps on Windows, macOS and iOS/iPadOS against Exchange Online, SharePoint Online and Teams. Browser support is in preview and limited to Azure Resource Manager. Most browser sessions are therefore not covered yet.
• Continuous access evaluation: CAE lets Exchange Online, SharePoint Online, Teams and Microsoft Graph reject a valid token when an account is disabled, a password changes, sessions are revoked or Entra ID Protection detects high user risk. IP location changes apply instantly, other events can take up to 15 minutes. CAE does not support guest users.

None of these replaces phishing-resistant sign-in. Together they shorten the window in which a stolen token is worth something, and that window is what an incident response team fights about in the first hour.

What to do now

1. Board: Replace the question “Do we have MFA?” with 2 others. What share of privileged accounts can only sign in with a phishing-resistant method, and how long does it take us to revoke all sessions of a compromised account?
2. CISO: Enforce the phishing-resistant MFA authentication strength for all privileged Entra ID roles and break-glass accounts within 90 days. Register at least 2 device-bound keys per admin with attestation enforced.
3. CIO: Require compliant or hybrid joined devices for access to Microsoft 365 and the admin portals, and pilot token protection in report-only mode for Exchange Online, SharePoint Online and Teams on Windows clients.
4. IT Operations: Verify that CAE is not disabled, convert user accounts used as service accounts to workload identities, and add session and token revocation as a mandatory step in the compromise runbook.
5. CFO: Budget hardware security keys for admins and a phased passkey rollout for the workforce. Plan the effort for device management and user enrolment, not only for the keys.

At HACKED24 we start with read access: we export the Conditional Access policies, authentication method registrations and sign-in logs of a tenant and show which privileged sign-ins would still succeed through a phishing proxy today. The fixes go through change windows with a named senior partner accountable for each step. If you want that picture for your tenant, the Executive IT & AI Review is the usual entry point, and our Microsoft Platform Services carry the rollout. For the board side of a compromise, see our note on the first 24 hours of an incident.