Skip to main content

Passkey Downgrade Detection

Sysadmin
Sysadmin
Fluency Sysadmin

A detection release for Microsoft Entra ID, published November 10, 2026. One new high-severity rule, EntraID_MFA_Downgrade, alerts when a user who signs in with a passkey, a security key or a certificate completes a sign-in with a password and a weaker MFA method instead, from a network they have never used the stronger method from. That is the step an adversary-in-the-middle phishing page needs, and the one that let the attacker in during the Workday payroll session hijack described in the advisory. The rule also alerts on a password and weaker MFA from a browser that claims to be Safari on Windows.

No action is needed: the rule syncs to every instance automatically.

Rollout and requirements​

  • Rollout. The rule is published to the default rule set and reaches each instance through resource sync within about two hours. No configuration is needed. It applies to sign-ins from release on, not retroactively; to look back, use the checks in the advisory.
  • Learning period. The passkey comparison raises nothing for its first seven days on an instance, while it learns which networks each user's passkey sign-ins come from. The Safari-on-Windows case needs no history and alerts from release.
  • Data sources. The rule reads the authentication steps in the Entra ID sign-in logs, collected by Entra ID Audit via Event Hubs or Microsoft Graph. The Microsoft 365 audit log does not carry those steps, so an instance that collects only that log does not get this detection.
  • Entra ID P2. Not needed. The rule reads which methods the sign-in used, not Microsoft's risk rating.

The attack​

A passkey or a FIDO2 security key cannot be relayed by a phishing page: the browser binds it to the real sign-in site. So an adversary-in-the-middle kit makes the sign-in page offer a weaker method, such as an authenticator code, a push or a text message, relays that one, and keeps the session. Some kits get there by sending a browser identity that Entra ID offers no passkey to.

In the incident Fluency investigated, the employee normally signed in with a passkey. The phishing page led them to "use another method", relayed the password and a one-time code, and the attacker's sign-in from a hosting provider was allowed. Entra ID rated it high risk, but a completed MFA counts as remediating the risk. The attacker went straight to Workday through single sign-on. The full account is in the advisory.

The user's own history shows the switch: a passkey sign-in from the user's network, then, minutes later, a password and a code from somewhere the passkey has never been used.

New detection​

IDRuleChangeSeverityFires when
102210EntraID_MFA_DowngradeNewHighAn interactive sign-in in a web browser passes with a password and a weaker MFA method, and either of the two cases below applies.

Passkey comparison. All of these are true:

  • the sign-in used a password and a weaker MFA method, and no phishing-resistant method;
  • the same user had a phishing-resistant sign-in in the two hours before it;
  • it came from a network (ASN) the user has had no phishing-resistant sign-in from in the last 30 days;
  • it was not on a compliant device: the sign-in carries no device ID, or the device is not compliant;
  • the network is not Microsoft's own.

Safari on Windows. The sign-in used a password and a weaker MFA method from a browser whose user agent claims to be Safari on Windows. Apple no longer ships Safari for Windows, and phishing kits that force the weaker method send that user agent. This case needs no history of the user. Electron apps, Postman and 8x8 Work, which send a similar user agent, are not matched.

The methods the rule counts:

KindMethods
Phishing-resistantPasskey, FIDO2 security key, certificate
WeakerAuthenticator one-time code, authenticator push notification, text message, phone call, email code

A sign-in counts as passed when it succeeded, or reached the stay-signed-in prompt (50140), which Entra ID shows after authentication.

What the rule does not cover​

EntraID_MFA_Downgrade does not fire for:

  • users who never sign in with a passkey, a security key or a certificate, except in the Safari-on-Windows case;
  • Windows Hello for Business, which is not counted as phishing-resistant here. Many users have it and also use their phone's authenticator, so counting it would make every phone sign-in a downgrade;
  • a weaker sign-in more than two hours after the user's last phishing-resistant one;
  • a network the user has used a passkey, security key or certificate from in the last 30 days;
  • a compliant device;
  • sign-ins that were refused, and non-interactive sign-ins;
  • stolen tokens replayed outside a browser. EntraID_AiTM_Session_Replay follows a captured session;
  • a second sign-in on the same session by the same user on the same day.

It is keyed on the user and alerts at most once per user and session a day. Each alert names the session ID, the IP address, network (ASN), country and city, the application and resource, the result, the user agent and browser, the device ID and whether it is compliant, the sign-in ID, the authentication methods used, which case matched, the networks the user's phishing-resistant sign-ins come from, and the minutes since the last one.

Triage guidance​

Treat an alert as a stolen session, even though the sign-in passed MFA.

  1. Contain first. Revoke the user's sessions (Entra admin center → Users → the user → Revoke sessions) and reset the password.
  2. Confirm with the user. Ask whether they chose another sign-in method at that time, on that network and device. A user who picked the authenticator on a new personal device, away from their usual networks, matches too.
  3. Remove what the attacker added. Check the MFA methods registered since the sign-in and remove any the user did not add. Check for new inbox rules and for mail sent from the session.
  4. End the sessions in every SSO application. Revoking Microsoft sessions does not sign the user out of Workday, Salesforce or other SSO apps, which keep their own sessions. End them inside each application and read its audit log for activity after the sign-in. Fluency collects the Workday user activity log.
  5. Close the gap. In Entra ID Conditional Access, apply the Phishing-resistant MFA authentication strength to HR, payroll and banking-detail apps, and restrict one-time codes, text messages and phone calls for users who have a passkey. The advisory lists the full set of steps.

To find these alerts, search behavior events by rule name. The rule is also listed by name on the Behavior Rules page (v1: Behavior Rules).

References​