• The provisioning is done by the IT person equipped with software and hardware that allows burning seeds onto programmable hardware tokens (i.e. an Android device with NFC, iPhone 8 or newer for “-i” models etc.). Exact requirements are listed on the product page of each model. No special admin access is needed as the provisioning needs to be done on behalf of the end-users
• The user is remote and can only use a Windows machine to log in to Office 365 services (if a user has a smartphone or a tablet, a mobile authenticator can be used with MFA, hence no need for a hardware token)
• The user does not have a possibility to burn a hardware token themselves
• There is a way to contact the user and organize screen sharing (using MS Teams, MS SfB, TeamViewer, AnyDesk or a similar tool)
• A hardware token provisioned by IT/Helpdesk using the method described below can be shipped and delivered to the end-user within a short time (i.e. within a month )
• With Azure AD Free, there is no way for Global Admins to import existing seeds to Azure MFA (P1/P2 license is needed for this). Without AD Premium, the seed is automatically generated by the server and is shown as a QR code only to the end-user. Therefore, there is no way to configure this method in advance.
• If MFA for the user is activated and a hardware token is provisioned remotely, the user may be unable to log in to Office 365 while the hardware token is being shipped to her/him
1. Contact the user using a tool allowing screen sharing and ask to share the desktop. You can request control and perform the next operations yourself, or guide the user through the next steps
2. Ask the user to login to Office 365 (by going to https://www.office.com ), then go to MFA settings page (short URL: https://aka.ms/mfasetup )
3. Perform the burning process as described in the provisioning manual.
[the screen sharing must remain active so you can scan the QR code from the user’s desktop]
4. During the process, make sure you copy and save the text version of the secret key together with the username.
After the token is delivered, it is also recommended to remove the secret from the spreadsheet.
5. After the token has been provisioned, verified and added to the user’s MFA settings, as the user to log out and log in again. When logging in, make sure “Don’t ask again for 60 days” and “Stay signed in” option is activated. This will make sure the hardware token is not needed to log in for some time (while the token is being delivered)
6. Arrange to ship the token. Instruct the user to call Helpdesk in case the second factor is needed before the token has been delivered.
Actions described in step 5 of provisioning instructions above should make sure the user stays logged in for an extended period (ideally for 60 days), which should allow enough time for the token to be delivered. However, there may be situations when the user is prompted to re-login (i.e. a different browser is used, or session cookie has been cleared, or browser storage was corrupted etc.). Follow the recommendations below in case the user needs to enter the OTP while the token is still being delivered.
As described in step 6 above, users must be instructed to call the helpdesk, or any other IT support person/team designated to handle these requests. Important: user identity verification protocol should be in place to prevent social engineering attacks. The team or person handling these requests should have access to the spreadsheet described in Step 4 above. The secret value stored next to user’s name has to be used to generate the current OTP using one of the methods described in the next section and communicated to the end-user over the phone (or instant messaging). Email is also possible, but please note that the OTP is valid only for a limited period (currently around 10 minutes).
You can use the following tools to generate current OTP from a secret: