Glossary
Smart Lockout
By Emil Björk · Microsoft ecosystem consultant, Gothenburg
An Entra ID feature that locks out attackers attempting credential brute-force while keeping legitimate users signed in.
Smart Lockout in Microsoft Entra ID is the mechanism that locks out attackers attempting credential brute-force or password-spray while keeping legitimate users signed in. Microsoft tracks failed sign-in attempts by IP and user agent; after a configurable threshold (10 attempts by default, locking for 60 seconds), further attempts from that source are blocked. Legitimate users on different devices / locations aren't affected. Critically, Smart Lockout uses familiar location and device patterns — a user signing in from their usual location isn't locked out even if attackers are spraying from elsewhere. Combined with Entra ID Password Protection (banning weak passwords) and MFA, Smart Lockout is part of the Entra ID account-protection baseline.
Why "smart" is the operative word
Traditional Active Directory account lockout policy locks an account after N failed attempts, from anywhere — which means an attacker who knows (or guesses) a valid username can deliberately trigger a lockout against a legitimate user as a denial-of-service tactic, entirely separate from actually trying to guess the password. Smart Lockout tracks failed attempts by a combination of the source (IP address, device/user-agent fingerprint) and familiarity (has this combination of location and device signed in successfully before), rather than by the account alone. That means an attacker spraying an account from unfamiliar infrastructure gets locked out quickly, while the legitimate account owner signing in from their normal laptop and home network in a different location is tracked separately and isn't penalised by the attacker's failed attempts against the same username.
Worked example
An attacker runs a credential-stuffing attempt against a specific employee's account from a rented cloud server, trying a list of passwords leaked from an unrelated breach. Smart Lockout tracks these attempts against the source (that cloud server's IP and connection fingerprint) separately from the employee's own familiar sign-in pattern. After the threshold of failed attempts from that unfamiliar source, further attempts from it are locked out for the configured duration — while the employee, signing in that same afternoon from their normal laptop at home, is entirely unaffected and isn't asked to deal with a locked account, because Entra ID recognises their location and device as an already-familiar combination distinct from the attacker's.
Interaction with hybrid Active Directory lockout
In a hybrid identity environment, Smart Lockout's cloud-side thresholds and the on-premises Active Directory's own account lockout policy are two separate mechanisms that can interact in confusing ways if their thresholds aren't reconciled — a cloud-only sign-in attempt is governed purely by Smart Lockout, but an attempt that reaches back to on-prem AD via pass-through authentication is also subject to AD's own lockout policy, and a mismatch (a looser cloud threshold feeding into a stricter, easily-tripped on-prem threshold) can produce on-prem account lockouts that Smart Lockout's own settings don't fully explain from the Entra ID side alone. Reviewing both policies together, rather than assuming the cloud-side configuration is the whole picture, avoids a class of confusing hybrid lockout tickets.
Common pitfalls
Smart Lockout's default thresholds are sensible for most tenants, but organisations with unusual sign-in patterns — a highly mobile workforce with genuinely no consistent "familiar location," for instance — can see more false-positive throttling than expected, since the familiarity signal has less history to work from. It's also worth knowing that Smart Lockout operates independently of, not as a replacement for, MFA and password protection — it slows down a brute-force attempt, but a weak, easily-guessed password combined with no MFA can still eventually be found within a lockout policy's own throttling limits if the attacker is patient and spreads attempts widely enough across accounts.