I’m excited to announce the public preview of hardware OATH tokens in Azure Multi-Factor Authentication (Azure MFA) in the cloud! We’ve had several phone-based methods available since launching Azure MFA, and we’ve seen incredible adoption. But many of our customers have users who don’t have a phone available when they need to authenticate. Today, MFA is available for those users too!

At the same time, we added support for multiple MFA devices. Your users can now have up to five devices in any combination of hardware or software based OATH tokens and the Microsoft Authenticator app. This gives them the ability to have backup devices ready when they need them and to use different types of credentials in different environments.

Multiple device support is available for all users with Azure Active Directory (Azure AD) MFA in the cloud. Hardware OATH tokens are available for users with an Azure AD Premium P1 or P2 license.

Check out our credential docs and read on to try out hardware OATH tokens in your tenant.

Support for OATH tokens for Azure MFA in the cloud

First, you will need some OATH tokens from the vendor of your choice. You can use any OATH TOTP token with a 30- or 60-second refresh that has a secret key of 128 characters or less. Some vendors include:

Because OATH is a standard, you’re not locked to a single vendor or form factor. Once you purchase the keys from your vendor, they need to send you a file with a secret key, serial number, time interval, manufacturer, and model for each token.

To assign the tokens to users, edit that file to add your user’s user principal names (usually their email address) and then upload it to Azure Portal > Azure Active Directory > MFA Server > OATH tokens. Make sure to use the format described in the docs—the secret is in base 32! Also keep the header row in the file. Then, activate each token and hand them out to your users.

Support for multiple devices in Azure MFA

In addition to hardware tokens, we also rolled out support for multiple authenticator devices. Your users can now have up to five devices across the Authenticator app, software OATH tokens, and hardware OATH tokens. This is great to give your users different devices for different environments and to let them have backup devices in case they lose one or forget one at home.

Multiple device support is available today for all users—there’s nothing you need to do to get started!

These are just the start of a lot of changes we’re making to MFA and authentication in Azure as we drive toward a password-less future, so stay tuned here to learn more about the amazing developments as they come.

You can also let us know what you think in the comments below. As always, we’d love to hear any feedback or suggestions you have.

To the comment about the YubiKey 5 not being supported by the Yubico Authenticator App, it should work fine. I double checked and I was able to set up a YubiKey 5 without any issues. If you are seeing an issue, let us know. The best way to contact Yubico is via https://support.yubico.com/support/tickets/new but you can reach out to me too.

Great news, been waiting for this feature for awhile now, but when i try enabling this and we click on MFA Server it shows we don`t have a Azure Premuim License? We currently have a A3 License, which includes Azure AD Premium P1 licenses.

@ Daniel Lowe, I was just in our tenant yesterday and noticed the same thing, which surprised me as we have EMS E5 licenses for all users. I noticed though that I could still click into the different options under MFA Server and configure them. I just checked a demo tenant I have, which includes EMS E3, and it does the same thing, so I think that Overview page for MFA Server is static and always shows the licensing message.

Hey folks! Thanks for all the great comments. I'll respond to them all here.

Q: "Why is this in the MFA Server blade in the Azure Portal?"

A: Great question--we're continuing to evolve our UX for MFA and credentials management. The next stage isn't ready yet, but when it is, OATH tokens will move to a better aligned, more aptly-named location.

Q: "FIDO2 and FIDO U2F?"

A: Yes, we love FIDO2! At Ignite, we announced private preview for FIDO2 support, and we're shooting for public preview early in 2019. We don't have plans, though, for FIDO U2F--we think going passwordless is much more important than having yet another second factor.

Q: "Once OATH is activated for a user, can they not sign-in using SMS or mobile app?"

A: Activating OATH doesn't change any credentials already registered for a user! It just sets OATH as their default MFA method. If the user wants to SMS, app, or any other cred, they can click "Sign-in another way" on the MFA screen. They can also change their default at MyApps > Profile > Edit Security Info.

Q: "Is there a way to disable support for multiple devices?"

A: No, it's on for all users.

Q: "What is the recommended procedure in case the token is damaged/lost/stolen?"

A: An admin can delete the token from the user in the admin interface. The user can also deactivate their token themselves from MyApps > Profile > Edit Security Info.

Q: "Why is the MFA Server blade saying we don`t have an Azure Premium License?"

A: It's a bug--sorry! We have a fix coded and are going to deploy shortly.

However, it is not setting OATH token as primary MFA method, after activating the token I still had the phone as my primary method (which is fine). Also, the login page asks for "mobile authenticator", although the OTP from the token was accepted with no issues.

On the figure below, what the page asks for is, in fact, a code from my token, not my app

On the aka.ms/mfasetup page the name of the profile is made of the token name and its serial number.

On the same page, users can change the default MFA method from phone to token, but again, the there is no "OATH token" in the list, it still says "app"

It is also important to mention that multiple MFA devices work transparently fine, in addition to the hardware token I managed to add a mobile app profile (Google Authenticator) and it worked just fine, accepting both the hardware token and app-generated OTP without any issues.

First of all I am very happy to read that you support OAUTH-Tokens! We have already obtained some and apart from a few flaws (mentioned above, like not describing the OAUTH-Method distinctively, but still showing as Code from Authenticator App) it works very well.

However, there is one thing that bothers our administrators and I hope that you will improve this once the Preview progresses into an official release:

When we receive the OAUTH-Hardwaretoken (e.g. SafeID - Deepnet) we register it on the Azure platform. This could be done for a bulk order of more than 1000 devices with a csv-file. BUT, when we actually want to activate the OAUTH-Token, this has to be done by the Azure administrator as well - manually. He has to enter the generated code from every single hardware token that has been registered before.

