Locking / Unlocking Accounts after multiple failed attempts

Question

I am using Native Authentication to Sign In to my application by calling these endpoints:

1. https://<tenant>/oauth2/v2.0/initiate
2. https://<tenant>/oauth2/v2.0/challenge
3. https://<tenant>/oauth2/v2.0/token

Is there a way to 'lock' the account after, example, 10 failed attempts? Because when I try more than 10 times, the account is not locked out.

In the Entra Admin Portal (Authentication Methods), Password Protection / Smart Lockout does not seem to be the solution:

I would also highly prefer to not be toggling Account Enabled to yes and no

Below is a screenshot of when a user is created in our application

Answer 1

Hello Jinki Lee,

It looks like you’re calling the native OAuth2 endpoints against a cloud-only Azure AD tenant and you’re not seeing the user get locked out even after 10 bad password attempts. A few things to know:

1. Microsoft Entra Smart Lockout is turned on by default for Azure AD accounts
   • Default threshold is 10 failed attempts (60 sec lockout) for public clouds.
   • If your tenant has Azure AD P1/P2 you can tweak those values under Entra ID > Authentication methods > Password protection (see screenshot in your post).
2. Geo-distribution and datacenter replication can make it look like you get more than 10 “tries” before the lock actually fires
   • Each authentication datacenter keeps its own counter. Until all of them sync you can sometimes see up to (threshold × datacenter count) failures show up before you actually hit the lockout state.
   • Once the account is locked you’ll see AADSTS50053 in your token response and sign-in logs.
3. There’s no built-in “manual unlock” for smart lockout — you have to wait out the duration (or use SSPR if you’ve enabled it). Admins today can’t click “unlock user” on a smart-lockout event.
4. If you really need a hard disable after exactly N tries, you’ll have to build that logic yourself (for example, track failed sign-ins in your app or via sign-in logs + an Azure Function, then call the Graph API to set user.accountEnabled = false when you hit your custom threshold).

Here are some things to check to make sure smart lockout is applied correctly: • Have you confirmed that the user is a cloud-only (non-federated) account? • Do you have at least Azure AD P1 licenses (required if you want to customize threshold/duration)? • After you hit 10 failures, do you see any AADSTS errors or “temporarily locked” messages? • Can you find the bad-password attempts in the Sign-ins blade or via the audit logs?

If you need more control over exactly when and how an account gets disabled, the recommended pattern is:

1. Capture your app’s sign-in failures (or ingest sign-in logs via Azure Monitor)
2. When you detect your own “10th failure,” call Microsoft Graph to disable the account
3. Re-enable via Graph once you’re ready

Hope that clarifies why you aren’t seeing a hard lockout right at “attempt #11” and points you at your options.

References • Manage Microsoft Entra smart lockout values:

https://learn.microsoft.com/en-in/entra/identity/authentication/howto-password-smart-lockout#manage-microsoft-enra-smart-lockout-values

Troubleshoot account lockout with Azure AD Domain Services (for FGPPs): https://learn.microsoft.com/entra/identity/domain-services/troubleshoot-account-lockout