Microsoft has recently (around 15/10/2018) announced the availability (public preview) of [classic] OATH hardware tokens with its cloud-hosted Azure MFA Server.

This means the limitation of using only programmable hardware tokens is, in theory, gone and you can use cheaper classic TOTP tokens for systems relying on Azure Cloud MFA (such as Office 365 etc.). We have thoroughly tested the new feature and can confirm it is working, at least with our trial tenant account on Office 365 with E5 and Azure AD Premium P2 licenses.



There is, however, something you need to handle with care when it comes to provisioning. Let us have a look at the provisioning process first:
As per Microsoft "Azure AD supports the use of OATH-TOTP SHA-1 tokens of the 30-second or 60-second variety. Customers can procure these tokens from the vendor of their choice. Note that secret keys are limited to 128 characters, which may not be compatible with all tokens"
Token2 classic tokens are 30-seconds and the keys are 64 characters, so we are fine here.
Next, "[..] once tokens are acquired they must be uploaded in a comma-separated values (CSV) file format including the UPN, serial number, secret key, time interval, manufacturer, and model[..]". No problem here as well, Token2 will send you the CSV file for the tokens acquired upon request (we strongly recommend to send us your public GPG/PGP key so we send the file encrypted)
Furthermore, to complete the process "the administrator then can activate each key by clicking Activate for the token to be activated and entering the OTP displayed on the token". This one is something not very convenient and here is why:
a) When they say "the administrator", they really mean it. In order to activate a hardware token for a user, Global tenant admin rights are required. As per our knowledge MFA permission delegation has yet to be implemented
b) The administrator will need to have access to the token itself in order to activate it. This makes the provisioning process kind of cumbersome as tokens cannot be bulk provisioned or pre-provisioned. This needs to be done one by one, with the physical presence of the user (or the token). If the token is provisioned (activated) in advance and then sent to the end user, he or she will not be able to log in until the token reaches the user: the reason is that with hardware tokens enabled it is not clear whether alternative verification methods such as SMS and/or phone call can be used (more tests to conduct) if an alternative method, such as SMS, is not configured. In this scenario, the provision of tokens has logistical challenges around loss, replace, and theft scenarios. So if the token is lost or damaged, the MFA needs to be manually disabled by the tenant admin while the token is being replaced. We also noticed that CSV with token data cannot be imported, if one of the users in the list already has any kind of MFA enabled (app or SMS etc.)

This is the error you get when trying to import CSV file for users with MFA already enabled

There are some minor issues as well with the provisioning, such as checkboxes not shown as checked when trying to delete/edit, "Verify" button grayed out when trying to activate a token (althout the button itself works when clicked)

Taking into account the issues above, here is the outcome:
While using classic TOTP tokens can significantly decrease the budget needed to enable hardware token based MFA, this adds more work for tenant administrators. Therefore, only smaller organizations where global administrators take care of user provisioning and operating in one physical location can fully benefit from this new feature. Bigger organizations should still rely on programmable hardware tokens, where provisioning is done by users themselves.

The comparative summary is shown below

This page describes the enrollment procedure for classic tokens with Azure Cloud MFA