Reporting Authentication Method Usage Data via the Graph
New Summary Methods for Entra ID Authentication Methods
Three new Entra ID Graph resources are available in the authentication methods usage reports API to help track adoption of authentication methods, especially the progress towards usage of strong authentication methods for multifactor authentication. It’s easy enough to create a report detailing the authentication methods in use with PowerShell. These resources deliver summary information in a very accessible manner, providing that you have the necessary Entra P1 or P2 licenses needed to access report data via the Graph.
Microsoft doesn’t add to the Graph without good reason. In this case, it’s likely that these resources and methods will be used for reporting in the Entra admin center. Microsoft Graph PowerShell SDK cmdlets aren’t available for the APIs yet, so the examples below use the Invoke-MgGraphRequest cmdlet to run requests. Like all Entra ID sign-in data, information is available for the last 30 days. To run the requests, the Graph SDK session needs the AuditLog.Read.All permission and the signed-in user must hold one of the roles specified in the documentation like Reports Reader or Security Administrator.
User Events Summary
The userEventsSummary resource provides a list of events associated with user activities to register an authentication method or reset using SSPR. The method supports several different filters to allow events to be found based on user principal name, display name, success or failure, and authentication method. Here’s an example which looks for every matching event that’s available. Only one event is available in my tenant, where a user set up SMS as a secondary authentication method. This isn’t a strong authentication method and the user deserves to be nagged to use a stronger method, like the Microsoft authenticator app.
$Uri = 'https://graph.microsoft.com/beta/reports/authenticationMethods/userEventsSummary' [array]$Data = Invoke-MgGraphRequest -Uri $Uri -Method GET -OutputType PSObject | Select-Object -ExpandProperty Value $Data id : d93bdb0a-8cb7-4303-a8ef-48c488997c38 feature : registration userPrincipalName : John.Jameson@office365itpros.com userDisplayName : John Jameson isSuccess : True authMethod : sms failureReason : eventDateTime : 01/08/2025 12:35:30
User Registration Method Summary
The userRegistrationMethodSummary resource is a summary of the number of users registered for each authentication method. To access the summary, run the request as follows:
$Uri = "https://graph.microsoft.com/beta/reports/authenticationMethods/usersRegisteredByMethod(includedUserTypes='all',includedUserRoles='all')" [array]$data = Invoke-MgGraphRequest -Uri $Uri -Method Get -OutputType PSObject | Select-Object -ExpandProperty userRegistrationMethodCounts $Data authenticationMethod userCount -------------------- --------- password 0 email 11 mobilePhone 126 alternateMobilePhone 0 officePhone 0 microsoftAuthenticatorPush 115 softwareOneTimePasscode 15 hardwareOneTimePasscode 0 microsoftAuthenticatorPasswordless 2 windowsHelloForBusiness 1 fido2SecurityKey 0 temporaryAccessPass 0 securityQuestion 0 macOsSecureEnclaveKey 0 passKeyDeviceBound 1 passKeyDeviceBoundAuthenticator 1 passKeyDeviceBoundWindowsHello 0 externalAuthMethod 0
User MFA Sign-In Summary
The userMfaSignInSummary list method is the one that interested me the most. Essentially, the report gives a daily sign-in report for 30 days detailing the total sign-ins and the number for MFA and single-factor sign-ins. A record looks like this:
id : f7c6b675-e664-44dc-9523-947501b0fac6 createdDateTime : 15/07/2025 00:00:00 totalSignIns : 59 singleFactorSignIns : 17 multiFactorSignIns : 42
I used the report to interrogate the sign-in audit log for days when single-factor sign-ins occurred to discover which accounts and apps are involved. The command used to find single-factor sign-ins for a day looks like this (the beta cmdlet is used because the V1.0 cmdlet doesn’t currently return the authentication requirement):
[array]$SignInRecords = Get-MgBetaAuditLogSignIn -Filter "createdDateTime gt $StartDate and createdDateTime lt $EndDate and AuthenticationRequirement eq 'singleFactorAuthentication' and status/errorCode eq 0" -Sort "createdDateTime DESC"
Figure 1 shows the report output. The idea is that administrators can use this information to figure out why single-factor authentications still happen. Most of the accounts highlighted by the report are guest accounts that don’t use MFA because I disabled the conditional access policy to enforce MFA for guest accounts.

You can download the full script from the Office 365 for IT Pros GitHub repository.
Looking for Usage
Any API is only useful if it has a purpose. Hopefully, these notes spark some ideas for how to use the report data in campaigns to improve multifactor adoption within Microsoft 365 tenants. At least, that’s the general idea…
Insight like this doesn’t come easily. You’ve got to know the technology and understand how to look behind the scenes. Benefit from the knowledge and experience of the Office 365 for IT Pros team by subscribing to the best eBook covering Office 365 and the wider Microsoft 365 ecosystem.