On the other hand, with smartphones users can purchase, register and activate the authenticator app on that particular device themselves without the need of an administrator.

My question: Do you think you can create a process, where IT can register OAUTH-hardware tokens (not FIDO, but SafeID - Deepnet) on Azure through CSV files, but let users activate the hardware tokens themselves? I would imagine that during the activation process the azure will check the serialnumber of the token to verify that the token has been registered through an Azure administrator and thus make it trustworthy.

This would be such a relief, since users could even obtain hardware tokens themselves in case of a loss or theft, contact our IT, pass through the serial number, get their hardware token registered and then activate the hardware token themselves.

Great to see this and test out. To piggyback on Hirmand's question is there a way to do a mass activate of the token either via csv upload or powershell (rather than having to key in the OTP manually for each user)? Thanks!

@Hirmand Ebadi asked about user self-activation. Yes, we're absolutely planning that! It's a key scenario we're planning to build, basically as you described it. @bob slav, no way to do mass activation today, but hopefully the distributed approach helps you when we release it.

@abu shayeed asked about Safenet Mobilepass. It looks like a software OATH solution; we haven't tested it. In their documentation they say it's OATH TOTP compatible, so chances are it's compatible, but I can't say for sure. I'd suggest contacting Gemalto to see if they have guidance. However, if you're interested in a software authenticator, I'd suggest using the Microsoft Authenticator app to do push notification auth, which is a more seamless experience for your users.

We have noticed that you can't use the verification code from the Authenticator app and a hardware token simultaneously. The hardware token replaces the "Use a verification code from the app" prompt during MFA.

Will you be fixing this so that the hardware token is accurately represented, and the app code and hardware code can be used concurrently?

Thanks, @Emin Huseynov. Are you saying that you can pick the "Use the verification code from the mobile app" option and use either the hardware token or authenticator code, from the single option? Or, are you seeing two options? In your original post, you note that there is no hardware token option displayed.

@Phillip Lyle , My default is text for the time being, in addition I see phone call , and "Verification code from app" which is accepting 3 different OTPs, one from the app, second from my programmable token and third is my OATH TOTP token.

This is my test tenant.

My production tenant also accepts more than one OTP in the "Verification code" field as I have enrolled 2 different apps ( in fact an app and a programmable token)

I was able to fix this by removing my authenticator app and re-adding. It then worked as expected (both codes supported from the same option).

My co-worker did not run into the same issue. My authenticator app was working properly before, but I tried multiple separate MFA attempts after adding the hardware token and the verification code was rejected each time. We'll keep testing.

I'm looking for a way to automate MFA authorization in code for automated testing that needs to login and verify that MFA is turned on and is working without human intervention. Do you have guidelines or information on setting this up? Currently I'm looking at open source libraries to make this happen and I'm curious about the feasibility. Our automation is written in Java so I was looking at the following as a possible solution to the problem: https://github.com/aerogear/aerogear-otp-java

This isn't a scenario we support or can really advise you on, though I can broadly say such automation should never be used for real accounts: you'd be putting the account's password and second-factor secret out of the hands of the rightful user, so there's a lot of risk involved. Even doing so with accounts not tied to a specific user or without much privilege puts your whole tenant at risk: bad guys generally know they don't need specific or privileged accounts to get in; rather, any account is a good foothold.

That said, Azure MFA does support the OATH TOTP standard, so any compliant software OATH code generator should work with the service.

Is there any update on availability of mass activation? We are looking to move from our current environment (using TOTP tokens via Google Authenticator) to using Microsoft Azure, and have 38K+ OATH tokens to load up. While I can very easily create the CSV to upload them, there is no way I can go through that many and activate them all individually. A mass activate would be extremely useful (and in our case, necessary).

Any word on when we can expect these options in the Government cloud? We have folks, because we're government, who can't have phones in secure areas. Hard to use MFA if we have no options other than phones!

It's my understanding that OAuth with TOTP has no means of verifying the actual URL of the page displaying the request for the MFA code, so attackers are now just making fraudulent fake MFA request webpages and phishing the TOTP codes, much like they've been doing for passwords for decades. Meaning that OAuth will only protect us from incompetent attackers and persistent recurring login breaches (since attackers would need to Phish the TOTP code each time they logged in...)

Is that vulnerability to Phishing accurate? Or is there Phishing protection in OAuth like U2F and FIDO2 have?

@Torsion-Limit , there is nothing that can fully protect all users, and overall these techniques are still a balance between security and user experience

Assuming the first factor is compromised:

- TOTP phishing is theoretically possible mainly in a "manual" mode. Meaning that the victim should be targeted and the attack itself can be performed in real-time.

- If we are talking about such targeted attacks, U2F is also not 100% secure - the attacker would only need physical access to the U2F key for a short time : the attacker will need to log in, enrol another key and put the original key back. Stealing a U2F key is harder that TOTP phishing, but this would give permanent access (whereas with TOTP they "need to Phish the TOTP code each time they logged in")

@blob63 , with TOTP SHA-1 is used only for generating a secret key and is not really a pure SHA-1, it is HMAC-SHA1.

Here is a quote from another discussion of this topic:

1) the TOTP algorithm SHA-hashes a constantly-changing “document”, composed of a per-user secret key and the current timestamp (pegged to 30-second time steps), and

2) the 6-digit nonce that’s generated is checked at the server side, which can do simple rate-limiting (e.g. get it wrong twice, and you have to wait till the next 30-second period…which requires a new nonce)

A bit off-topic, but when it comes to one-time password, even MD5 is secure enough.

We are looking at implementing a hardware token device for use with MFA and Conditional Access. I see no mention of Conditional Access in any of these posts. So are these devices only compatible with the traditional MFA solution within Azure, or are they also compatible with Conditional Access MFA. Thanks for any advice given.