Our friends at Microsoft have embraced the cloud as a way to give us the benefits of Pay-per-Use for our licensing needs. This is good news for any person, responsible for billing in an organization that relies heavily on Microsoft products.

When thinking about Azure Multi-Factor Authentication (MFA), as a service for, for instance, Azure Admins, it makes sense to be billed per billing period, or even to pay per 10 authentications.

This seems well-documented on the Microsoft documentation website for the Azure Multi-Factor Authentication Service (the cloud-only variant). However, for Azure Multi-Factor Authentication (MFA) Server (the on-premises variant, leveraging the same cloud-based Azure Multi-Factor Authentication engine as the cloud-only variant), it’s not that obvious.

So let’s dive into it.

Billing details for Azure MFA

According to Microsoft’s documentation on Azure Multi-Factor Authentication Pricing, the following Questions & Answers (Q&A) provide all the information you need:

How does Multi-Factor Authentication billing work?

The ‘per user’ or ‘per authentication’ billing/usage model is chosen when creating a Multi-Factor Auth Provider in the Microsoft Azure classic portal. It is a consumption-based resource that is billed against the organization’s Azure subscription, just like virtual machines, websites, etc.

Does the ‘per user’ billing model charge based on the number of users enabled for Multi-Factor Authentication or the number of users who perform the verifications?
Billing is based on the number of users enabled for Multi-Factor Authentication.

We’ve done a bit of research and found, that when using the Per-User license model, user objects have the following characteristics:

• A (synchronized) user object can have any of the following values for the StrongAuthenticationRequirement attribute:
  • clear
    
  • When the attribute is clear, the user object is not configured or enrolled for Azure Multi-Factor Authentication.
  • enabled
    When enabled, a user object is configured for Azure Multi-Factor Authentication and enrolls the first time, a policy enforcement point (PEP) is passed that requires multi-factor authentication.
  • enforced
    When enforced, a user object is enabled and has passed a policy enforcement point (PEP) that requires or required multi-factor authentication, and the user object is enrolled (configured) for Azure Multi-Factor Authentication.

A Per-User license for Azure Multi-Factor Authentication is billed, when the user object’s StrongAuthenticationRequirement attribute reads either enabled or enforced.

However, user objects may already be assigned an Azure MFA license. No separate Azure MFA license is billed for the user object when any one of the following license is assigned, since these licenses contain the Azure MFA sublicense:

• Azure AD Premium (P1)
• Azure AD Premium P2
• Enterprise Mobility + Security (EM+S) E3
• Enterprise Mobility + Security (EM+S) E5
• Secure Productive Enterprise (SPE) E3 (previously Enterprise Cloud Suite, or ECS)
• Secure Productive Enterprise (SPE) E5

If no applicable license is assigned, Microsoft attaches the Azure MFA per-user license.

Tip!
You might want to check for user objects that are enabled vs. enforced to prevent license costs for user objects that never pass a multi-factor authentication-enabled policy enforcement point (PEP). The script I previously shared to get to know the colleagues using Azure Multi-Factor Authentication provides this information, albeit more focused on the method used.

Tip!
You might want to check for user objects that are enforced, but are also configured with the BlockCredential attribute. This is the attribute that is filled with $true when a synchronized Azure AD user object falls out of scope of Azure AD Connect’s synchronization rules, for instance because it is disabled in the on-premises Active Directory Domain Services environment.

Billing details for MFA Server

Now, of course, when an organization wants the full functionality of Azure MFA (except for App Passwords), they’ll implement the on-premises Azure Multi-Factor Authentication Server.

Licensing for Azure MFA Server is interesting, and most closely resembles the Per-User licensing module of the Azure MFA Cloud variant: An Azure MFA license is needed for every enabled user in the PhoneFactor.pfdata database, used to store the multi-factor authentication information on all (synchronized) user objects by the Azure MFA Server(s) on-premises.

Note:
The default setting when you manually add a user object to the PhoneFactor.pfdata database or synchronize a user object from Active Directory or an Oracle LDAP directory, is Enabled, if a phone number is provided.

Again, for user objects that have an Azure AD Premium P1, Azure AD Premium P2, EM+S E3, EM+S E5, SPE E3 and/or SPE E5 license assigned, no separate Azure MFA license is billed for the user object; all these licenses have Azure MFA included as a sublicense. If no applicable license is attached, Microsoft attaches the Azure MFA per-user license.

When multiple Azure MFA Servers are part of the same Azure MFA Server Group, the PhoneFactor.pfdata file is replicated amongst all Azure MFA Servers in the group and the user object is only billed once.

Microsoft states it sends information to the cloud-based Azure Multi-Factor Authentication engine to perform multi-factor authentication (by asking it to place a phone call, sending and receiving text messages and/or pushing a notification). However, as part of this information, the license state is also sent per user, along with information to uniquely identity the user object between the Azure MFA variants.

Tip!
You might want to pay close attention to Enabled users in the Azure Multi-Factor Authentication Server Management User Interface, that have no multi-factor authentication information, like a phone number. These user objects are billed, but cannot perform multi-factor authentications.

The Filter User List link on top of the Users list in the Azure Multi-Factor Authentication Server Management User Interface, can be followed to expand the filtering option. This provides the opportunity to select Enabled, so only enabled user objects are shown in the list, temporarily. Sorting on the Phone column, then, provides a quick overview.

Concluding

Billing for Azure MFA and Azure MFA Server is straightforward, but there’s a couple of gotchas to be aware of.