Entra ID Multifactor Authentication Reaches 38% of All User Accounts

Slowly But Surely Entra ID Multifactor Authentication is Protecting User Accounts

On February 12, Microsoft Security tweeted a snippet of a conference session featuring Alex Weinert, VP of Entra ID Security, discussing the roll-out of Microsoft-managed conditional access policies. Microsoft is currently deploying these policies to “eligible” Microsoft 365 tenants, meaning tenants with Entra ID P1 or P2 licenses (required for conditional access) to help customers embrace the goodness of multifactor authentication.

In the snippet, Alex says that 38% of Entra ID monthly active users (MAU) use multifactor authentication (Figure 1). Entra ID serves more than Microsoft 365, so you can’t assume that this figure correlates with what’s happening in tenants.

In September 2022, Alex said that the percentage for multifactor authentication was 26.64%. I don’t know if this is an apples-to-apples comparison, but let’s assume that it is, and that the growth represents a reasonable increase in multifactor authentication usage over the last 18 months. It’s a step along the path towards achieving Microsoft’s goal of driving multifactor authentication to over 80%. I’m not sure that managed conditional access policies will be the magic bullet to convince customers to switch on multifactor authentication for all users, but it might be a factor.

Figuring Out MFA Usage in a Tenant

As discussed in this article, there’s no single endpoint to query to discover if an Entra ID user account is enabled for multifactor authentication. You can certainly discover if authentication methods exist for an account, but that’s not proof that the account authenticates using anything other than a password. The article explains how to download CSV sign-in data from the Entra admin center and search the data to find successful multifactor authentication operations. It’s an example of using data drawn from multiple places to gain extra insight into user actions.

Some readers noted that no method exists to download the sign-in data. The Graph X-Ray tool doesn’t reveal if the Entra admin center uses PowerShell cmdlets to fetch the data, so it’s something that administrators need to remember to do before running the report (a column must be removed from the CSV too before it’s possible to load its contents into a PowerShell array).

Scripts can fetch sign-in data without using the downloadable CSV file by running the Get-MgAuditLogSignIn cmdlet. Or rather, the Get-MgBetaAuditLogSignIn cmdlet, because it supports better filtering capabilities, specifically to find records with a sign-in event type indicating interactive access. Records for non-interactive access, such as Teams signing in on behalf of a user to renew an access token in the background, are not included in this analysis.

The data available through both approaches are limited by the 30-day storage period enforced by Entra ID. In practical terms, this means that only authentication operations performed in the last 30 days can be analyzed. If users are active and the sign-in frequency session control set by conditional access policies is 30 days or less, this shouldn’t be an issue.

Scripting the Analysis of Sign-in Records

The approach I took is as follows:

• Connect to the Graph SDK with the Directory.Read.All and AuditLog.Read.All scopes.
• Run the Get-MgBetaAuditLogSignIn cmdlet to find interactive sign-in records. The command used looks for records created in the last 15 days for interactive sign-ins by tenant member accounts. Sign-in records are usually available for searching within ten minutes. For date comparisons, you need a sortable date with a terminating “Z.” Here’s the code to create a sortable date and find the sign-in records:

$StartDate = (Get-Date).AddDays(-15)
$StartDateS = (Get-Date $StartDate -Format s) + "Z"
[array]$AuditRecords = Get-MgBetaAuditLogSignIn -Top 5000 `
  -Filter "(CreatedDateTime ge $StartDateS) and (signInEventTypes/any(t:t eq 'interactiveuser')) and (usertype eq 'Member')"

• Run the Get-MgUser cmdlet to find licensed user accounts.
• For each user, extract the set of sign-in records (if any exist) and parse the sign-in records to discover if the account uses single-factor or multifactor authentication.
• Report the details (Figure 2). The script also exports the report data to a CSV file.

“No sign-in records found” means that the search for sign-in records returned nothing for the user account. In other words, this user has not performed an interactive sign-in in the last 15 days (or whatever search period is used up to the maximum of 30 days). “Single factor” means that Entra ID reports that the user signed in with a password (the single factor).

Entra ID doesn’t update the lastSignInDateTime or the new lastSuccessfulSignInDateTime property for a user account immediately following a sign-in. Probably for performance reasons, it seems like Entra ID updates the sign-in properties at intervals. I’ve seen delays of several hours before Entra ID refreshed a sign-in date.

The Role of the Primary Refresh Token

When an “existing claim in the token” is reported, it means that authentication is satisfied by the primary refresh token (PRT) issued to a user account on a registered device. A PRT has a lifetime of 14 days and is renewed automatically if the user continues to use the device. It is used to prevent applications from continually prompting with MFA challenges.

In their documentation for the sign-in report available in the Entra admin center, Microsoft cautions that “The Authentication details tab can initially show incomplete or inaccurate data until log information is fully aggregated.” One of the known issues is that “A satisfied by claim in the token message is incorrectly displayed when sign-in events are initially logged.” In other words, recent MFA sign-in records can show that the PRT was used when something else happened. As background processes run to “fully aggregate” data, the information becomes more accurate. For example, Figure 3 shows details of a sign-in record where the MFA requirement is satisfied by a password and SMS challenge.

The same adjustments to sign-in data appear in the records retrieved using the Graph. The report is still accurate in terms of detecting which accounts use MFA, but more accurate results are possible if the script analyzes a sign-in date that’s a couple of days old. For instance, this code finds sign-in records for a 15-day period ending 3 days ago:

$StartDate = (Get-Date).AddDays(-18)
$StartDateS = (Get-Date $StartDate -Format s) + "Z"
$EndDate = (Get-Date).AddDays(-3)
$EndDateS = (Get-Date $EndDate -Format s) + "Z"

[array]$AuditRecords = Get-MgBetaAuditLogSignIn -Top 5000 `
  -Filter "(CreatedDateTime ge $StartDateS) and (CreatedDateTime le $EndDateS) and (signInEventTypes/any(t:t eq 'interactiveuser')) and (usertype eq 'Member')"

Comparing the Tenant Against the Norm

To round things off, the script assesses if the tenant is better or worse than the percentage for MFA usage Microsoft cites for Entra ID as a whole:

Looking for sign-in records...
Finding user accounts to check...
Checking 847 sign-in audit records for 34 user accounts...
11 users of 34 found to use MFA
Oh dear! Tenant MFA usage percentage 32.35% is worse than Entra ID norm (38%)

Some user accounts will not use multifactor authentication, including breakglass accounts, which should be excluded from conditional access policies. Most of the accounts hosted in my tenant are used for testing, and some still use single-factor authentication. It’s time to do better and increase the tenant’s usage of MFA.

You can download the script from GitHub. As always, the code is to illustrate a principal. Have fun measuring your tenant’s MFA usage against the overall percentage reported for Entra ID.