Every 90 days, the same thing happens. A reminder tells everyone their password has expired. Half the company changes Denton2024! to Denton2025!. The other half moves the exclamation point. Then the help desk fields a week of lockout calls from people who cannot remember which variation they used. Nobody is safer. Everyone is more annoyed.
We bring this up because password policy is one of the few security controls a small business fully owns. No vendor approval, no budget line. And in a lot of the offices we walk into around Denton County, the policy on paper is quietly working against the people it protects. The good news is that fixing it means doing less, not more.
Where the 90-Day Rule Came From
Forced rotation was not a bad idea when it was invented. If an attacker steals a scrambled copy of your password file, they can grind away at it offline for weeks. Changing passwords on a schedule shortens the window in which a cracked password is useful. On a whiteboard, that holds up fine.
The problem is what happens when real humans are asked to invent a genuinely new secret four times a year. They do not. They iterate. Spring becomes Summer. The number at the end goes up by one. Attackers figured this out long ago, and password-guessing tools include rules that mutate a known old password into its likely successors. The rotation meant to shrink the attacker’s window instead handed them a pattern.
The federal standards body most security frameworks lean on reached the same conclusion. In Revision 3 of Special Publication 800-63B, NIST wrote that verifiers “SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically).” In Revision 4, published in 2025, that recommendation hardened into a requirement: verifiers “SHALL NOT require subscribers to change passwords periodically.” NIST is clear about when a change is warranted, which is when there is evidence the credential has been compromised. Evidence, not the calendar.
Complexity Rules Are How You Get Password1!
The second half of the classic policy is the character-class requirement: one uppercase, one lowercase, one number, one symbol. The intent is variety. The result is that everyone produces variety the same way.
Think about how you would satisfy those rules under time pressure. Capitalize the first letter, because that is where capitals live in English. Put the number at the end. Pick an exclamation point, because you can find it without looking. Millions of people make those same three decisions, so the space of all possible passwords collapses into the much smaller space of passwords humans actually produce.
NIST’s current guidance is blunt: verifiers “SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords.” Note what that does not say. Symbols are not bad. Mandating them produces predictable output while making the password harder to remember, the worst possible trade.
Length Is the Part That Actually Helps
Guessing gets harder in a straight line as you add character types, and exponentially as you add characters. One more word beats one more symbol, every time. NIST Revision 4 puts numbers on it. Systems “SHALL require passwords that are used as a single-factor authentication mechanism to be a minimum of 15 characters in length.” Where the password is one part of a multi-factor sign-in, the floor drops to eight. Verifiers “SHOULD permit a maximum password length of at least 64 characters,” which matters more than it sounds: a system that silently truncates at 12 characters punishes your best-behaved users.
Fifteen characters sounds miserable until you count words instead of characters. Here is how we coach people to build a passphrase:
- Use words that have no business together. “copper lantern trout hallway” works. “I love the Dallas Cowboys” does not, because common phrases live in cracking dictionaries.
- Skip lyrics, scripture, and movie quotes. Anything typed online a million times is not a secret.
- Four or five words is plenty. You do not need to salt it with punctuation. Length is doing the work.
- Never reuse it. A long password used in four places is one breach away from being useless in all four.
Screen Against Breach Lists, Not the Calendar
This is the control that should replace rotation. NIST requires that when someone sets a password, the system “SHALL compare the prospective secret against a blocklist that contains known commonly used, expected, or compromised passwords.” If it matches, the user picks something else right then, before the weak password goes into service.
This addresses the attack that actually happens to small businesses. Criminals rarely sit and guess at your login page. They take username and password pairs already exposed in somebody else’s breach and try them against your systems in bulk. That works because people reuse passwords across personal and work accounts. Screening closes that door without asking anyone to memorize anything, and on most identity platforms it is a checkbox rather than a project.
Where a Password Manager Fits
Once you drop rotation and complexity theater, the remaining ask is real: every account needs a long, unique password. Nobody holds thirty of those in their head. That is what a password manager is for, and NIST now says systems “SHALL allow the use of password managers and autofill functionality.” CISA lists the same tool among its core recommendations, noting that “using strong passwords and a password manager are some easy ways to protect ourselves from someone logging into an account and stealing data or money.” A few specifics matter:
- Buy the business tier. You need shared vaults and an administrator who can recover access when someone leaves.
- Get credentials out of the spreadsheet. The shared workbook of logins on the file server is the most common thing we find.
- Treat autofill as a phishing check. A manager matches on the real web address. If it refuses to fill on a familiar-looking page, read the address bar.
- Protect the manager itself. One long passphrase plus a strong second factor. This is the one password everyone still memorizes.
None of this replaces multi-factor authentication. A password is a thing you know, and things you know can be phished no matter how long they are. For where second factors, passkeys, and hardware keys fit, see YubiKey vs. passkey vs. MFA and what a YubiKey actually is.
A Policy You Can Actually Write Down
- Set a 15-character minimum where the password is the only thing standing in the way, and require multi-factor authentication elsewhere.
- Drop character-class requirements. Allow every character, including spaces, and allow long entries.
- Turn off scheduled expiration, but keep the ability to force a reset.
- Force a change on evidence of compromise: a confirmed phishing click, a breach notice naming your domain, a sign-in from somewhere nobody works.
- Screen new passwords against known-compromised lists at the moment they are set.
- Deploy a business password manager so onboarding includes a vault, not a sticky note.
The Bottom Line
The old policy asked employees to do something humans are bad at, on a schedule, forever, then blamed them for the predictable result. Current guidance asks for one long unique secret per account, a tool to remember them, a check against passwords already known to be exposed, and a second factor on anything that matters. Fewer rules, less friction, better security, which almost never happens at once.
One honest caveat. If a compliance framework, a contract, or an insurance questionnaire specifically requires rotation, follow it and note the conflict. Standards move faster than paperwork. Just do not invent the requirement yourself.
If you are not sure what your password settings actually enforce, that is a normal answer and a short conversation to resolve. We can review your identity configuration, tell you what is really being applied, and help you land on a policy your team will follow. Contact us today.
Sources:
Comments are closed