Password rotation still shows up in security frameworks: change your password every 90 days. Most organizations still enforce it, because the control is named and named controls get implemented literally.

Here is what actually happens when you enforce it. A password that was Summer2024! becomes Summer2024!! at the next forced change, then Summer2024!!! at the one after that. The user isn’t being lazy. They’re solving the problem they were handed: produce something the system will accept, that they can still remember, on a deadline they didn’t choose. The incrementing pattern is a rational response to an irrational requirement.

The control ran. It’s in the audit log. It did not make credential compromise less likely. A predictable, incrementing password is easier to guess than a strong one a person would have chosen and kept, if the policy had let them.

The practitioner’s question

A hardware security key like a YubiKey gets you what the rotation policy was actually trying to deliver: only the authorized person can authenticate. It does this without asking anyone to invent a new secret on a deadline, and it doesn’t degrade over time the way a memorized password does, because there’s no secret for the user to gradually simplify. The intent behind the policy, only the right person gets in, is served directly, by a mechanism that doesn’t depend on human behavior holding up under a schedule.

That’s the gap that matters. The rotation policy specified an activity: change the password every 90 days. It never specified the outcome it was trying to produce. Frameworks do this because they have to. NIST, ISO/IEC 27001, SOC 2: these are written to apply across organizations, industries, and technology stacks that didn’t exist when large parts of the framework were drafted. A framework that named a specific mechanism would be obsolete before it shipped, so it names the class of control instead and leaves the mechanism to you.

That’s a reasonable constraint on a framework. It isn’t an excuse for a practitioner. The question a framework can’t ask on your behalf is the one that actually matters: what is this control trying to prevent, and is there a way to prevent it that doesn’t depend on people doing the hard thing correctly, every time, forever? Sometimes the framework-named control is still the best available answer. Increasingly, it isn’t. Picking the better one, with the mapping back to the framework’s intent documented, satisfies that intent more directly than compliance with the literal control would have.

When it isn’t a control at all

Password rotation is a mechanism that exists and underperforms. There’s a category one step past that: mechanisms that don’t reliably function as controls at all.

Security awareness training is the clearest example. Nearly every framework requires evidence of it: completion records, quiz scores, phishing simulation pass rates. Organizations spend real hours every year generating that evidence, and audits treat it the way they treat a technical control, as something that either happened or didn’t.

But a technical control performs its function on its own. A hardware key doesn’t need the user to be alert. A build pipeline that rejects unsigned dependencies doesn’t need the engineer to remember to check. Awareness training has no equivalent guarantee. It depends on every person recognizing the right threat and making the right call, every time, under pressure specifically designed to defeat good judgment in the moment. A quiz score afterward doesn’t tell you whether that held up. A phishing simulation that people have learned to recognize as a simulation isn’t testing the thing you actually care about.

None of this means awareness has zero value. People who know what a credential-harvesting page looks like are somewhat less likely to hand a password to one. But the time most organizations spend proving the training happened is wildly out of proportion to the risk it actually reduces. Call the activity what it is: evidence generation, not risk reduction.

The useful response isn’t canceling the training and hoping for the best. It’s stopping the practice of treating it as a control and planning the program around what it can’t guarantee. Assume people will click the wrong thing, because some of them, some of the time, will. Design for that: phishing-resistant authentication that makes a harvested password useless on its own, isolation that limits what a single compromised session can reach, blast radius constraints that hold regardless of which individual made the mistake. These work whether or not the training landed. Awareness training isn’t in the same category as they are, and shouldn’t be budgeted or defended as if it were.

What the question buys you

Every control, technical or procedural, encodes a claim about what it prevents. The practitioner’s job is interrogating that claim: what is this actually trying to stop, can the mechanism you’ve chosen reliably stop it, and if it can’t, what would? That’s not a new discipline. It’s the one this series has been describing since the first article: governance defines what you’re accountable for, threat modeling tells you what threatens it, risk assessment tells you how much that matters. Asking what a control is actually for is that same discipline, run at the level of a single line item instead of the whole program.

It also changes the conversation you have with an auditor. If you can state precisely what a control is meant to prevent, and show that your mechanism satisfies that intent more reliably than the one named in the framework, you’re not asking for an exception. You’re making a case. That case, not the literal text of the control, is what the next piece in this series is about.