nist says stop forcing password rotation

nist says stop forcing password rotation

for years every corporate policy doc said the same thing. change your password every 90 days. it felt like security theater even before we had data to prove it, and now we have the data. nist quietly killed this advice in sp 800-63b, and a lot of sysadmins still haven't gotten the memo because the old habit is baked into every onboarding checklist ever written.

why forced rotation backfires

here's what actually happens when you force people to change passwords on a schedule. they don't generate a fresh random password every 90 days. they take their old password and increment it. summer2024! becomes summer2024!! becomes fall2024!. the pattern is predictable, it's weaker in practice than a password that never changes, and it gives attackers a smaller search space if they ever get a leaked hash to work from.

it also trains users to write passwords down on sticky notes because nobody can memorize a new string every quarter. you end up trading a theoretical benefit for a very real, very physical vulnerability sitting under someone's keyboard.

checking your own systems

on any linux box you manage, you can see the current rotation policy with one line:

grep PASS_MAX_DAYS /etc/login.defs

break that down: grep is just searching a text file for a pattern. PASS_MAX_DAYS is the setting inside /etc/login.defs that controls the maximum number of days a password is valid before the system forces a change. if that number is set to something like 90 or 60, congratulations, your system is enforcing the exact policy nist told everyone to stop using.

you can check an individual user's actual expiration settings too:

chage -l username

this shows you password last changed, expiration date, and warning period for that specific account, which is useful when you inherit a server and have no idea what policies were applied to which users.

what nist actually recommends instead

the updated guidance shifts the focus from "change it often" to "make it long, unique, and only change it when there's a reason." a reason means a suspected breach, a leaked credential, or evidence of compromise, not a calendar reminder. the priorities nist actually cares about are length over complexity, screening new passwords against known breach lists, and turning on multi-factor authentication wherever it's available.

length beats complexity because a long passphrase is exponentially harder to brute force than a short password stuffed with symbols. "correct horse battery staple" style passphrases are easier for humans to remember and harder for machines to crack than "P@ssw0rd1!".

fixing it on your own machines

if you find your systems still enforcing rotation, here's how to move toward the better model. first, stop forcing arbitrary expiration. you can set max days to a very high number or effectively disable it for a given user:

sudo chage -M 99999 username

second, replace that removed control with something that actually matters. enable mfa on every account that supports it, ssh, sudo, whatever you're running. third, if you have the tooling, screen new passwords against breach databases like haveibeenpwned's api or a local copy of known-compromised password lists, so weak or reused passwords get rejected at creation time instead of relying on rotation to eventually flush them out.

fourth, actually monitor for compromise instead of assuming rotation will save you. watch auth logs, set up alerts for repeated failed logins, and have a real process for forcing a password reset the moment you suspect an account is burned, not on some arbitrary 90 day timer.

the takeaway

forced rotation feels like security because it looks like effort, but it mostly just annoys your users into weaker habits. run that grep command on your systems, see what policy you're actually enforcing, and if it's still stuck in 2003, update it. long unique passwords, mfa everywhere, and real breach monitoring will protect you far better than making everyone type a new password every three months.