Passwordless/Phishing Resistant Considerations in Entra

Passwordless has been dreamt of as an end goal for security admins however there are many quirks to be aware of when planning a passwordless/phishing resistant deployment I have encountered.

1) Lack of FIDO support for B2B

Despite the fact the below account is enrolled for FIDO in the home tenancy I am prompted for MFA code when accessing an external tenant as a guest, even more frustrating is that I am required to register for MFA per external tenant which could lead to many logins inside of my authenticator app. This can provide a poor user experience via MFA fatigue despite the fact they may have only done MFA in their home tenant once.

Solution: Token Trust between tenants. On initial inspection this sounds like a horrid thing as it adds a potential lateral movement path between a compromised user and tenants they are allowed to access. But this actually unlocks Authentication Contexts between tenants meaning you can do phishing resistant Conditional Access which was previously not available. It also deals with the MFA fatigue problem and puts a further dent in AiTM attacks.

My Takeway: I would love to see more granular claim trust as FIDO has its own AMR (Authentication Methods Reference) claim in token to reduce chance of mis-configuration on conditional access.

I would also look at restricting what B2B identities you accept and who can invite them but that's a topic in itself. Once restricted consider also adding guest compliant device to the conditional access mix to reduce token theft for an extra safety net (though this may not be possible for all guests)

Lukas Beran did an interesting poll on this topic I thought I'd add to this point:

2) Risk Policy for Password Change

Remember that risk policy conditional access policy you setup to remediate high risk scenarios (like leaked password), well if said policy was to trigger for some other reason (maybe security team marks user as compromised in XDR as a response to incident which then sets their risk state to high) The user would be completely unable to reset their password because well they don't know their password (if you've set up passwordless correctly)

As a somewhat mitigation you do see which Conditional Access is directly applied if you hit confirm user compromised from XDR now:

Solution: Create a security group of your passwordless users and exclude them from any reset password policies OR you could also move the policy to block instead (or force reset for non-passwordless and block passwordless). Annoying I can't see a way of using Dynamic Groups to solve this one automatically natively but by leveraging some automation upon KQL we could add users to the group automatically or at least inform admins they need to add a user to the group (perhaps Azure Monitor + some Action Type)

Ru Campbell mentions this same point in his article on Entra ID protection mistakes:

Note: If you haven't moved Risk based access from the legacy menu to conditional access this may be one reason for doing so as the retirement date is October 1st 2026.

3) Spoofing User agent to one that does not support FIDO

This is another interesting one involving a scenario where the user does in fact have their password (maybe a lift and shift without resetting their password) but FIDO fails because the user agent is being spoofed to one that does not support FIDO. The user then attempts to sign-in using their normal credentials. User agent spoofing is absolutely trivial and an attacker can do this. This means an AiTM can still bypass FIDO by falling back to password. (Currently do not have a demo, wonder if Nicola S. can help me out with that one)

Solution: As much as we can say the user should check twice if the security key fails I am still very much in the conditional access camp for this one. The main conditional access to stop AiTM (other than FIDO) is going to be things like Entra Join/hybrid join/complaint device (because attackers proxy won't have PRT), Named Locations, blocking any device platform you don't support.

I give plenty of recommendations on protecting against AiTMs in:

Important Note: As far as I understand FIDO alone does NOT stop token theft as this is just part of the claim in the token, FIDO is NOT a one-size fits all solution for identity problems.

4) Still require "less secure auth" for Self Service Password Reset

This is the most quirkiest one on the list because there isn't a clear cut solution (at least to me). In one of my tenants once I enrolled my FIDO key I removed my SMS from security devices thinking I did not need it because I technically still had my Microsoft Authenticator and I had my FIDO key. Upon resigning in I was hit with the SSPR you need to register a second method - you will get this prompt everytime:

So I'm not allowed to use the same FIDO key as my 2nd method..makes perfect sense really because if I'm using the FIDO key theres a good chance I am going to forget my password or be locked out of my password safe also but I'm also not allowed to use ANY key as a second option. Also sort of makes sense because if I enrolled a second key I could just login normally and change password (the new security info page does NOT prompt for old password) also crosses-factor with mobile passkey (if that's the FIDO method of choice) and could potentially not be a true "second method".

Solution: I haven't come to a perfect recommendation on this one yet but my initial thoughts are to apply authentication context to registration portal and authentication context to the rest of privileged apps meaning an attacker is unable to enroll their own key to "step up" their AMR claim even if my email/SMS/Mobile authenticator is compromised. An attacker managing to bypass both methods and then passing conditional access is already quite extremely rare. It is possible to disable SSPR for admins via powershell and to disable SMS/voice call/Email OTP Authentication methods so they are ONLY used for SSPR and not for login (layered on top of Authentication context for a true defense in depth creme a la creme). You may want to consider removing SSPR for passwordless end-users by leveraging the same security group as discussed in point 2. If you choose to keep SSPR I would monitor anyone attempting to switch on SMS/Email authentication methods in case there is a gap in conditional access.

There is a slight quirk with disabling SSPR for admin and removing SMS/Email entirely in that when you hit the default 180 days for reconfirming authentication you enter a prompt loop if you have support type admins not excluded from SSPR....

5) What if Attacker just enrolls their own key to get past authentication contexts?

Solution: Touched on this one already but this requires explicit MFA again rather than trusting the token already used which considerably slows down an attacker, even if they get past this ensure you are only allowing specific AAGUIDs /requiring authentication context to enroll.

You can review AAGUIDs in the tenant by using https://github.com/f-bader/EntraIDPasskeyHelper by Fabian Bader or Steven Lim 's KQL Query

AuditLogs
| where ActivityDisplayName contains "Add Passkey"
| where Result == "success"
| extend AccountUPN = TargetResources[0].userPrincipalName
| extend AAGUID = AdditionalDetails[1].value
| extend WebAuthnInfo = AdditionalDetails[0].value
| project TimeGenerated, AccountUPN, ActivityDisplayName, AAGUID, WebAuthnInfo

        

Also a useful resource is the passkey AAGUID Explorer:

Conclusion

Removing passwords was never going to be easy but hopefully I've vented some of the nuances/questions I have come across when trying to plan a passwordless deployment (or created more questions). Hopefully someone smarter than me will figure out a solution to problem 4.

My final point is regardless of your state on passwordless today or your view on it you MUST MUST MUST enroll your breakglass into a FIDO method with a physical key. With the new changes Microsoft are rolling out with managed Conditional Access and MFA at ARM level us admins cannot take any risks / afford the downtime to bypass new changes no matter how well we monitor breakglass exclusions. Furthermore, mobile phones are simply NOT reliable enough for a breakglass scenario (hell they aren't even reliable for me today, I love waiting 10 minutes for my phone to charge before I can login)

John Savill covered the new MFA at ARM level change well in the following video: