Forum Discussion

michaelhosdez's avatar
michaelhosdez
Copper Contributor
Jun 18, 2026

Authentication methods for SSPR

Hello,

 

We have a Microsoft Entra ID P1 environment with a lot of users (thousands).

Our users are created in Active Directory and synced to Entra with Azure AD Connect (latest version).

We want to set authentication methods (for password resets: SSPR) for every user automatically.

I wrote a C# app to get all info from our internal systems and set the authentication methods for every user via the Graph API.

 

NuGet package used: Microsoft Graph v6.2.0

 

Code example:

 

//Execution

var batchResponse = await graphClient.Batch.PostAsync(batchRequest);

 

//The batchRequest is a collection of multiple request

// Add email method

userResponse.RequestId = await batchRequest.AddBatchRequestStepAsync(

graphClient.Users[userId].Authentication.EmailMethods.ToPostRequestInformation(emailMethod)

);

 

// Add phone method

userResponse.RequestId = await batchRequest.AddBatchRequestStepAsync(

graphClient.Users[userId].Authentication.PhoneMethods.ToPostRequestInformation(phoneMethod)

);

 

//Objects:

var phoneMethod = new PhoneAuthenticationMethod

{

PhoneNumber = phoneNumber,

P h o n e T y p e = AuthenticationPhoneType.Mobile

};

 

var emailMethod = new EmailAuthenticationMethod

{

EmailAddress = emailAddress

};

 

Source:

https://learn.microsoft.com/en-us/graph/api/authentication-post-emailmethods?view=graph-rest-1.0&tabs=csharp

 

Problem:

When I get a “success” response, the email / phone is always added to the user, but not always activated / visible as an authentication method.

 

In other words, when I take a look under “Authentication Methods”, the phone and/or email address is not always displayed so it is not usable as an SSPR method.

The audit log shows that an email or phone was added successfully.

 

When I manually add the phone or email address (GUI), it’s correctly registered as an authentication method and visible.

In Microsoft Entra, phone and email authentication methods are enabled for everyone.

 

Phone audit log:

 

Activity Type: User registered security info

Status: success

Status reason: User registered phone method

Modified properties:

Id: "..."

P h o n e T y p e : "Mobile"

PhoneNumber: "....."

 

Email audit log:

 

Activity Type: User registered security info

Status: success

Status reason: User registered Email Authentication Method

Modified properties:

EmailAuthenticationMethod.Email: "......"

 

The only difference i can find is an Azure Credential Configuration Endpoint Service audit log entry where the following attributes are changed:

 

StrongAuthenticationUserDetails:

[{"PhoneNumber":"+xx .....","AlternativePhoneNumber":null,"Email":".....@.....com","VoiceOnlyPhoneNumber":null}]

Included Updated Properties:

"StrongAuthenticationUserDetails"

 

TargetId.UserType:

"Member"

 

For users where the Azure Credential Configuration Endpoint Service audit log entry is found, the authentication methods work, for others it doesn't.

 

I’m confused and I hope someone can explain this behavior.

 

1 Reply

  • Hi, that is an interesting one. The confusing part is that "Graph call succeeded" and "method is usable for SSPR" are not always the same observable state immediately afterward.

     

    I would test a small sample without batching first. Add one method, wait a few minutes, then read back the user's authentication methods with Graph and compare that to the Entra portal. Also watch for throttling or partial failures inside the batch response, because batch success at the wrapper level can hide per-request details.

     

    The `StrongAuthenticationUserDetails` difference is a good clue. It suggests a backend registration/configuration step is happening for some users but not others. I would collect correlation IDs, timestamps, affected user IDs, and before/after Graph reads, then open a Microsoft support case. For thousands of users, I would also throttle the process and add a verification/retry pass rather than assuming the first successful POST made the method SSPR-ready.