What HIPAA password requirements actually are
The Security Rule requires procedures for creating, changing and safeguarding passwords, but it sets no minimum length, complexity or change interval. That gap is what usually surprises buyers. The requirement sits in the password management implementation specification under 45 CFR 164.308(a)(5)(ii)(D), which is part of the security awareness and training standard. A customer questionnaire that asks for a HIPAA password rule is therefore asking for your documented procedure, not for a number that the regulation supplies. Expect the reviewer to ask who wrote the procedure, when it was approved, and whether the systems that hold ePHI actually enforce it. The organization owns that password policy and must decide what it requires. An implementation partner can prepare the directory, identity provider and system configurations, plus the evidence that shows those settings are in place. Only an independent assessor can test the control and report on it, and HHS does not recognize any private HIPAA certificate in its place.
The January 2025 proposed revision would change this picture. HHS proposed in 90 FR 898 that covered entities and business associates require multi-factor authentication, but that rule was not final as of October 2026, so today's obligation is still the procedure described above. Do not write a contract or questionnaire answer that presents MFA as a current HIPAA requirement, and do not promise the proposed change as a deadline. Instead, record the pending status and check whether your password procedure already covers MFA for remote and privileged access, since that makes a later change easier to absorb. Confirm the current text and status directly in the eCFR Security Rule text and the proposed rule on the Federal Register before you respond to a buyer.
The practical decision is which external reference your procedure adopts. Most programs point to NIST SP 800-63B, which is a reference HHS lists as informational rather than binding, and they state the adopted settings in their own policy. Ask your team to confirm three things: that the written procedure names the settings and the owner of each, that the evidence (configuration exports, directory policy screenshots, change records) matches the written text, and that a qualified assessor, not your implementation partner, will be the one to report on it. A partner's configuration work can support that evidence, but it does not replace the organization's own accountability or an independent opinion.
How NIST SP 800-63B fills the gap most programs adopt
When a password is the only authentication factor protecting a system, NIST SP 800-63B-4 (section 3.1.1.2) asks for the longest minimum. A password used as a single factor must be at least 15 characters long. The guidance is written for any system that relies on a password alone, so it applies to legacy applications, shared administrative logins and internal tools that have no second factor yet. HIPAA does not set a length for these passwords, so a covered entity or business associate that adopts the NIST minimum is choosing a stronger standard than the rule itself states.
- Minimum length of 15 characters: Passwords used as the sole factor should meet this floor, and the length is counted in characters, not in complexity rules.
- No composition rules: Requirements that force mixed case, digits or symbols are not permitted under the NIST text.
- No periodic forced changes: Passwords should not expire on a fixed schedule.
- Change on evidence of compromise: A password must be changed when there is evidence that it has been exposed.
- Blocklist checks: New passwords should be screened against a list of known-compromised or commonly used values.
Before relying on this standard, confirm with your own risk analysis which systems rely on a password alone, and ask your application vendors whether they can enforce a 15-character minimum and a blocklist check.
When a password is one factor in a multi-factor login, NIST SP 800-63B-4 allows a shorter minimum of 8 characters. The reduced length reflects that the second factor, not the password alone, carries much of the assurance. The same prohibitions on composition rules and forced periodic changes apply, and the blocklist and compromise-change rules still hold. Current HIPAA text does not require MFA at all, but the January 2025 proposed rule would require it, and that proposal was not final as of October 2026 (90 FR 898). Organizations that already use MFA can therefore align their password policy with this tab without waiting for a final rule.
- Minimum length of 8 characters: This applies only where a password is combined with another authenticator.
- Same composition and expiry prohibitions: The 8-character floor does not permit mandatory complexity rules or scheduled resets.
- Compromise triggers a change: Evidence of exposure requires a new password regardless of the MFA layer.
- Blocklist screening still applies: Reused or breached passwords should be rejected at creation.
- Second factor must be verified: A shorter password is only defensible if the second factor is actually enforced for every login path, including remote access and administrative consoles.
Confirm with each identity provider or application that MFA cannot be bypassed for the accounts this tab covers.
Some requirements in the NIST text apply regardless of whether a password is used alone or inside MFA. HIPAA's own password language is procedural: 45 CFR 164.308(a)(5)(ii)(D) calls for procedures for creating, changing and safeguarding passwords, and 45 CFR 164.308(a)(5)(ii)(C) calls for monitoring log-in attempts and reporting discrepancies. NIST's guidance fills in how those procedures can be written. HHS lists NIST special publications, including SP 800-66 Rev. 2, as informational resources that are not legally binding, so covered entities and business associates may adopt them as a reference rather than as a mandate.
- Blocklist screening: Check new passwords against known-compromised values at the point of creation.
- Compromise response: Define how a suspected exposure triggers a forced change and who is notified.
- Login monitoring: Log failed attempts and review them, which is the HIPAA monitoring requirement.
- Unique user IDs: Pair every password with a unique identifier under 45 CFR 164.312(a)(2)(i).
- Documented procedures: Record the adopted standard in written policy so an auditor can compare practice to it.
Ask your auditor or assessor whether they expect the NIST standard to be cited directly in your policy or simply reflected in your procedures.
What to have in place before an OCR review or customer audit
An OCR investigator or customer assessor will not find a password policy in a configuration file. They will look for a written procedure, settings that enforce it, logs that show monitoring and a record that someone reviews access. Each card below is one item to prepare and a way to check it before the review starts.
Written password procedure
The Security Rule's password item under 164.308(a)(5)(ii)(D) asks for procedures covering how passwords are created, changed and safeguarded. Write one procedure that names the authentication factors in use, the minimum length you chose, the blocklist source, the rule for resetting a password after suspected compromise and who approves exceptions. Check that the document matches what the systems actually enforce, because an assessor will compare the two.
Identity provider and blocklist settings
Export the configuration from your identity provider and directory and confirm the password length, blocklist check, lockout threshold and absence of forced periodic changes. Where NIST SP 800-63B-4 is your reference, a single-factor password should be at least 15 characters and a password used inside multi-factor authentication at least 8. Keep the exported settings with a date, because the configuration will change over time.
Log-in monitoring with a reporting path
The rule under 164.308(a)(5)(ii)(C) calls for monitoring log-in attempts and reporting discrepancies. Confirm that failed log-ins, lockouts and unusual sign-ins are written to a log your team reviews, and that a named person receives alerts. Keep a sample of review records showing who looked, what they found and where a discrepancy went, since an assessor will ask for proof of the review, not only the logging.
Unique user IDs and access review
Each person and service account needs its own identifier under 164.312(a)(2)(i), a required specification. Pull a list of accounts from each system and match every one to a named individual or documented service owner. Shared accounts and orphaned accounts for former staff are the findings most likely to appear, so record the date of your last access review and the reviewer's sign-off.
Session timeout settings
Under 164.312(a)(2)(iii), electronic procedures must end a session after a predetermined period of inactivity. The rule does not set that period, so choose one, document the reason and set it in each system that holds ePHI, including workstations, portals and remote access. Test one system by leaving a session idle and recording when it closes. Log the test result as evidence.
Documentation under 164.316
Section 164.316 requires written policies for each Security Rule requirement and documentation kept for six years, made available to the people who need it and updated when something changes. Keep the password procedure, configuration exports, review records and change history together in one location with version dates. A password policy that was updated after an incident but never re-dated will raise questions in an assessment.
Which password approach fits your environment
This table compares three ways to set password controls for ePHI systems: keeping a legacy composition policy, adopting NIST SP 800-63B settings under the current rule, or adopting NIST settings plus multi-factor authentication ahead of the proposed rule. Read each row for when the option fits and what evidence it leaves for an assessor. The main takeaway is that the current rule sets no password rules, so the choice is about your risk and documentation, not a federal test you must pass.
| Approach | When it fits | Evidence it produces |
|---|---|---|
| Legacy composition policy | Existing policy already reflects an internal decision, and changing it needs a formal review first. Expect to document why the composition rules remain reasonable. | Written password policy, the procedure required by 45 CFR 164.308(a)(5)(ii)(D), and records showing the rules were reviewed and approved. |
| NIST SP 800-63B settings under the current rule | Your risk analysis supports longer passwords, blocklist checks and no forced periodic changes, and you want the current rule's password procedures to reflect a recognized reference. | Updated procedure citing NIST SP 800-63B-4, blocklist configuration records, change-on-compromise logs and the risk analysis entry that justified the decision. |
| NIST SP 800-63B settings plus MFA | Systems accept remote access or hold high volumes of ePHI, or you want to align early with the MFA requirement in the January 2025 proposed rule, which is not final. | MFA enrollment and enforcement reports, authentication logs, a documented risk decision for any system without MFA, and the password procedure. |
| Documentation burden | Every option needs a written rationale. Confirm with your counsel and assessor how they will test the chosen settings against your risk analysis. | Policy version history, approval records and an annual review note under 45 CFR 164.316. |
How self-hosted open-source platforms produce password evidence
A self-hosted identity platform can produce much of the password evidence an assessor will ask for, but only if the settings are configured deliberately and the records are exported on a schedule. Keycloak is the example most teams evaluate. In its realm settings, the password policy and brute-force detection options are where a team would look to enforce a blocklist of known-compromised passwords, a lockout threshold after repeated failures and a temporary lockout period. Session idle and maximum lifespan values sit in the realm's session settings. Confirm the exact policy provider names, blocklist support and session parameters against the Keycloak documentation for the version you deploy, because these options change between releases and some are not present in every distribution.
The evidence comes from two places: the configuration itself and the event records it generates. Realm configuration can be exported and kept under version control, so a reviewer can see what the policy was on a given date and who changed it. Login and admin events can be stored and forwarded to a central log platform, which supports the log-in monitoring procedure in 45 CFR 164.308(a)(5)(ii)(C). Ask your identity team to show how failed log-ins are retained, how far back they go, and whether they can be filtered by user ID for a discrepancy review. Also confirm that each user account maps to one unique identifier, since that supports the unique user identification specification in 45 CFR 164.312(a)(2)(i).
The policy document is still the part an assessor reads first. The configuration export shows what the system enforces, but the written procedure must explain why the chosen settings are reasonable and appropriate, how exceptions are approved and how a compromised password is handled. Plan a periodic check in which someone restores the export into a test realm or compares it with the live settings, then records the result. Any gap between the written policy and the running system is the finding most likely to appear in an assessment, so close it before the review rather than explaining it afterward. An implementation partner can prepare the configuration, exports and log routing, but the covered entity or business associate owns the procedure and decides the settings.
Who owns the password policy, the configuration and the proof
The covered entity or business associate owns the password policy and the Security Rule decisions that sit behind it. Under 45 CFR 164.308(a)(5)(ii)(D), the organization must have procedures for creating, changing and safeguarding passwords, and it must make the choices those procedures reflect. Because the current rule sets no length, complexity or rotation numbers, the organization must decide what its policy says, record why, and show that people follow it.
- Policy and procedure: A written password procedure that states which standard the organization follows, such as NIST SP 800-63B, and how exceptions are approved.
- Unique user IDs: Ownership of the required unique name or number for each user under 45 CFR 164.312(a)(2)(i), including rules for shared and service accounts.
- Access reviews: Periodic review of who holds accounts, with removal of leavers and role changes tracked to a named owner.
- Log-in monitoring: Assignment of someone to review failed log-in activity and record how discrepancies were reported and handled.
- Sign-off: Named approval of the password procedure by the security official and senior management, kept as documentation.
Check that every decision in the procedure has a named owner and a dated record, because the assessor will ask for that record first.
An implementation partner such as DeployOpen can configure the systems the organization has chosen to run and prepare the evidence that shows those settings are in place. The partner works inside the client's own infrastructure and under a written scope, but it does not set the policy, approve exceptions or decide what the organization accepts as risk. Its work product is configuration, logging and documentation, not an opinion on compliance.
- Configuration: Setting password rules, lockout thresholds and blocklist checks in the directory or identity platform the organization already uses, as agreed in scope.
- Logging setup: Sending authentication events to a central log store so failed log-ins can be monitored and reported.
- Session settings: Configuring automatic log-off after inactivity, where the chosen time is set by the organization under 45 CFR 164.312(a)(2)(iii).
- Evidence packs: Exported configuration files, screenshots, log samples and change records, each labeled with the date and the control it supports.
- Handover: Written runbooks so the client's staff can operate and re-verify the settings after the engagement ends.
Check that the scope names each system, each setting and each evidence item, and that the organization keeps ownership of the final configuration.
An independent assessor tests the password controls and reports on what it found. HHS states that no Security Rule standard requires certification, and that HHS does not endorse private certifications, so the assessor's report is an opinion about specific tests, not a HIPAA certificate. Only an independent auditor or assessor issues reports, and DeployOpen does not issue audit reports or certifications.
- Test design: Sampling of accounts, reviewing the password procedure against the organization's own stated standard, and checking whether log-in failures are actually reviewed.
- Technical testing: Attempting weak or blocklisted passwords and confirming lockout and session timeout behave as documented.
- Evidence review: Examining the evidence packs and sign-off records for completeness and dates.
- Findings: A written list of exceptions, with the organization's responses and remediation dates.
- Limits: A clear statement of what the test covered and did not cover, which the organization should keep with any claims it makes to customers.
Check that the assessor's engagement letter defines the scope, and that no one describes the result as a HIPAA certification.
Questions buyers ask about HIPAA password rules
Is there a HIPAA password length rule?
No. The Security Rule does not set a minimum password length, complexity or change interval. It requires covered entities and business associates to have procedures for creating, changing and safeguarding passwords under 45 CFR 164.308(a)(5)(ii)(D), and leaves the specifics to a risk-based decision. Many programs adopt NIST SP 800-63B-4 as the reference. That guidance calls for at least 15 characters for a password used as a single factor and at least 8 characters when it sits inside multi-factor authentication, plus a blocklist check for new passwords. Confirm the values your auditor or customer expects before you write them into policy, because contracts sometimes set stricter numbers than the rule does.
Can we keep a 90-day password rotation policy?
The rule does not require rotation, and it does not forbid it. The practical question is whether a fixed 90-day cycle reduces risk in your environment or mainly produces weaker, predictable passwords. NIST SP 800-63B-4 forbids periodic forced changes and instead requires a change when there is evidence of compromise. If you keep rotation, document why it is reasonable for your risk analysis and keep the procedure consistent with your other safeguards. Ask your security official and any customer that imposes the rule whether they expect rotation, because a contract can set requirements the Security Rule does not.
Is there a HIPAA password certification?
No. HIPAA has no certification. HHS states that no Security Rule standard requires an entity to certify compliance, that it does not endorse or recognize private certifications, and that such certifications do not prevent HHS from later finding a violation. A third-party assessment can test whether your password procedures exist, are followed and are documented, and it can produce a report for a customer. That report describes what was tested and does not make you HIPAA certified. Only the assessor issues the report, and the covered entity or business associate still owns the control.
How long does a password policy change take to implement?
The duration depends on what the change touches. Updating the written policy and procedure is usually the fastest step. Enforcing a new rule in identity systems, directory services, applications, medical devices and vendor portals takes longer, because each system has its own settings and some cannot enforce the rule at all. Inventory every system that authenticates to ePHI first. HHS has not published a standard implementation duration for this change, so ask your implementation partner for a timeline built from that inventory in the written scope before work starts.
What does a password change need from our staff?
Staff time goes to four areas: reviewing the current policy and the list of systems, agreeing the rules with your security official and legal team, communicating the change to users, and running the training required under the Security Rule's security awareness and training standard, which includes password management. Help desks need scripts for resets and lockouts, and system owners must confirm which settings they can change. Expect the heaviest load on the people who own legacy applications and third-party systems, because those changes often need vendor action. Ask any partner to list each role, the hours it expects from each, and the handoff points in its quote.
Can our own IT team change the password settings?
Often, yes, for systems your team already administers, such as directory services and in-house applications. Your team owns the control either way, and the question is capacity and skills. Confirm three things before deciding: whether each system can enforce the required settings, whether the change needs testing against clinical or billing workflows, and who will document the procedure and keep the evidence current. An implementation partner can prepare systems, configuration baselines, documentation and evidence for your team to run, but it cannot issue an audit report. A fixed-scope written engagement makes the split of work explicit.
What the proposed rule could change for passwords and MFA
HHS proposed a major revision of the Security Rule on January 6, 2025 (90 FR 898, RIN 0945-AA22), and the proposal would require multi-factor authentication for systems that hold ePHI. That requirement is the most consequential change for password programs, because it would move MFA from a question of reasonable judgment to a stated obligation. As of October 2026, no final rule has been published. The Unified Agenda entry lists the rule under Long-Term Actions with final action projected for July 2027. Those dates can move, and the final text may differ from the proposal in scope, exceptions or implementation periods.
Plan for MFA without assuming the final wording. Start by inventorying every system that stores, processes or transmits ePHI and recording which of them already enforce MFA for workforce users, administrators, remote access and vendor access. Confirm with counsel and your compliance lead how your organization would document an MFA gap today under the current rule, which does not mention MFA directly. Then check whether your identity provider, VPN, EHR and cloud consoles support MFA methods that can be enforced centrally and logged, since retrofitting that across many systems is usually the slow part of any change.
Read the proposed text yourself rather than relying on summaries, and track the Federal Register and the Unified Agenda entry for changes. Ask any vendor or implementation partner how their proposed design would change if the final rule requires MFA for particular access paths, and ask for that in writing. Where a design choice is still open, prefer an approach that a stricter rule would not force you to rebuild, such as central identity management and enforced policy rather than per-application settings. Treat the password requirements you adopt now as a baseline, and record the decisions you make so the evidence trail holds up whichever version of the rule is finalized.
How DeployOpen works on this
DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside your own infrastructure, including the password, log-in and session settings that the Security Rule's technical safeguards touch. We prepare the systems and evidence; the organization owns its policies and decisions, and only an independent assessor can test them and report on them.
How we scope
- We list every system that stores or authenticates users to ePHI, including directories, applications, admin consoles and remote access paths.
- We agree in writing which password, log-in monitoring, unique user ID and session timeout settings the engagement will cover.
- We confirm with your compliance lead which NIST SP 800-63B-4 choices you adopt, since the Security Rule does not set them.
How we build
- We configure password policy, blocklist checks, lockout and log-in monitoring on each in-scope platform, using your chosen standard as the baseline.
- We enforce unique user identifiers and remove shared or generic accounts from in-scope systems during the build.
- We set inactivity session termination to the value your organization approves, documenting the chosen interval and the reason for it.
How we hand over
- We deliver configuration records, test results and screenshots that show each password and log-in setting as it runs.
- We provide a written procedure for creating, changing and safeguarding passwords, drafted for your review and approval.
- We document the addressable decisions, including any equivalent alternative measure, so your assessor can trace each choice.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, so settings stay aligned after platform changes.
- We can re-run configuration checks and log-in monitoring reviews on a schedule agreed in the written scope.
- Any future change to the Security Rule, including the proposed rule, is handled as a new written scope rather than an open-ended task.
