The Password Rules Were Wrong. What Else Is?

For roughly 15 years, most organizations told employees the same thing about passwords: mix uppercase and lowercase letters, add a number and a symbol, and change them regularly, typically every 90 days. The rules traced back to NIST guidance drafted in 2003, and they spread into nearly every policy, audit checklist, and system default.

People complied in a way that seems obvious only in hindsight. Password1! became Password2!, then Password3!. The rules made passwords harder to remember without making them much harder to guess.

In 2017, NIST revised its digital identity guidelines and advised organizations to drop composition rules and scheduled changes. The current version, finalized in 2025, goes further, changing “should not” to “shall not.” William Burr, who wrote the original password guidance as head of NIST’s Security Technology Group, told The Wall Street Journal in 2017, “Much of what I did I now regret.”

The reasons the old rules lasted so long, and what replaced them, hold lessons well beyond passwords.

Easy to check, hard to see failing

The old rules survived because they were easy to verify, which had little to do with whether they worked. An auditor could confirm them on a single configuration screen. A questionnaire could ask about them in a yes-or-no box.

Their failure, by contrast, was invisible. Reports didn’t show how many employees had cycled from Spring2012! to Summer2012!, or how many kept their current password on a sticky note. The control produced clean evidence of compliance without evidence of results.

Plenty of other controls share that profile. Training completion rates show how many people clicked through the modules, not how many would report a phishing email. Annual policy acknowledgments prove that employees checked a box, not that they read the policy. Both are easy to report and say little about whether the controls work.

That combination is how security programs become overcomplicated. Controls that are simple to demonstrate stay in place whether or not they’re simple to execute, and the program keeps adding them. Eventually people can’t keep up, and the shortcuts they take can leave the organization less secure than a simpler program would.

What replaced the old rules

NIST didn’t make passwords less important. It shifted the burden from people to systems, as the table below shows.

What the old rules asked of people	What the current guidelines ask of systems
Mix character types	Require at least 15 characters when a password is the only factor
Avoid weak or reused passwords	Check every new password against a list of common and compromised passwords, and explain any rejection
Change passwords on a schedule	Force a change only when there’s evidence of compromise

Each change asks less of people and more of systems. The result is a control that’s simpler to execute and stronger, since protection depends far less on thousands of individual choices.

The same pattern beyond passwords

Controls that share the overcomplication problem tend to have a few things in common. They ask for more effort than people can sustain, produce tidy evidence, and can be satisfied in form rather than substance. Common examples include:

• Access reviews. Managers asked to certify hundreds of entitlements each quarter often approve the whole list. The review is documented, and the excess access stays. Focusing reviews on privileged access and recent changes makes them manageable, and granting access through defined roles shifts much of the work to the system.

  
  

• Vendor questionnaires. Many organizations send every vendor the same questionnaire. Vendors have every reason to answer yes, reviewers rarely have time to check, and the completed file becomes evidence that third-party risk is managed. Tiering vendors by the data and access they hold, and asking critical ones for independent evidence such as a SOC 2 report or recent penetration testing results, put the effort where the risk is.

  
  

• Data classification. A scheme with six or seven sensitivity levels asks employees to make a judgment call every time they save a file. Many pick whatever label lets them complete their work with the least friction. Fewer levels, with labels applied automatically where possible, produce more accurate results.

Three questions for any control

To find the controls in your own program that behave like the old password rules, start by asking these questions.

1. What do real people do in response to it? Judge a control by the behavior it produces, not the behavior it requires. A manager who approves 400 entitlements in 10 minutes has completed the review without really performing it.

   
   

2. Who carries the burden, a person or a system? Controls that depend on sustained human effort erode over time. Controls that systems enforce stay consistent. A label applied automatically is as accurate on Friday afternoon as it is on Monday morning.

   
   

3. Would we keep it if no one checked for it? A control that survives mainly because it’s easy to show an auditor may be adding complexity without adding protection. A 300-question vendor questionnaire that no one has time to read is a strong candidate.

Before you retire a control

Before retiring any control, check what else depends on it. NIST isn’t the only authority over a password policy, for example. PCI DSS still requires passwords to mix letters and numbers, and it requires 90-day changes unless MFA or continuous risk analysis is in place. Beyond passwords, the CJIS Security Policy, HIPAA, a cyber insurance policy, or a contract clause may still call for the control you want to drop.

So retire controls deliberately, and document the rationale for each change. In many cases, the best path is the one NIST took. A system control such as MFA can satisfy the requirement and make the old rule unnecessary, taking the burden off people.

The old password rules lasted because they seemed rigorous and were easy to prove. NIST dropped them because someone measured the results. Every security program has controls in the same position, and finding them is one of the most practical ways to make a program simpler and stronger at the same time.

Securance helps organizations sort the controls that reduce risk from the ones that only add work, through risk assessments, governance and policy development, and vCISO services, all led and executed by senior consultants. 

If your program has controls that are easier to prove than to justify, talk with our experts about where to start.