Authentication Methods – What Happens If I Click That Button

There are various buttons in the Entra ID portal that can be used in the event of an incident with a user account, but each have different effects and can be used in different circumstances. This blog post outlines the impact of each button on the user.

To do these tests I performed a standard login. I logged in both on an on-premises, hybrid joined Windows client and a seperate in-private browser session on an unrelated machine. The first completed SSO and signed in the user with only an MFA prompt (push notification to Microsoft Authenticator app) and the second required the username, password and MFA prompt. Both browsers were logged into the Office Portal (https://portal.office.com) before any of the following actions, and upon completion of the action and recording the effect, they were logged out and logged in again before the next test.

Additionally for the in-private session, Keep Me Signed In was checked and “Yes” choosen (which persists the login token/cookie), even though its an in-private (incognito) session and closing the browser wipes all tokens/cookies.

As mentioned above, there are various buttons in various portals. We will start with the Authentication Methods for a user – Entra Portal > Users > select a user > Authentication Methods

Reset Password

This one is a bit obvious, but for completeness, this button in the Entra ID portal under both the User Overview page and the Authentication Methods page will change the users password to a suggested new password and require the user to change it again at first login. There is no option here for the administrator to say what the new password will be nor an option so that the user does not require their own password change. So actually, compared to the Microsoft 365 Admin Center where this is totally the opposite behaviour, this is not that obvious really!

Require re-register multifactor authentication

Pressing this button should require the user to complete MFA registration. Additionally it will deactivate hardware OATH tokens and delete the following authentication methods from this user: phone numbers, Microsoft Authenticator apps and software OATH tokens. This is ideal in situations where the user has lost all their MFA methods for authentication (i.e. a new phone and dont have the old one) becuase once MFA is configured for a user, the easiest way to add new methods is to sign and on the My Account page to add new methods. The add new methods page will require completion of an existing MFA method. So if the user does not have available any old method and options like SMS have been disabled (so a text to an existing number cannot be sent) then pressing “Require reregister MFA” will give the user an option to add new methods and have the old methods removed. This is also useful when an account has been taken over and the malicious actor has added their own methods as well (a common event in my experience).

Note that this button will not always cause the user to reregister their account. Testing showed that if the user has a passkey then this keeps working, but other methods having been removed means that this is the only way to login. If a user has a passkey then this will still work to sign the user in. To get the user past the passkey requirement and to force the user to visit the MFA registration portal you need to issue the user a TAP.

This button differs from just issuing a TAP (Temporary Access Pass) for the user because although that allows the user to register new methods, a TAP does not remove the old methods (though it warns you to do this). Therefore, you might need to do a TAP and force reregister (if the user has passkeys including Windows Hello) if you need the user to reregister. To add a TAP ensure that it is enabled via the new Authentication Methods page and click “Add authentication method”. After the user uses the TAP to login, direct them to https://aka.ms/mysecurityinfo to update any MFA method required.

Revoke multifactor authentication sessions

This has no effect on browser based sessions, but will require you to redo MFA in applications. In a single test of many I did for writing this blog post, the Edge browser also signed out on the first press of the button but I could only get this to repeat in frequently.

For tenants not yet migrated to the modern Authentication Methods policies there is the option to “Remember MFA on trusted device”. This button in the Entra ID portal to revoke MFA sessions will cancel this saving of MFA on trusted devices. Therefore, only on “trusted devices” where the user has previously checked to keep their MFA session for x days will this session not be kept and be re-prompted for. The user is not asked to reregister their MFA methods but only to provide MFA again at next login.

View authentication methods policy

This button shows the effective authentication policy for the selected user. This is based on the new Authentication Methods migration process and does not include legacy settings.

On the Entra ID portal, Users > select your user, you get to the Users Overview page. On this page there is a “Revoke Sessions” button. This is the button that often should be used along with your selected option above. Revoking a session makes the login token invalid, updates the earliest time a token can be valid from to the current date/time and then as this means the current token is invalid, the user is signed out. This could be next to instantaneous in apps like Exchange Online and Teams, or within the hour on any app that does not use Continious Access Evaluation (CAE). On the users Properties page you can see their “Sign in sessions valid from date” property. Click “Revoke session” and this will change to the current time. The user will need to sign in again within the hour but immediately in Teams, SharePoint and Outlook.

Photo by Life Of Pix: https://www.pexels.com/photo/brass-colored-metal-padlock-with-chain-4291/

Posted

23 September 2024

enterprise mobility + security, Entra, Entra ID, Microsoft 365, security

Brian Reid

Tags:

Entra

Comments

4 responses to “Authentication Methods – What Happens If I Click That Button”

S

18 June 2025

Hi Brian,

Thanks for the read.

> Revoke multifactor authentication sessions
I do not understand this completely. Is this triggered *client-side* on controlled devices, or is this revokations initiated *server-side*?

Consider the scenario where a TA phished a victim via an AiTM portal, thereby the TA authenticates as the victim on some Microsoft app (e.g. Sharepoint, or another non-Microsoft app that happens to authenticate via Entra ID) with the phished password and MFA TOTP from Microsoft Authenticator.

In this scenario, the TA did not compromise the authenticator keys itself (the TA only stole the password and has access to a valid victim session now).

Would “Revoke multifactor authentication sessions” do anything meaningful here to mitigate the threat in any way? I am struggling to understand in what scenario this helps.

Thanks,
S

Reply
1. Brian Reid
  
  24 June 2025
  
  Hi – so the only scenario for this button in a malicious account takeover would be if you suspect that the threat actor (TA) has added their own authenticator methods to the account. Given that this is a common occurrence as far as I have seen then I would press this button as part of an account recovery flow. But in this flow I would not ONLY press this button. I would use this button as described in the blog to force a user to set their own methods again at loss of other methods, but in an account recovery scenario I would do this to remove any TA added methods, reset all the other methods so the user has to reregister, reset password if the user is using a password (i.e. not if they are using a passkey) and revoke the session token.
  
  I would combine the account recovery scenario with the following conditional access rule – the user can only set authenticator methods from a trusted location or with existing MFA (remember though you have reset these) – i.e. they need to come into the office or provide MFA to reset MFA methods. You do not want the TA resetting the password and adding their own auth method again which they would be able to do if you had no restrictions of the MFA registration process. Ideally, I would use as part of this account recovery flow a Temporary Access Pass (TAP), as that is considered a secure MFA method – so you confirm the users identity out of band with Entra and pass them the TAP. As they have the TAP they can now register a new MFA method because the TAP is considered as existing MFA. The TA cannot register a new method as they are not (hopefully) in your office or have the TAP.
  
  Reply
  1. S
    
    2 July 2025
    
    Hi Brian,
    
    Thank you for this insightful answer!
    
    Ok, so additionally, besides ‘require re-register MFA’, also revoke the MFA sessions and password if applicable. Makes sense. I’m planning to create a similar flow.
    I’ll also include temporarily disabling the account by default, which comes at the expense of usability/availability but at least also – to the best of my knowledge – causes earlier issues TGTs and Refresh tokens to become invalidated.
    
    I’ll also include temporarily disabling the account by default. This impacts usability/availability, but to the best of my knowledge, it also causes existing TGTs and refresh tokens to be invalidated – which, I believe does not happen on password change [1] and probably also not on MFA reregistration.
    
    1. Do you know how Microsoft aims to achieve ‘Revoke MFA sessions’ technically? This still isn’t clear to me. Is this triggered *client-side* on controlled devices, or are revocations initiated *server-side*? What I’d expect is that this changes the behavior of the IdP: future authentications require MFA again. What confuses me is that Microsoft states: it ‘clears the user’s remembered MFA sessions and requires them to perform MFA the next time it’s required *by the policy on the device*’. Now, I would add it to my flow because it doesn’t hurt to add it, but ideally I would also know exactly what this accomplishes.
    However, this option inherently seems a bit vague to me- also because you reported: ‘In a single test of many I did for writing this blog post, the Edge browser also signed out on the first press of the button but I could only get this to repeat in frequently’.
    
    Nice, I agree with TAP being a good method here and combining it with CAS would be ideal.
    
    Thank you again!
    S
    
    [1] edermi.github[.]io/post/2020/abusing_accounts_that_changed_passwords/ (removed link because not sure if that’d be marked automatically as a spam comment).
    
    Reply
    1. Brian Reid
      
      8 July 2025
      
      Changing your password in Entra will revoke your previous sessions. TGT and Kerberos (as mentioned in the blog post you linked to) are all on-premises and not Entra related. OAuth Token (OIDC etc) are revoked when your password changes (specifically when the “password last changed” value is changed. You token is always only valid from that date, and you can see this in the Entra properties of a user (“Sign in sessions valid from date time” will never be older than “last password change date time”)
      
      Reply