Lift the keyboard at any front desk in America and there is a decent chance a password is taped underneath it. The EHR login is shared by three people because the vendor charges per seat. The Wi-Fi password is the practice name. And somewhere in the policy binder is a sentence that says passwords must be eight characters with a capital letter and a symbol, changed every ninety days, which everyone believes HIPAA requires.
HIPAA requires none of those specifics. It requires something both easier and harder: a documented, defensible set of procedures. This post quotes the actual specification, explains what "Addressable" does and does not mean, sets out what the current federal password guidance says (it has changed more than most policies have), and covers the proposed Security Rule language that would tighten this, framed as what it is: proposed.
HIPAA Password Requirements: The Text, the Label, and the Gap
1. The Only Sentence About Passwords in the Security Rule
45 CFR 164.308(a)(5) is the security awareness and training standard. Its fourth implementation specification, at (a)(5)(ii)(D), reads in full: "Password management (Addressable). Procedures for creating, changing, and safeguarding passwords." That is the entire text. No length, no complexity, no rotation interval, no lockout threshold. The rule tells you to have procedures and leaves their content to you, subject to the general duty in 164.306(a) to "protect against any reasonably anticipated threats or hazards."
Three related specifications do the rest of the work. Unique user identification, 164.312(a)(2)(i), is Required: "Assign a unique name and/or number for identifying and tracking user identity." That sentence outlaws the shared EHR login on its own. Person or entity authentication, 164.312(d), is also Required: "Implement procedures to verify that a person or entity seeking access to electronic protected health information is the one claimed." And log-in monitoring, 164.308(a)(5)(ii)(C), Addressable, asks for "procedures for monitoring log-in attempts and reporting discrepancies."
2. Addressable Is Not Optional
164.306(d)(3) defines the label. For an addressable specification a covered entity must "assess whether each implementation specification is a reasonable and appropriate safeguard in its environment," then either implement it or "document why it would not be reasonable and appropriate" and "implement an equivalent alternative measure if reasonable and appropriate." There is no practice for which password procedures are unreasonable, so the assessment step ends the same way every time: write them. The longer treatment is in why addressable does not mean optional.
3. What "Reasonable and Appropriate" Means Now: NIST Changed the Answer
Because HIPAA supplies no numbers, investigators and auditors look to recognized guidance to judge whether procedures were reasonable. The reference document is NIST Special Publication 800-63B, and its current edition, SP 800-63B-4, was published in July 2025. It reverses several habits that older HIPAA policies still enforce. Quoting the verifier requirements:
- Passwords "used as a single-factor authentication mechanism" must be "a minimum of 15 characters in length." Passwords used only as part of multi-factor authentication may be shorter but must be "a minimum of eight characters in length."
- Verifiers "SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords."
- Verifiers "SHALL NOT require subscribers to change passwords periodically. However, verifiers SHALL force a change if there is evidence that the authenticator has been compromised."
- Chosen passwords are checked against "a blocklist of commonly used, expected, or compromised values," and a blocked password must be replaced.
- Verifiers "SHALL implement a rate-limiting mechanism that effectively limits the number of failed authentication attempts."
- Verifiers "SHALL allow the use of password managers and autofill functionality," and "SHALL NOT permit the subscriber to store a hint" or use security questions when choosing passwords.
Read that against the taped-under-the-keyboard problem. Forced 90-day rotation plus symbol requirements produce "Winter2026!" followed by "Spring2026!", written down because nobody can remember them. Length, a blocklist, a password manager, and multifactor authentication produce credentials people do not need to write down. The guidance is written for federal systems, and NIST says it is not intended to constrain others, but it is what "authoritative sources" means when anyone asks whether a practice's procedures were reasonable.
| Old policy habit | Current NIST SP 800-63B-4 position | What to write |
|---|---|---|
| 8 characters, mixed case, number, symbol | 15 characters minimum for single factor; 8 with MFA; no composition rules | Minimum length by system; long passphrases encouraged; no symbol requirement |
| Change every 60 or 90 days | No periodic change; forced change on evidence of compromise | Change on suspicion, on staff departure, and on vendor notice |
| No guidance on reuse | Blocklist of common and breached values | Systems that support a blocklist have it on; staff never reuse a work password elsewhere |
| Unlimited login attempts | Rate limiting required | Lockout or throttling on every system that supports it; monitored per 164.308(a)(5)(ii)(C) |
| Password managers discouraged | Password managers must be allowed | Practice-approved manager issued to every user; shared vault for the few unavoidable shared credentials |
| Security questions as backup | Not permitted | MFA as the recovery path, never "mother's maiden name" |
One more point about the guidance. NIST rewrote these rules because the old ones failed in practice: composition rules produced predictable substitutions, and forced rotation produced predictable sequences. A policy that still enforces the old rules is not stricter than the current guidance. It is out of date, and an investigator comparing it to the current publication will read it that way.
4. The Shared Login Is the Real Violation
In practice the password finding that costs money is not a short password. It is one account used by many people. It fails 164.312(a)(2)(i) outright, and it makes 164.312(b) audit controls useless, because the log shows "frontdesk" opened 400 charts and cannot say who. If a vendor charges per user, that is a budgeting problem, not a compliance exception. Role-based access with individual accounts is covered in the ePHI access control guide, and shutting accounts off when people leave is covered in the termination procedures post.
5. The Proposed Rule Would Add Numbers. It Is Not Law.
HHS published a proposed Security Rule update in the Federal Register on January 6, 2025. It is a proposal; it has not been finalized, OCR is not enforcing it, and the current text quoted above is the law. But it shows where the agency intends to go. The proposed authentication standard at 164.312(f)(2)(i) would require "technical controls that require users to adopt unique passwords that are consistent with the current recommendations of authoritative sources," which points directly at the NIST guidance above. Proposed 164.312(f)(2)(ii) would require multi-factor authentication for access to systems holding ePHI, with narrow exceptions. Proposed 164.312(a)(2)(v) would require controls that "disable or suspend the access of a user" after failed log-in attempts. And the proposed training standard at 164.308(a)(11)(ii)(A) would require training on "safeguarding passwords; setting unique passwords of sufficient strength to ensure the confidentiality, integrity, and availability of electronic protected health information; and limitations on sharing passwords."
Where the proposal stands, and why its timeline slipped, is covered in the Security Rule delay post. The MFA piece specifically is in the MFA and HIPAA guide. A practice that adopts the NIST positions now will not have to rewrite anything if the proposal becomes final; a practice that waits will be rewriting under a deadline.
6. What to Write Into Policy
The password procedure under 164.308(a)(5)(ii)(D) is one page. It states: every user has an individual account on every system that touches ePHI (164.312(a)(2)(i)); minimum length by system, with a stated preference for long passphrases and no composition rules; no scheduled rotation, with mandatory change on suspected compromise, staff departure, or vendor notice; the practice-issued password manager and the rule that work passwords are never reused elsewhere; multifactor authentication on every system that supports it, starting with email, the EHR, and remote access; lockout or throttling settings and who reviews failed-login reports (164.308(a)(5)(ii)(C)); how credentials are issued at onboarding, per the onboarding checklist, and revoked at departure; and the annual training reference under 164.308(a)(5). Date it, have the security official sign it, and keep it six years under 164.316(b)(2)(i).
Two habits round it out. Review the failed-login report on the same schedule as the rest of the activity review, and revisit the procedure whenever a system is added or replaced, because a new EHR or email platform arrives with its own defaults, and the defaults are rarely the ones the policy describes.
That is the whole requirement. Not a magic number, but a set of decisions you can explain to an investigator, backed by the guidance the investigator will be reading too.
---
FAQ
Does HIPAA require passwords to be changed every 90 days?
No. 45 CFR 164.308(a)(5)(ii)(D) sets no interval; it requires procedures for creating, changing, and safeguarding passwords. NIST SP 800-63B-4 says not to require periodic changes and to force a change when there is evidence of compromise.
What is the minimum password length under HIPAA?
HIPAA states none. NIST SP 800-63B-4 sets 15 characters for a password used as a single factor and 8 characters when used with multi-factor authentication, and most reviewers treat NIST as the reasonable-and-appropriate benchmark.
Is password management required or addressable under HIPAA?
Addressable. Under 45 CFR 164.306(d)(3) that means assess it, then implement it or document why not and adopt an equivalent alternative. For passwords the assessment always ends in implementation.
Can staff share a login if the software charges per user?
No. Unique user identification under 45 CFR 164.312(a)(2)(i) is a Required specification, and shared accounts also defeat the audit controls required by 164.312(b).
Will the proposed HIPAA Security Rule set password rules?
The January 2025 proposal would require unique passwords consistent with authoritative recommendations, multi-factor authentication, and lockout after failed attempts. It is proposed, not final, and is not being enforced.
Conclusion
A password procedure is one page, and most of the work is turning on settings that already exist in your EHR and email. One Guy Consulting's Full-Scope plan includes the access control and password policy templates, the device and IT audit that finds the shared logins, and consulting time to get MFA turned on where it counts. Start with a free 30-minute compliance review. No obligation, no pressure.
Sources
- 45 CFR 164.308 (administrative safeguards: password management, log-in monitoring)
- 45 CFR 164.312 (technical safeguards: unique user identification, authentication, audit controls)
- 45 CFR 164.306 (general rules: addressable implementation specifications)
- 45 CFR 164.316 (documentation retention)
- NIST SP 800-63B-4, Digital Identity Guidelines: Authentication and Authenticator Management (July 2025)
- NIST SP 800-63B-4 full text (password verifier requirements)
- HHS, HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information, proposed rule, 90 FR 898 (January 6, 2025)
Related Reading