Apply the NIST password guidelines in Active Directory
With Lithnet Password Protection, you can bring the NIST password guidelines to your Active Directory. NIST SP 800-63B recommends long passwords checked against a blocklist of common and compromised passwords, in place of complexity rules and scheduled password changes. Password Protection gives Active Directory that blocklist, built from Have I Been Pwned, your own breached password lists and your banned words, so your users can choose long passphrases they can remember while predictable passwords like Password1! stay out.
Support plans from USD 750 a year, including 300 usersFree for every organization
Complexity rules
P@ssw0rd1
- Meets the complexity rules
- Found in Have I Been Pwned
Rejected
Length-based policy
harbour lantern quietly sixty
- 29 characters long
- Not in any breach
Accepted
NIST SP 800-63B, rule by rule
NIST SP 800-63B sets out what a modern password policy should do. The table shows how each of its password rules is met in Active Directory with Lithnet Password Protection in place, and where Password Protection makes the difference.
| NIST SP 800-63B guidance | How you do it with Password Protection |
|---|---|
| Check every new password against a blocklist of commonly used, expected or compromised passwords, such as passwords from earlier breaches, dictionary words and words specific to your organization. | You build your own list of banned passwords from the sources that you choose. Password Protection checks every password change and reset against that list. For example, you can download the Have I Been Pwned list to your own network and refresh it whenever you like. You can also add the breach lists that your SOC or security partners give you and ban words such as your company and product names. With the checks turned on, Password Protection rejects any match before Active Directory saves the password. Have I Been Pwned for Active Directory |
| Block words specific to your organization and their derivatives, but compare the whole password, so a password isn't rejected only because a listed word appears inside it. | People make passwords in predictable ways that attackers know well, such as an @ for an a or a 1 for an i. Password Protection checks each new password to see whether it is just a banned word in disguise. For example, when "winter" is banned, Winter2026! and W1nter! are rejected. A long passphrase that happens to contain the word is still allowed. |
| Require at least 15 characters when the password is the only thing used to sign in, or at least 8 when it's always used with multi-factor authentication. | Set the minimum length in your Active Directory password policy or in Password Protection. Most people can't remember 15 random characters. We recommend that you let your users choose passphrases instead, because a few words together are long and easy to remember. With Password Protection's length-based complexity, you can reward length over complexity so that a long passphrase doesn't need numbers or symbols. |
| Stop requiring a mix of character types. | Turn off Active Directory's complexity requirement and rely on length and the blocklist instead. If your users need time to adjust, you can use Password Protection's length-based complexity to set different rules for different lengths. For example, you can require mixed character types for passwords under 15 characters and nothing extra at 15 characters or more. This lets you move your users to passphrases step by step. Because NIST's full guidance drops character-type rules altogether, we recommend that you plan to phase them out. |
| Stop asking users to change their passwords on a schedule, and force a change when there's evidence that a password has been compromised. | Turn off password expiry in Active Directory's password policy. To find compromised passwords, you can run a Password Protection audit at any time. The audit checks your users' current passwords against your breached password lists and lists the accounts that match. You can then require those users to change their password at their next logon. |
Summarized from NIST SP 800-63B revision 4, section 3.1.1.2 (NIST).
Complexity rules make passwords more predictable
NIST explains that people respond to complexity rules in predictable ways. Someone who wanted "password" picks "Password1", or "Password1!" when a symbol is required. Attackers are likely to try passwords like these because they have worked before. As a result, the rules add less strength than expected and make passwords harder to remember. NIST recommends length and a blocklist instead. With Password Protection, you can make that change in Active Directory without letting those predictable passwords back in.
NIST SP 800-63B, Appendix AAdopt the NIST guidelines at your own pace
You don't have to change everything at once because you can turn on each Password Protection check independently. You can start with the breached-password check and then raise the minimum length and remove complexity rules and password expiry when your users are ready. Password rules apply only when a user changes their password, so existing passwords keep working until then.
Lithnet Password Protection prioritizes safety
There's no service more important in an organization than its Active Directory. The Password Protection code is built with best practice code safety and extended protections to ensure that nothing ever impacts domain controller operation.
Already using Microsoft Entra Password Protection?
NIST recommends checking every new password against a blocklist of commonly used passwords and passwords from previous breaches. Microsoft Entra Password Protection blocks common weak passwords, but Microsoft states that its list isn't based on breached passwords. Lithnet Password Protection allows you to add the full Have I Been Pwned data set, or your own breached password lists.
Compare with Entra Password ProtectionFrequently asked questions
Which parts of NIST SP 800-63B does Password Protection cover?
Password Protection gives Active Directory the blocklist check at the heart of the guidelines, and lets you set the minimum length and reward long passwords with fewer complexity rules. Its audit finds the compromised passwords already in your directory, so you can require a change only from the users who need one. Together with Active Directory's own password settings, you can put the password rules of SP 800-63B in place across your domain.
Do we have to turn off password expiry to use Password Protection?
No. Password Protection works alongside your existing Active Directory password policy, so you can start with the breached password check and move to the rest of the NIST guidelines at whatever pace suits your organization.
Get started today
Support plans start at USD 750 a year, including 300 users. Lithnet Password Protection runs on your domain controllers, and a support plan ensures you have help available directly from Lithnet when you need it. We're there to help troubleshoot problems, provide advice, and ensure you are first to be notified about security fixes.