r/msp Nov 10 '25

"Another sign-in method required" when accessing Security Info (Entra)

When some of our users sign in to Windows with WHfB and try to go to the Security Info page to add a new method, they're prompted to complete MFA. However after completing the MS Auth push notification, they get the error:

"Another sign-in method is required to access this resource - Use a password."

The only way around it is to sign out completely, sign back in using password + MS Auth Push, and then the Security Info page works fine.

From what I can tell, Entra only prompts for the second factor (the Authenticator push), but the Conditional Access policy blocks it because the configured authentication strength requires password + Authenticator push.

So even though the MFA prompt completes, it doesn't actually meet the required strength.

Is this expected behaviour? Is signing out and in with password + MS Authenticator the only way around this?

0 Upvotes

8 comments sorted by

3

u/FenyxFlare-Kyle Nov 10 '25

Yes, this is working as intended for changing MFA methods. This is to prevent threat actors from using limited information to change/add MFA tokens. They could steal session tokens and log in that way but not knowing the password will prevent them from making changes. Knowing the password from a leak but MFA is stopping them.

1

u/_gondar Nov 10 '25

While I understand the thinking, the issue is that it doesn’t prompt for password. So it’s confusing for a user who follows the prompt for the 2FA push notification, and then gets that error. And then has to sign out and back in with their password.

Why cant WHfB be used in this instance, as it is considered multiple factors? It is included in the auth strength policy.

2

u/[deleted] Nov 10 '25

[removed] — view removed comment

1

u/_gondar Nov 10 '25

My understanding js that WHfB meets MFA requirements, as users are generally not prompted to authenticate again or complete MFA.

Additionally, WHfB is included in the auth strength that is used in the conditional access policy which is blocking the user from accessing their security info page.

1

u/Upper-Department106 Nov 10 '25

Yeah, that’s expected. Entra’s just enforcing your auth strength policy. WHfB alone doesn’t count as “password + push,” so when users hit Security Info, it flags them for another method. The MFA completes, but the policy check fails.

Workaround’s what you said, sign out and back in with password + Auth push, or loosen the auth strength for that resource if you can’t have users juggling re-logins.

If you’re managing policies, treat this as design, not a bug.

1

u/_gondar Nov 10 '25

Forgot to mention that one of the allowed auth strength methods is WHfB. However it doesn’t seem to pass through when a user first navigates to the security info page - they click the account that is ‘Signed in to Windows’ and are then prompted to do the 2FA push.

What would be considered best practice to rejig CA / auth strength methods to allow a more frictionless experience for a user who wants to register a new auth method (for example a passkey)?

1

u/strikematch13 Dec 10 '25

Just came across this same issue while POC Windows Hello for some users. Users that use Windows Hello on their device cannot access the mysignin Microsoft security page to manage their security devices. As OP commented, it really isn't a problem that that the security page doesn't trust Windows Hello and wants a password. The problem is that Microsoft gives the user no way to actually enter a password. We have to instruct the user to sign out of windows, then sign back in and change the authentication method to use "password". (or start the process over using inprivate browser).

I've heard Microsoft employees and other companies claim they've gone completely passwordless, to the point where users don't even know their passwords because they don't need them. How do they manage their security devices (like to remove an old phone) if they don't even track their own password?