Due to personal reasons I recently had to disable and re-enable 2FA on quite a few of services. Now during this action I noticed quite a few different practices when it comes to "what should a user do before being allowed to turn 2FA off".

So the question follows:
What is the most reasonable way to handle deactiviation of 2FA for personal / end-user accounts?

The options I've seen in the wild additionally to "being logged-in" include

  • No re-authentication
  • Re-authentication (without) using the password
  • Re-authentication (without) using one or two 2FA tokens
  • (No) E-Mail notification of the account owner
  • (No) Forced log-out of the user on all devices

Read all these points in each variation and combination, so "No-PW+1-Token+No-Email+Forced-Log-Out" is included just like "no-to-everything" as is "PW+No-Token+Email+No-Log-Out".

  • 1
    Are we talking about disabling 2FA completely, or removing a particular 2FA device? A user may have multiple devices attached to their account, and that distinction somewhat changes how to view the situation. Mar 26, 2017 at 16:28
  • @XiongChiamiov we are talking about "completely" here.
    – SEJPM
    Mar 26, 2017 at 16:28
  • Your best bet is to follow your "Password Reset" or use 2FA that can send to a one time code. I usually do Password reset + send code to sms ON FILE + send password to email ON FILE. If phone or emails were compromised then your just screwed, but it's easy enough to use. Trust has gotta start somewhere.
    – coteyr
    Mar 26, 2017 at 22:22
  • What is the user's workflow if they've lost the 2FA token? (are they allowed to have a long-term persistent session without logging in every time?)
    – pjc50
    Mar 27, 2017 at 11:26

3 Answers 3


TL;DR It's a Security vs. Usability thing. I prefer, and advocate for, the way GitHub does it; If the user is already logged in with a 2FA'd session, then require the password when entering the "sensitive" account area (changing email address or 2FA), and then allow disabling 2FA. Once disabled, send a notification email.

This is largely a fight between the UX expert and the security expert. On one hand, if the security guy/gal can get away with it, they'll require the password, email confirmation token, 2FA token, and maybe even an SMS token on top of that. But that will just deter users who will probably keep 2FA disabled forever after going through that horror of a UX.

If the user is already logged in using 2FA, it's reasonable to assume that this session in this browser is not initiated by an attacker. Thus, requiring 2FA while still in the same session is excessive. However, requiring the password is a good practice since the machine might be shared or left unattended by the user. This exactly how GitHub does it:

If the user is not logged in: Follow regular 2FA login flow and continue below.

If the user is already logged in with a 2FA'd session:

  1. User about to enter the danger zone to disable 2FA: enter image description here

  2. Require them to re-authenticate with the password: enter image description here

  3. Give them the option to disable 2FA with nothing else required: enter image description here

  4. Finally, and very importantly, send the user an email notification that 2FA is disabled.

Due to the nature of this change, unlike changing the password or enabling 2FA, I don't think it's necessary here to force-logout all the sessions.

  • Of course, if your browser saves your password, it'll just let you through here.... Mar 26, 2017 at 15:41
  • 5
    "If the user is already logged in using 2FA, it's reasonable to assume that this session in this browser is not initiated by an attacker" - exactly the situation I would be in if I were disabling a compromised 2FA account. Mar 26, 2017 at 17:09
  • 1
    I think it makes more sense to require the 2fa code than the password tbh. The password is more likely to be known by an attacker or saved in the browser. The 2fa code is much harder for an attacker to obtain.
    – Tim
    Mar 27, 2017 at 2:09
  • I agree with @Tim but for a different reason: deactivating 2FA means that one can access the account with just the password. So then make it such that the deactivation requires the token which won't be needed in the future.
    – dave
    Mar 27, 2017 at 11:15
  • Unless it's an e-mail service, it might be an option to send a verification code via e-mail.
    – comfreak
    Mar 30, 2017 at 20:50

The answer here depends on the risk appetite and threat profile of the organization. As @adi points out there's a trade off between usuability and security in this case.

For me, allowing the removal of 2FA without re-entering some kind of credential leaves applications at risk, where an attacker has access to an active session (e.g. via session hijacking, or in a shared PC environment), so is only really suitable for lower risk applications (and the question then might be, why do you have 2FA there in the first place...)

So the option is, what do you require in the way of re-authentication to execute the removal of 2FA.

If you allow just password+authenticated session (the github approach), then you're somewhat risking PC malware style attacks where an attacker is likely to have static password (via a keylogger) and an active session (via dumping information from the browser), but then once the attacker has privileged access to your client system, you're in a pretty bad place regardless.

Another option woud be to require a fallback token which was recorded when 2FA was set-up. This is doubtlessly bad for user experience (it's very easy to lose a token that you setup potentially years ago), and also potentially is weakened where the user's do things like store the tokens in the clear on the PC used to login.

A third option is to use another channel to confirm the action. This is likely to only make sense for higher value systems (e.g. online banking, internal company privileged access). Here the user is validated through another mechanism (e.g. SMS message, out of band confirmation via a phone call)


You can't ask them to authenticate with their second credential because that creates a catch-22 for users who have lost their second factor (e.g. misplaced a hard token).

Removal of 2FA should be similar to the forgotten password flow. In both cases, the user has forgotten or misplaced one of his factors; the workflow to change the factor, whether it be password or 2FA, should meet the same level of security, but can't require the original credential or factor.

Typically this sort of flow involves data entry of alternative factors (e.g. email address and date of birth, accompanied by CAPTCHA) followed by a OOB OTP. You could email the user a reset link or text them a short code, for example.

In any case, changes to any of their credentials should always trigger an email or SMS notification to that effect.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .