Microsoft Support Ticket

Subject: Microsoft Entra External ID Native Authentication API allows reuse of the current password despite password_recently_used documentation

Issue summary

We are using Microsoft Entra External ID Native Authentication APIs for customer accounts and have implemented the password reset/change flow using the following SSPR APIs:

1. /resetpassword/v1.0/start

/resetpassword/v1.0/challenge

/resetpassword/v1.0/continue

/resetpassword/v1.0/submit

/resetpassword/v1.0/poll_completion

According to the Microsoft Entra Native Authentication API documentation, the /resetpassword/v1.0/submit endpoint can return the following error:

error: invalid_grant
suberror: password_recently_used

The documentation describes this error as:

"The new password must not be the same as one recently used."

However, in our Microsoft Entra External ID tenant, we are unable to reproduce this behavior. The API allows the customer to set their new password to the same password they are currently using.

Test results

Test Case 1 – New password is the same as the current password

Current password: A
New password:     A

Result:

HTTP 200
poll_completion status = succeeded

The password reset operation completes successfully.

We expected the API to reject the request with:

error: invalid_grant
suberror: password_recently_used

but this error was not returned.

---

Test Case 2 – New password is different

Current password: A
New password:     B

Result:

HTTP 200
poll_completion status = succeeded

The password reset operation completes successfully as expected.

---

Test Case 3 – Reuse the newly changed password

After successfully changing the password from A to B:

Current password: B
New password:     B

Result:

HTTP 200
poll_completion status = succeeded

Again, the password reset operation completes successfully.

No:

suberror=password_recently_used

is returned.

Expected behavior

Based on the documentation for password_recently_used, we expected the API to reject a password that has recently been used, including the current password.

For example:

Current password = A
New password     = A

should result in an error similar to:

HTTP 400
error: invalid_grant
suberror: password_recently_used

Actual behavior

The API returns:

HTTP 200

and the subsequent:

poll_completion

returns:

status = succeeded

The customer can therefore reuse their current password.

Questions

Could Microsoft please clarify the following?

1. Is password_recently_used currently enforced for Microsoft Entra External ID customer accounts when using the Native Authentication SSPR APIs?

2. Does password_recently_used apply to the /resetpassword/v1.0/submit endpoint for External ID customer accounts?

3. Is there any tenant-level configuration, password policy, SSPR configuration, or other setting required to enable password history/reuse protection for External ID customer accounts?

4. Is there a Microsoft-supported way to prevent a customer from setting their new password to the same password they are currently using when using the Native Authentication API?

5. If password reuse is expected to be allowed for this flow, could Microsoft clarify the documentation for password_recently_used and specify which account types or scenarios this error applies to?

Additional information

We understand that the Native Authentication SSPR APIs can support password reset/change scenarios. Our concern is specifically that the API documentation indicates that password_recently_used can be returned by /resetpassword/v1.0/submit, while our testing with External ID customer accounts consistently allows reuse of the current password.

We would therefore like to confirm whether:

this is expected behavior for External ID customer accounts;

there is a tenant or policy configuration that we are missing;

password_recently_used is not currently enforced for this scenario; or

this could be an API implementation/documentation discrepancy.

We can provide the following information for further investigation:

Tenant ID

Client/Application ID

Request IDs / Correlation IDs

UTC timestamps

Sanitized request/response logs

Customer account configuration

Exact API responses from each step of the flow

Please let us know what additional information is required to investigate this behavior.

**Thank you.**Absolutely. I recommend raising this as a Microsoft support ticket and framing it as a potential documentation/API behavior discrepancy, rather than immediately calling it a bug.

Here is a polished version you can copy directly into the Microsoft support request:

Microsoft Support Ticket

Subject: Microsoft Entra External ID Native Authentication API allows reuse of the current password despite password_recently_used documentation

Issue summary

We are using Microsoft Entra External ID Native Authentication APIs for customer accounts and have implemented the password reset/change flow using the following SSPR APIs:

/resetpassword/v1.0/start

/resetpassword/v1.0/challenge

/resetpassword/v1.0/continue

/resetpassword/v1.0/submit

/resetpassword/v1.0/poll_completion

According to the Microsoft Entra Native Authentication API documentation, the /resetpassword/v1.0/submit endpoint can return the following error:

error: invalid_grant
suberror: password_recently_used

The documentation describes this error as:

"The new password must not be the same as one recently used."

However, in our Microsoft Entra External ID tenant, we are unable to reproduce this behavior. The API allows the customer to set their new password to the same password they are currently using.

Test results

Test Case 1 – New password is the same as the current password

Current password: A
New password:     A

Result:

HTTP 200
poll_completion status = succeeded

The password reset operation completes successfully.

We expected the API to reject the request with:

error: invalid_grant
suberror: password_recently_used

but this error was not returned.

---

Test Case 2 – New password is different

Current password: A
New password:     B

Result:

HTTP 200
poll_completion status = succeeded

The password reset operation completes successfully as expected.

---

Test Case 3 – Reuse the newly changed password

After successfully changing the password from A to B:

Current password: B
New password:     B

Result:

HTTP 200
poll_completion status = succeeded

Again, the password reset operation completes successfully.

No:

suberror=password_recently_used

is returned.

Expected behavior

Based on the documentation for password_recently_used, we expected the API to reject a password that has recently been used, including the current password.

For example:

Current password = A
New password     = A

should result in an error similar to:

HTTP 400
error: invalid_grant
suberror: password_recently_used

Actual behavior

The API returns:

HTTP 200

and the subsequent:

poll_completion

returns:

status = succeeded

The customer can therefore reuse their current password.

Questions

Could Microsoft please clarify the following?

1. Is password_recently_used currently enforced for Microsoft Entra External ID customer accounts when using the Native Authentication SSPR APIs?

2. Does password_recently_used apply to the /resetpassword/v1.0/submit endpoint for External ID customer accounts?

3. Is there any tenant-level configuration, password policy, SSPR configuration, or other setting required to enable password history/reuse protection for External ID customer accounts?

4. Is there a Microsoft-supported way to prevent a customer from setting their new password to the same password they are currently using when using the Native Authentication API?

5. If password reuse is expected to be allowed for this flow, could Microsoft clarify the documentation for password_recently_used and specify which account types or scenarios this error applies to?

Additional information

We understand that the Native Authentication SSPR APIs can support password reset/change scenarios. Our concern is specifically that the API documentation indicates that password_recently_used can be returned by /resetpassword/v1.0/submit, while our testing with External ID customer accounts consistently allows reuse of the current password.

We would therefore like to confirm whether:

this is expected behavior for External ID customer accounts;

there is a tenant or policy configuration that we are missing;

password_recently_used is not currently enforced for this scenario; or

this could be an API implementation/documentation discrepancy.

We can provide the following information for further investigation:

Tenant ID

Client/Application ID

Request IDs / Correlation IDs

UTC timestamps

Sanitized request/response logs

Customer account configuration

Exact API responses from each step of the flow

Please let us know what additional information is required to investigate this behavior.

Thank you.