I am the admin of a Google Apps domain. I created a brand new user account. I tried to sign in as that user (in a new browser) and it told me that "Your organization's policy requires you to enroll in 2-step verification. Please contact your administrator for more information." And then prompts me for a code.

How on earth would this brand new user have a code if they have never logged in before?Furthermore, when I look at this users account info from the domain admin panel, it says that 2FA is turned OFF.

Clearly when I try to login as this user it is not off since it's prompting for a code. There seems to be no way to access brand new accounts since it's requireing 2FA codes, but you can't get 2FA codes until you can login to the users account and turn it on & set it up!

6 Answers 6


Temporarily turning off 2-factor is not an ideal situation. Depending on the number of users, you could be chasing the user to get it setup so you can turn it back on. After while, you will just leave it off.

We recommend you create a suborganization called something like "Pre-2-factor" and move the new user into the suborg. That suborg has the 2-factor requirement turned off BUT also turn off everything else except for Mail and Vault (if you have vault).

Once the user notifies you they have completed the enrollment, you can move them into the regular organization or suborganization.

This puts the responsibility on the user with incentive to get it done because they cannot access anything but mail until they get enrolled and notify an admin.

Very easy to do from an admin perspective.

  • 20
    this is incredibly not trivial, I would have expected them to handle first time users differently
    – Michael
    Commented Jan 10, 2016 at 9:42
  • 5
    WTF! I this for real? Is there is no "normal" solution for this where we don't move users in a and out of special org? Shouldn't a user be able to setup MFA during account activation?
    – WooYek
    Commented Apr 5, 2017 at 8:35
  • 1
    The answer about "generate new codes" from @idean below seems like a better fit here; Sathya would you consider accepting that one instead?
    – Glyph
    Commented Jul 17, 2017 at 17:27
  • Simon Woodside has a real solution below. Apparently Google fixed the issue by adding a "New User enrollment period" option. Commented Jul 19, 2018 at 19:56

Google has fixed this now. You can now go to Security > Basic Settings > Go to advanced settings to enforce 2-step verification.

Then click New User enrollment period and set to 1 day. This will allow a new user one day to set their 2FA before they are locked out.

enter image description here

  • Thanks - great answer Commented Feb 4, 2019 at 22:30
  • I've found an amusing 'bug' with this - I've had a google account using my business email address for around 2 years. Today I was 'moved' into the Google Business suite and it thinks I've been with that for the same 2 years. It doesn't realise I've only been registered for 1 day and so I can't setup the 2FA. Commented Feb 27, 2019 at 14:35
  • 1
    This should be the new accepted answer.
    – MegaMatt
    Commented Apr 22, 2019 at 14:40

Immediately after creating a new user, go to that user's Security tab and click on "Generate New Codes" to generate a list of One-Time-Use codes.

Then give the user the first one or two codes from that list along with the URL https://accounts.google.com/b/0/SmsAuthSettings for SMS authentication (verify this, it might be different for you) so they can login once and setup their 2FA.

It's good practice to also have them generate a new list of backup authentication codes, since they've now used one or two.

  • 1
    This is better than the accepted answer...
    – fig
    Commented Jul 18, 2017 at 15:20
  • 1
    This has drawbacks: (a) the admin knows some of the user's one-time-use codes, which might not be appropriate depending on your security model, (b) requires you to securely transmit the codes to the user (i.e. with trust and encryption), which may be difficult to automate in a secure manner. Commented Sep 18, 2017 at 19:11

It sounds like you have 2 factor authentication Enforcement turned on for the domain:enter image description here

I'm thinking you could turn that off so all users are not forced to have 2 factor authentication.

The best answer I could find if you want to leave that setting enabled would be to setup an exception group:

Have all users and administrators enroll in 2-step verification or place them in an exception group using exception groups before enforcing the setting. This should be done for new users during account creation. Otherwise, they will be locked out of Google Apps.

More details on exception group can be found here: http://support.google.com/a/bin/answer.py?hl=en&answer=2548882

  • Yepp. That's what I ended up doing: temporarily turning off 2-factor authentication. It's not ideal, but it seems to be the only way.
    – znq
    Commented May 24, 2013 at 23:26
  • The Exception groups can be such a great feature, but it's managed so badly, it can't really be used.
    – Saariko
    Commented Sep 28, 2014 at 11:55

Dito GAM can now generate backup codes for users even if they don't have 2SV turned on yet. You can:

  1. Create the new user.
  2. Generate backup codes with the command "gam user [email protected] update backupcodes"
  3. Communicate one backup code to the user along with the initial password.
  4. Instruct the user to log in at: https://accounts.google.com/b/0/SmsAuthSettings and enroll in 2SV or risk being locked out after initial login.



An alternative causing less load on service desks, instead of sending the backup codes is to set and use the recovery phone.


  1. New user enrollment period - Never
  2. Apply the policy to all users

To create a new user

  1. Set the recovery phone
  2. Generate the "backup verification codes" (you don't have to share those with anyone, but it's important you create those)
  3. Share the account and password, and ask the user to login normally

At the first login, the user is then prompted to roll out MFA.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.