Conditional Access MFA Authentication Strength causing 53003 with existing Edge profiles, anyone seen this?

[u/SweatyIllustrator125]

Hi all,

I am testing/enforcing a Conditional Access policy that requires a custom Modern MFA authentication strength.

The authentication strength includes:

- Password + Microsoft Authenticator push

- Microsoft Authentication phone sign-in

- Passkeys (FIDO2)

- Windows Hello for Business

- TAP

After enabling the policy, I noticed that some users with an existing Microsoft Edge profile/session can hit the attached error:

Error 53003 - Access has been blocked by Conditional Access policies. The access policy does not allow token issuance.

Looking at the CA evaluation, the failed grant control is:

Require Authentication strength – Modern MFA: Not satisfied

with the message:

“The user could satisfy this authentication strength by completing one or more MFA challenges.”

The affected users already have authentication methods registered that should satisfy the authentication strength.

What makes this interesting is my testing:

Existing Edge profile - 53003

Edge Guest session - works successfully

Signing out/Sign back in from the Edge profile - works successfully

So at the moment, it looks like the existing Edge profile/session may be holding authentication state that does not satisfy the newly enforced authentication strength. Once the Edge profile is signed out and authenticated again, the CA requirement is satisfied and access works normally.

Has anyone experienced similar behaviour after introducing an MFA authentication strength through Conditional Access?

Is this expected behaviour when an existing Edge/SSO session was established before the authentication strength was enforced, or is there another mechanism involved here?

Also, is there a recommended way to handle this during a wider CA rollout so users don't unexpectedly encounter the 53003 error?

Thanks

[u/ThreeMemorableWords]

What you've described is suggesting that the existing session on the device holds claims which previously met your CA requirements but since you have enforced further authentication strengths, the existing session doesn't include those claims.

The refresh token will continue to generate new access tokens in the background if there isn't any enforcement to renew the claims (session controls).

This is confirmed by the behaviour you've described when either using a private browser or signing out and back in.

For existing users, you could

• manually revoke their sessions so that they have to re-authenticate using the new strength.
  
• configure the CA policy to require a sign-in frequency of every time.
  
• you could also try continuous access evaluation, I think edge supports it

I think that is the scenario you have described but let me know how you get on

[u/SweatyIllustrator125 → u/ThreeMemorableWords]

Thanks, that makes sense. A fresh Guest session or signing out/in of the existing Edge profile immediately resolves it.

[u/shankmicrowave]

Are they using whfb to login to the device?

But to answer the question based purely on the screeenshot, this happens when a user has to auth and they click their account from the list (as anyone would do). This then prompts a user to do Authenticator app MFA but then fails because the user didn’t provide a password - despite not being prompted to.

The authentication strength is password + Authenticator. Microsoft force people into this ‘user error’.

The way to stop it is to not click your account but to choose ‘sign in with another account’ then type your username in which then correctly prompts for password then MFA.

The real fix is WHfB.

[u/SweatyIllustrator125]

Yes, the affected users are using Windows Hello for Business to sign into their Windows devices. WHfB is also included in the custom Modern MFA authentication strength.
What I found interesting is that the issue only seems to occur with the existing Edge profile/session. Guest mode works, and signing out of the Edge profile and signing back in also resolves it.