Identify Users Signing In with SMS-Based Authentication

SMS-based multi-factor authentication is widely deployed but is the weakest of the supported MFA methods. It is vulnerable to SIM-swap attacks, SS7 interception, smishing, and telecom-provider compromise. Microsoft, CISA, and NIST SP 800-63B all recommend migrating away from SMS/voice OTP toward phishing-resistant methods like FIDO2 security keys, Windows Hello for Business, certificate-based auth, or — at minimum — the Microsoft Authenticator app with number matching.

Before you can migrate users off SMS, you need to know who is actually using it. Run this recipe when you are:

• Planning a rollout of the Authentication Methods policy to disable SMS tenant-wide.
• Performing a quarterly MFA hygiene audit.
• Responding to a compliance requirement (PCI DSS 4.0, HIPAA, CMMC, cyber-insurance questionnaire) that asks for evidence of strong-factor adoption.
• Investigating a SIM-swap or account-takeover incident and need to scope which accounts are exposed.

The recipe combines two data sources for a complete picture: the userRegistrationDetails report (who has SMS registered) and the Entra sign-in logs (who has actually used SMS in the last 30 days).

When you finish, you will have:

• A CSV list of every user who has SMS/text-message configured as an authentication method.
• A second CSV of users who actually completed an SMS MFA challenge in the last 30 days, with the date of their most recent SMS sign-in and a count of SMS challenges.
• A clear view of how much SMS usage exists in your tenant (often far less than admins expect once Authenticator and Windows Hello are deployed).
• A targeted migration list you can hand to your helpdesk or campaign tool to move users onto Authenticator, FIDO2, or passkeys.
• Evidence you can attach to an audit or compliance report.

Gotchas and caveats

• Property name differences. The sign-in log resource uses userDisplayName, not displayName. The authenticationDetails property is only available on the beta Graph endpoint — it is not selectable from v1.0.
• No server-side filter for SMS. You cannot use $filter on authenticationDetails/authenticationMethod. You must fetch sign-ins for the window and filter client-side. For busy tenants this can mean tens of thousands of records.
• Performance. A 30-day scan of a mid-size tenant can easily exceed 100k sign-in events. Always page with $top=999, follow @odata.nextLink, and consider narrowing the window (7 or 14 days) if runs are timing out.
• Registered ≠ used. userRegistrationDetails tells you who can use SMS, not who did. Cross-reference with sign-in logs for actual usage.
• "Previously satisfied" noise. Many sign-ins show authenticationMethod: "Previously satisfied" because the MFA claim was cached. Those are not SMS events — only count entries where the method explicitly contains "SMS" or "Text".
• Log retention. Entra sign-in logs are retained 7 days on free tenants, 30 days on Entra ID P1/P2. If you need longer history, ship logs to Log Analytics or a SIEM.
• Do not disable SMS tenant-wide before migrating users. Pulling SMS before users have registered an alternate method will lock them out.