Password policy design
Nov 2, 2026
Complexity rules alone don’t stop weak passwords. Users meet them with predictable tweaks, like changing Jaroslaw102026! to Jaroslaw112026!, and attackers build their tools around those habits. A modern password policy rejects usernames, keyboard and repeating patterns, character substitutions, and breached passwords, which blocks the guessing behind spraying, credential stuffing, and dictionary attacks
Your org has complex password requirements, and users still find a way around them. It needs a capital letter, a number, and a special character, so you change
Jaroslaw102026!
to
Jaroslaw112026!
Yeah, Jaroslaw is my name, if you haven't guessed.
Whoever wrote the password rules did it a long time ago and never went back to check them against breached password databases or today's patterns.
Complexity rules
Many organizations built their policy around older NIST guidance. It was written for federal authentication systems, but private organizations could adopt it voluntarily, and plenty did. Humans then found the easiest way to meet every requirement. When passwords got too complex to remember, people put them on a piece of paper. Swapping characters in something memorable became the new normal.
Attackers know this, and they build their tools around it. Current NIST guidance (SP 800-63B) has moved away from composition rules and toward screening passwords against common and breached lists.
Attacks a password policy can prevent
A policy won't stop every attack, but it takes away the easy wins. These are the ones it directly affects.
Dictionary attacks. Attackers run huge lists of common words and known passwords against an account. A policy that blocks dictionary words means those guesses fail before they start.
Rule-based and mutation attacks. Cracking tools don't only try "password." They try Password1!, P@ssw0rd, and every common swap of a letter for a number or symbol. If your policy only checks that a special character exists, these passwords pass. A policy that detects character substitution rejects them.
Password spraying. Instead of hammering one account, attackers try a few common passwords across thousands of accounts to stay under lockout thresholds. Patterns like Winter2026! or Company123! are the usual targets. Blocking predictable patterns removes the passwords spraying depends on.
Credential stuffing. Attackers take usernames and passwords from earlier breaches and try them on your systems, betting that people reuse them. Checking new passwords against breach data blocks the ones already circulating.
Targeted guessing. If your name is Jaroslaw, an attacker who finds that on LinkedIn will try Jaroslaw plus a year. Blocking personal names and usernames takes the most obvious guesses off the table.
Offline cracking. When attackers steal password hashes, weak passwords fall first. A policy can't prevent the theft, but rejecting predictable passwords makes the cracking take far longer.
What your password policy should reject
When you redesign your policy, decide where you stand on each of these:
- Personal names and usernames: block them.
- Repeating patterns: reject Jarojaro and Jaaaaaro.
- Keyboard patterns: reject ASDFG and similar runs.
- Character substitutions: detect them, so a pattern like abcd can't be scrambled into something that passes.
- Breached passwords: check against known breach data, at creation and on a schedule.
Uppercase, lowercase, numeric, and special character requirements still have a place. Build the pattern rules on top of them.
How Netwrix Password Policy Enforcer helps
Native Active Directory password policies can’t do most of the above. Netwrix Password Policy Enforcer adds:
- Multiple password policies for users, groups, and OUs
- Custom complexity controls for length, character sets, and passphrases
- Dictionary and pattern protection that blocks common words, substitutions, and predictable patterns
- Username blocking, so people can’t build a password from their own account name
- Keyboard pattern blocking, such as ASDFG
- Compromised password checks against breach data, such as Have I Been Pwned, during password creation or scheduled scans
- Real-time feedback so users know whether the new password they are typing has satisfied the policy-designated requirements
- Policy testing before deployment, so you can see the impact before users do
- Built-in compliance templates for CIS, HIPAA, NERC CIP, NIST, PCI DSS, and CJIS
Two more things to do
Turn on MFA. AI tools can guess a 15-character password if it's predictable. MFA protects the account when a password falls anyway.
Store passwords in a vault. A vault gives people a safe place for credentials instead of paper or a spreadsheet. Netwrix Password Secure covers that.
Block weak, reused, and compromised credentials with Netwrix Password Policy Enforcer.
Learn moreShare on
Learn More
About the author
Jarosław Bogalecki
Product Manager
Jarosław Bogalecki is a Product Manager at Netwrix, responsible for PolicyPak and Password Policy Enforcer. He has worked in technical roles since 2019, with a passion for product strategy, AI, and building solutions around real customer problems. Prior to Product Management, he worked in Application Engineering and Technical Consulting.