Graph API - how to differentiate Entra "sign-in" features/methods from "SSPR" features/methods ESPECIALLY with phones?

Question

Hi,

I'm trying to get some differentiation to see if users are registered for SMS for MFA and/or for SSPR right down to the individual phone level, but there doesn't appear to be a simple way to do this. I've broadly been looking at these resources:

• /graph/api/resources/credentialusagesummary
• graph/api/userregistrationdetails-get
• graph/api/authenticationmethodsroot-usersregisteredbymethod
• graph/api/authenticationmethodsroot-usersregisteredbymethod
• graph/api/authenticationmethodsroot-usersregisteredbyfeature
• graph/api/resources/userregistrationfeaturesummary
• graph/api/resources/userregistrationmethodsummary
• graph/api/resources/userregistrationmethodsummary
• graph/api/resources/phoneauthenticationmethod

There are many reasons why someone might want to do this particularly through a staged rollout or migration, with campaigns to encourage user registration.

1. Say a company needs to enable call to primary mobile phone for SSPR "by exception" to satisfy a range of inclusion/accessibility use cases, but discourage/block it for everyday logon because it's a very noisy, or public facing, workspace (or a workspace where people would have no mobile network signal.) Phone auth might be OK for SSPR, but completely impractical as a logon credential.
2. Correct me if I'm wrong but in principle SSPR has to be an "out of band" recovery option, not one that's embedded into a successful logon workflow? After all, just because you happen to know someone's Windows Hello PIN, doesn't mean it's good enough to assert in order to change their AD password.
3. A company could be in a migration scenario with "old" Azure policies using a setup that we can't turn off during the migration, but we need to know if marking it as "migration complete" is going to either bin or mess up credentials that users have legitimately registered under the old config.

Thanks in advance!

Answer 1

Hello @Staddon, Tim , it is not posible to differentiate which methods authentication are enabled for MFA, SSPR or primary authentication. This is by design. The exception is SMS: you can see if its enabled for signing in trough thre smsSignInState property of the phoneAuthenticationMethod that belongs to him. .

MFA and SSPR management and methods have been combined. A method is not registered exclusively for MFA or for SSPR. If a user has registered SMS and policy allows both MFA and SSPR for the given user then he will be able to use SMS for both. If latter the SMS is disabled by policy, he won't be able to use the method but its registration will remain. For more information about what methods support MFA or SSPR take a look to How each authentication method works.

Let us know if you need additional assistance. If the answer was helpful, please accept it and rate it so that others facing a similar issue can easily find a solution.

Answer 2

@Staddon, Tim ,

To add to Alfredo's answer, another way to get part of the information you are looking for is to use the Authentication Methods Activity dashboard and Activity reports API to view SSPR reset activities and check based on the audit data: https://learn.microsoft.com/en-us/graph/api/resources/azure-ad-auditlog-overview?view=graph-rest-1.0

https://learn.microsoft.com/en-us/azure/active-directory/authentication/howto-authentication-methods-activity

You can use the List phoneMethods API to retrieve a list of phone authentication method objects for a user, and you can use the List registered user objects API to return a list of registered user objects.

See related discussion: https://techcommunity.microsoft.com/t5/microsoft-entra-azure-ad/get-all-users-subscribed-to-the-self-service-password-reset/m-p/102363