Your Company Password Policy Is Security Theatre (and NIST Agrees)

Every 90 days, somewhere in an office, a small tragedy repeats itself. A message pops up demanding a new password. The user sighs, changes Welcome2025! to Welcome2026!, writes it on a sticky note stuck to the monitor, and gets back to work feeling slightly less secure than before. The IT department logs this as a win.

I want to be very clear about something, because it will save you a lot of pointless effort. Almost everything the average corporate password policy demands, the forced resets, the one capital and one number and one symbol, the complexity meter that turns green when you add an exclamation mark, is either useless or actively harmful. This is not my hot take. It is, in writing, the position of the people who wrote the rules in the first place.

The standards body changed its mind. Your IT department did not.

The closest thing the world has to an official password rulebook is NIST Special Publication 800-63B, the digital identity guidelines from the United States National Institute of Standards and Technology. Half the security policies on earth are descended from it. In its current form, finalised in 2025, it says two things that should be printed and taped to every IT manager's door.

First, on forced password changes: verifiers should not require memorized secrets to be changed arbitrarily, for example periodically. Second, on those complexity rules: it recommends against requiring composition rules such as a mix of upper case, lower case, digits, and special characters.

Read that again. The single most common corporate password rule, change it every 90 days, and the second most common, it must have a capital and a number and a symbol, are the two things the standard now explicitly tells you to stop doing. Your company is not being extra careful. It is following a version of the advice that expired years ago.

Why forced resets make things worse

The logic of the 90-day reset sounds reasonable right up until you watch a real human deal with it. Nobody invents a fresh, strong, memorable password four times a year. They do what you do. Password1 becomes Password2. The good password they actually had gets retired and replaced with a weaker, more predictable one, because the brain flatly refuses to memorise a new random string every quarter.

NIST says this plainly. Frequent mandatory changes push people toward predictable patterns and insecure storage, the sticky note being the national flag of password policy. The correct trigger for changing a password is not the calendar. It is evidence that the password was actually exposed, such as a breach. Change it when there is a reason, not on a schedule designed to make an auditor nod.

Why "P@ssw0rd1" is a punchline

Composition rules feel like they add strength. Mostly they add predictability. Take the classic "P@ssw0rd1". It has an uppercase letter, lowercase letters, a number, and a symbol. It sails through nearly every corporate policy on the planet. It is also one of the first things a cracking tool tries, because attackers know every one of those cute substitutions. They bake "a becomes @" and "o becomes 0" and "1 on the end" straight into their wordlists.

The thing that actually makes a password hard to guess is not which characters you sprinkle in. It is length, and genuine randomness. A long string of random words beats a short tangle of symbols every time, which is why the modern guidance is to demand length, support passwords of at least 64 characters, push for 15 or more when the password is the only thing protecting an account, and then get out of the user's way.

What actually keeps an account safe

Here is the short, unglamorous list that does more than every complexity rule combined.

Length over complexity. A four to six word passphrase like "anchor violet tractor mango" is both easier to remember and harder to crack than "Xq7!p2". Generate one you did not pick yourself with our passphrase generator.
A unique password for every account, kept in a password manager. Reuse is the real killer. One breached site should never unlock the others. Let a manager create long random passwords with the password generator and remember them for you.
Screen against known breaches. Modern guidance says to check new passwords against lists of already-leaked ones. If a password has shown up in a breach, it is burnt, no matter how many symbols it has.
Turn on multi-factor authentication, and use passkeys where you can. A second factor stops most attacks even when the password leaks.
Stop answering security questions honestly. Your mother's maiden name and your first school are not secrets, they are a search away. Treat the answers like extra passwords and make them random too.

If you want to see the difference for yourself, run your current password through our strength checker, which looks at length and predictability rather than just counting character types. Do not paste a password you actively use into random websites, by the way. Ours runs entirely in your browser, but treat that as the rule everywhere.

So why does the theatre continue

Because theatre is easy to audit. "We force a reset every 90 days and require a symbol" fits neatly in a compliance spreadsheet. "We encourage long unique passphrases, screen against breach lists, and enforce multi-factor authentication" requires actually understanding the threat. One looks like security to a clipboard. The other is security. Guess which one wins in most organisations.

There are real exceptions. Some regulations, like certain payment-industry rules, still mandate rotation, and where the law says jump, you jump. But for the policies your company invented on its own, the ones nobody can quite explain, the answer is almost always that someone copied a checklist from 2005 and never looked at it again.

The bottom line

Strong account security in 2026 is short and boring. Long unique passphrases, a password manager, breach screening, and multi-factor authentication. Everything else, the quarterly reset, the symbol requirement, the green complexity bar, is mostly there to look busy. The standards body that started the whole thing has moved on. The only thing stopping your IT department from doing the same is the comfort of a rule that feels strict and does nothing.