The Password Policy Nobody Follows (And Why That's Your Fault)
Somewhere in your organization right now, there is a sticky note on a monitor. You know the one. It has a username on it, and beneath the username, a password that almost certainly contains the word "Summer" or "Welcome" and ends in an exclamation point because the policy requires a special character and the exclamation point is the path of least resistance. This sticky note is not evidence of a reckless employee. It is evidence of a password policy that was designed by someone optimizing for security requirements rather than human behavior, and those two design goals are not always the same thing.
The history of password policy in enterprise IT is essentially a case study in well-intentioned rules producing the opposite of their intended outcomes. Mandatory complexity requirements produced passwords like "P@ssw0rd1!" that are simultaneously compliant and trivially guessable. Mandatory rotation schedules produced passwords like "Summer2024!" cycling to "Summer2025!" on a predictable annual schedule that attackers learned to account for. Prohibitions on writing passwords down produced sticky notes hidden slightly under keyboards rather than openly on monitors, which is not a security improvement. Every policy that treats the human as the problem to be constrained rather than the behavior to be supported has generated a creative workaround that is usually worse than the original risk.
The research on this has been settled long enough that it should no longer be controversial: long passphrases beat complex short passwords for both security and memorability, mandatory rotation without evidence of compromise produces weaker passwords over time, and the single highest-impact intervention available is multi-factor authentication, which makes the password itself significantly less consequential. The National Institute of Standards and Technology updated its guidance on this years ago. Many enterprise password policies have not caught up, either because nobody reviewed them after the initial implementation or because the compliance framework the organization operates under has not updated its requirements and the internal policy mirrors the compliance requirement rather than the actual threat model.
The stickier problem, and the one that requires actual leadership rather than policy revision, is the cultural dimension. Security behavior is social behavior. People take their cues about how seriously to treat security requirements from what they observe around them, including whether leadership follows the same rules, whether violations have visible consequences, and whether the security team is perceived as a function that enables the business or one that obstructs it. An organization where the CEO's assistant manages the CEO's password because the CEO finds the policy inconvenient has communicated everything its employees need to know about how seriously to take that policy. Password hygiene is not a technical problem. It is a leadership credibility problem with a technical symptom.
The path forward is not a stricter policy delivered via a strongly worded all-hands email. It is a policy redesign that starts with human behavior as the constraint rather than the obstacle, a MFA rollout that removes the password from the critical path entirely for most access scenarios, and a security culture that makes good behavior the easier choice rather than the effortful one. The sticky note on the monitor is not the enemy. It is a design failure wearing a Post-it costume, and it deserves a design solution rather than a scolding.
