Password Rotation Policies Under Scrutiny: NIST Guidelines, Historical Origins, and Logical Flaws

The debate over scheduled password changes has resurfaced after a reference to NIST guidance in an earlier article on the Hive Systems password table sparked extensive commentary. NIST recommends changing passwords only when compromise is detected rather than on a calendar basis. Critics raised several objections: public breach databases are incomplete, scheduled rotation limits the window for offline hash cracking, it terminates unknown active sessions, and user inconvenience is not a valid reason to abandon good hygiene.

The author argues that these discussions often follow flawed reverse logic. Proper security design, as outlined in FSTEC Russia Order No. 117, GOST R ISO/IEC 27001, and the FSTEC threat assessment methodology, begins with threats and then selects controls. In contrast, many defenses of 90-day rotation start with the existing policy and then construct hypothetical scenarios to justify it.

This reverse approach can justify almost any measure. Requiring password changes every 12 hours or never changing them at all can both be "proven" useful by inventing suitable threats. The author proposes a practical test: state the conditions under which the control would be considered unnecessary. If such conditions cannot be formulated, the measure is being rationalized rather than justified.

A key distinction is drawn between leakage and compromise. Leakage is an objective event in which secret information becomes known to unauthorized parties. Compromise is the loss of grounds for trusting that the secret remains known only to authorized persons. NIST and FSTEC documents therefore require replacement when there is reason to doubt secrecy, not only when an actual leak is proven. Internal signals such as personnel changes, workstation incidents, or anomalous logins often provide stronger indicators than external breach repositories.

The 90-day figure is frequently attributed to the 1985 U.S. Department of Defense "Green Book" (CSC-STD-002-85). Examination of the document shows the claim is incorrect. The Green Book models password lifetime as an input parameter rather than a derived result and demonstrates that extending the lifetime from six months to a year changes the required password length by only a fraction of a character. The authors explicitly state that lifetime is not a critical factor provided the password is changed at least annually.

Crucially, the Green Book calculations assume an online attack with rate limiting. When a password hash database is stolen, the guessing rate increases by many orders of magnitude and the model no longer applies; only increased password entropy (length and complexity) remains effective. This limitation was already recognized in 1985.

PCI DSS v4.0 requirement 8.3.9 now permits organizations to replace the 90-day rotation mandate with continuous monitoring and dynamic analysis of account behavior. The article concludes that scheduled rotation is only defensible when detection capabilities are absent; once proper monitoring exists, targeted changes upon detected compromise are strictly superior.