164.308(a)(5)(ii)(D) Password management requirements

HIPAA password management: what 164.308(a)(5)(ii)(D) asks for

When an assessor or OCR asks how passwords are managed for systems holding ePHI, the answer starts with a fact many teams miss: 164.308(a)(5)(ii)(D) is an addressable specification, and the current text sets no minimum length, complexity or change interval. Under 45 CFR 164.304, a password is confidential authentication information composed of a string of characters. The rule asks for procedures for creating, changing and safeguarding passwords. Your risk analysis decides how strict those procedures must be, and you must document the reasoning. Under the addressable approach in 164.306(d)(3), if a measure is not reasonable and appropriate, you document why and implement an equivalent alternative. Confirm your current policy text against the eCFR entry for 164.308 before you cite any specific setting to an assessor.

The risk this specification addresses is straightforward: guessed, reused or shared credentials that let someone reach ePHI as a legitimate user. The difficulty is scope. Passwords for a clinic or hospital span workforce logins, administrator accounts, service accounts that connect applications, database credentials, and secrets embedded in build pipelines and scripts. A password policy written for staff email rarely covers a service account that has not changed in years. Start with an inventory of every system and non-human account that touches ePHI, then record how each credential is created, rotated, stored and retired. Automated tools can help find exposed secrets in code repositories, but an inventory still has to come from your own environment.

The 2025 proposed Security Rule revision (90 FR 898) would require multi-factor authentication for ePHI access, which would change how passwords function as a single factor. That proposal was not final as of October 2026, so the current rule still governs. Plan for the change anyway: ask your identity and access vendors which multi-factor methods they support, and review which systems still depend on passwords alone. Document today's decision and the risk reasoning behind it, so you can show how your approach evolved if the final rule changes the requirement.

Which password management scope applies to your ePHI systems

The password procedures in 164.308(a)(5)(ii)(D) reach every credential that can open, administer or move ePHI, not only the logins staff type each morning. Work through the card list below to see which parts of your environment fall in scope and which scoping decisions change the effort.

Workforce logins to EHR and billing

Clinical, billing and front-desk staff sign in to the systems where most ePHI is viewed and changed. Your password procedures should state how passwords are created, how they are changed after a reset or suspected exposure, and how users protect them from sharing. Check whether these systems accept single sign-on, because that moves much of the procedure to the identity provider. The current rule sets no length, complexity or rotation interval, so record the choice your risk analysis supports.

Administrator and break-glass accounts

Privileged and emergency accounts can disable logging, export records or override access controls, so a weak password here affects every other safeguard. List each administrator account, each break-glass account kept for outages, and who knows the credential. Your procedure should say where emergency passwords are stored, who may retrieve them, and how a retrieval is recorded. Treat these accounts as the first place to confirm the procedure works in practice.

Service accounts and database credentials

Applications use service accounts to reach databases, file stores and interfaces that hold ePHI. These credentials are often embedded in configuration files, rarely rotated and shared across several systems. Confirm which service accounts can read ePHI, who owns each one, and whether the application can accept a changed credential without an outage. Documenting ownership usually matters more than choosing an interval.

API keys and secrets in CI/CD pipelines

Build pipelines and deployment jobs often hold tokens that reach production systems, and a secret committed to a repository can expose ePHI systems without any user login. Your procedure should cover how secrets are injected at run time, who can read them, and how exposed values are revoked. Scan repositories and pipeline output for committed secrets, and confirm that every scanner finding leads to a documented revocation.

Shared accounts and identity provider coverage

Shared logins on workstations, kiosks or legacy applications make it impossible to tie an action to a person, which weakens both password controls and the audit trail. Identify every shared account and decide whether to retire it, move it behind individual sign-in or document a compensating control. Also check whether a central identity provider already handles sign-in for most applications, since that changes where password rules are enforced.

Business associate and vendor access

Vendors that support your EHR, billing or hosting may hold their own accounts on your systems, and their staff's password habits fall outside your workforce training. Establish which business associates hold credentials, whether the contract requires them to follow equivalent password procedures, and how their access is removed when the engagement ends. Ask each vendor to confirm how it protects the credentials it holds for you.

How an assessor tests password management

This table compares five assessor test approaches for 164.308(a)(5)(ii)(D), the evidence each one asks for, and the findings that most often come up. Read it as a checklist of what to prepare before an OCR review or a third-party assessment, because the current rule sets no length or rotation number, so the assessor tests whether your documented decision is reasoned and followed. No certification replaces this evidence.

Test approach	Evidence requested	Common findings
Written password procedure exists and matches the risk analysis	Current password procedure, version history, and the risk analysis section that addresses authentication	Procedure written but never approved, or procedure states rules the risk analysis never considered
Risk analysis records why length, complexity and change rules were chosen	Risk analysis entries for authentication, rationale for each rule, and any equivalent alternative measure documented under 164.306(d)(3)	No rationale recorded, or an alternative such as multi-factor authentication claimed without a documented decision
Sampling accounts to confirm the procedure is enforced	Directory or identity provider configuration exports, sample account settings, and exceptions list with approvals	Policy says one thing, while directory settings allow weaker passwords, or exceptions are never approved or reviewed
Review of shared and service credential storage and rotation	Inventory of shared and service accounts, secrets manager configuration, rotation logs, and secret scanning reports	Shared passwords kept in spreadsheets or chat, service credentials that never rotate, or secrets committed to code repositories
Check that workforce members were trained on password safeguarding	Training content covering password safeguarding, attendance or completion records, and security reminder notices	Training delivered once at hire with no refresh, or no record showing who completed it
Confirm the procedure is reviewed when the environment changes	Review dates, change records for identity systems, and minutes or sign-offs from the security official	Procedure unchanged after a system migration, merger, or a credential-related incident

How to implement password management in six steps

This sequence turns the addressable password management specification into a documented decision, enforced sign-in procedures and managed secrets that an assessor can trace from risk analysis to configuration. Each step produces a record you can show an auditor or OCR investigator.

Inventory every credential type touching ePHI
Security, IT and application owners list every place where a password, passphrase, key or token is used to reach ePHI. Include workforce logins to EHR and email, administrator accounts, database and API credentials, service accounts, CI/CD pipeline variables and vendor portal access. For each entry, record the owner, the system, and whether the credential is human-used or machine-used. You know this step is done when every ePHI system appears with at least one credential type, and the list is reviewed by someone outside the team that maintains the system.
Record password measures and reasoning in the risk analysis
The security official documents, for each credential type, the password measures chosen, such as length, composition, change triggers, lockout, or use of multi-factor authentication or managed secrets. Because 164.308(a)(5)(ii)(D) is addressable, the record must state whether the procedure is reasonable and appropriate, and if a specific measure is not adopted, why not and what equivalent alternative is used. The current rule sets no length or rotation interval, so the reasoning rests on the identified threats and the sensitivity of the ePHI. Done when each entry links to a risk and a decision, and the reasoning is signed off by the security official.
Write the creation, change and safeguarding procedure
Write the procedure that staff and administrators follow to create, change and protect passwords. Cover how initial passwords are issued and how users must change them, how reset requests are verified, what storage is prohibited (for example, sticky notes, shared spreadsheets, or source code), and how suspected compromise is reported. Tie each rule back to a line in the risk analysis. The procedure is complete when a workforce member can follow it without asking questions, and when the document has an owner, a version and an approval date.
Configure the identity provider to enforce the procedure
Engineers configure the identity provider and directory so that sign-in behavior matches the written procedure. For example, an identity provider such as authentik can act as the sign-in source for applications through OAuth2, OpenID Connect, SAML, LDAP, RADIUS or proxy providers, so applications delegate authentication rather than storing their own passwords. FreeIPA can supply single sign-on for Linux and UNIX environments through an MIT Kerberos KDC. Confirm with each vendor which password policy, lockout and multi-factor options the chosen version supports. Done when a test account is shown to meet the policy and a failed-login test produces a log entry.
Move service and pipeline secrets into a managed store
Service accounts, database credentials and API keys should not live in configuration files or code. Store them in a managed secrets platform such as OpenBao, which encrypts secrets in one place, can generate dynamic short-lived credentials for systems such as databases, attaches leases that revoke secrets on expiry, and can revoke single secrets or whole trees of credentials. Use GitLab pipeline secret detection to scan committed code for exposed secrets, and review the gl-secret-detection-report.json artifact after each run. Confirm the revocation and rotation behavior of your chosen versions in their documentation. Done when a scan finds no hard-coded ePHI system credentials and a revocation test succeeds.
Set a review cycle for the password decision
Schedule a recurring review of the password measures, the procedure and the configurations, and trigger an out-of-cycle review after significant system changes, new vendors, incidents, or changes in threat information. The review re-runs the inventory, checks that the identity provider and secrets store still enforce the documented rules, and updates the risk analysis if a credential type has been added or retired. The evaluation standard in 164.308(a)(8) is the natural anchor for this review. Done when the review produces a dated record, identifies any gaps, and assigns owners and follow-up actions in the risk management plan.

Which open-source tools support password evidence

OpenBao is a secrets manager released under the MPL-2.0 license. It keeps secrets such as database passwords and API keys encrypted in one place, so teams stop sharing credentials through spreadsheets, chat or configuration files. Its more useful feature for password procedures is dynamic credentials: instead of a long-lived shared password, an application or person receives a short-lived credential for a system such as a database, and that credential expires on its own.

Encrypted central storage: Records where secrets live and who may read them, which supports your procedure for safeguarding passwords.
Dynamic short-lived database credentials: Generated on request, so there is no standing password to rotate by hand for those systems.
Leases: Each dynamic secret carries a lease that revokes it automatically at expiry, and the lease history can be used as evidence of change control.
Targeted revocation: Single secrets or whole trees of credentials can be revoked, which supports incident response when a credential is suspected to be exposed.
License note: MPL-2.0 is a file-level copyleft license. Have counsel confirm how it applies to your modifications and distribution.

What it does not prove on its own: OpenBao does not set your minimum length or complexity rules for human passwords, and it cannot show that applications outside its integrations keep passwords out of code. Confirm the supported secret engines and audit device options against current OpenBao documentation before relying on them.

Password management evidence that passes an audit

The password specification is addressable, so an assessor will look for a documented decision, a written procedure and records showing the procedure is enforced. The six artifacts below connect those layers, and each one should be exported or versioned on a schedule so it is current when an assessor asks.

Approved password procedure

The written procedure sets how workforce members create, change and safeguard passwords, and who approves it. Keep each version with its approval date, the approver's name and role, and a record of the last review. Check that the procedure matches what the identity provider actually enforces, because a mismatch is one of the first gaps an assessor finds. Store the document under version control so the history is visible.

Risk analysis entries for passwords

Under 164.306(d), the entity must decide whether a password measure is reasonable and appropriate. Record that decision in the risk analysis, including the threats considered and the reasoning. If the entity declines a measure, the entry must document why and name the equivalent alternative measure. Revisit the entry when the environment changes, such as a new remote access path or a new identity provider.

Identity provider configuration exports

Applications that delegate sign-in to an identity provider, such as authentik through its OAuth2, OpenID Connect, SAML, LDAP or proxy providers, inherit that provider's password and session settings. Export the policy configuration on a schedule and store it with a change record for each edit. Confirm which applications authenticate through the provider, since any application with a local password store sits outside those settings.

Access reviews and account listings

Sample account listings from directories such as FreeIPA, and from each application, show whether the procedure is applied in practice. Look for accounts with no owner, shared accounts, and accounts that still exist after a departure. Pair each listing with the review sign-off and the actions taken. Ask your team to confirm which directory is authoritative, because two sources that disagree will weaken the evidence.

Secret store audit and revocation logs

A secret store such as OpenBao keeps secrets encrypted in one place, issues dynamic short-lived credentials, and attaches leases that revoke secrets on expiry. Keep the audit log of secret reads and writes, and the lease and revocation records showing that credentials ended when expected. These records show that stored credentials are safeguarded, not only that a policy exists. Confirm the retention period for these logs in your own environment.

Pipeline secret detection reports

Pipeline secret detection in GitLab Community Edition scans committed and pushed files during a CI/CD job and writes findings to a gl-secret-detection-report.json artifact. Retain these reports, and link each finding to a remediation ticket that records the rotation or removal of the exposed credential. A report with open findings and no tickets is weak evidence, so review the reports on a set cadence and keep the review record.

What meeting password management costs in money and effort

This table breaks down the cost components of meeting the password management specification, who is paid for each, whether it is one-time or recurring, and what drives it up or down. Use it to scope a quote, since no DeployOpen price is implied and every figure depends on your own environment and written scope. The main takeaway is that open-source licenses remove the license fee, but hosting, identity integration and ongoing evidence work still carry real effort and cost.

Cost component	One-time or recurring	What drives it	How to keep it down
Password policy and risk analysis writing	One-time, then annual review	Number of systems in scope, how many account types exist, and how much the risk analysis must justify each password decision	Reuse a single policy template, tie password rules to the existing risk analysis, and review on a fixed cycle instead of ad hoc
Identity provider and directory setup	One-time setup, recurring hosting and administration	Choice of directory and sign-on service, number of user populations, and whether MFA or single sign-on is added	Standardize on one identity source and confirm the platform fits your hosting model before scoping
Per-application integration	One-time per application, plus updates when apps change	Protocol support in each application (OIDC, SAML, LDAP or proxy), custom code, and vendor-hosted apps that cannot be changed	Inventory applications first, group them by integration method, and retire or consolidate legacy apps
Engineering time to move service and pipeline secrets into a managed store	One-time migration, then recurring rotation and onboarding work	Count of hard-coded credentials, number of pipelines and databases, and how many teams own them	Run secret scanning to find exposed credentials, migrate highest-risk systems first, and use dynamic short-lived credentials where supported
License spend for named open-source tools	No license fee to the adopter under the stated licenses; recurring hosting and staff time still apply	Hosting footprint, high availability design, support contracts if you buy them, and internal staff hours	Confirm each license with the project, size hosting to actual load, and budget for staff rather than assuming zero cost
Ongoing evidence upkeep	Recurring	Log retention, frequency of access reviews, number of evidence artifacts such as scan reports and rotation records	Automate report generation and store evidence in one location tied to the risk analysis
External review or penetration testing, if commissioned	Recurring when commissioned, scope-dependent	Scope of authentication testing, number of applications tested, and retest rounds after remediation	Limit scope to password and authentication paths, and agree deliverables in writing before testing starts
Auditor or assessor sampling	Recurring per assessment	Number of samples the assessor selects, how complete your evidence is, and how many findings require follow-up	Keep evidence organized by control and confirm with the assessor which artifacts they will request

Who owns password management and who can help

Your organization owns the password procedure, and the Security Rule treats this as a decision you must make and document. Because 164.308(a)(5)(ii)(D) is addressable, you first assess whether a password procedure is reasonable and appropriate for each system holding ePHI, then implement it or document why not and adopt an equivalent measure. The current rule sets no minimum length, complexity or rotation interval, so your risk analysis and risk management plan determine those settings. Your team also decides who may approve access and how staff are trained to protect credentials.

Procedure ownership: a named owner maintains the written password procedure and its review dates.
Risk-based settings: length, reuse rules, lockout and change triggers are set from your risk analysis, not copied from a template.
Access approvals: managers or the security official approve who receives credentials and at what level.
Workforce training: staff learn how to create, store and report compromised passwords.
Documentation of decisions: record why each addressable choice was made and what alternative measure applies.

Check that your written procedure names an owner, cites your latest risk analysis and states how exceptions are approved.

Where password management usually falls short

Password management under 164.308(a)(5)(ii)(D) is addressable, so the gaps usually sit in the reasoning around the procedure rather than in the procedure itself. The six gaps below share one root cause: a decision was made or a control was described, but nobody kept the link to the risk analysis or the records that prove it works.

Procedure not tied to the risk analysis

A password policy copied from a template often sets rules that nobody measured against the organization's own ePHI exposure. Because the Security Rule sets no minimum length, complexity or change interval, the risk analysis is the only place those choices can be justified. Check that each password rule traces to a named risk entry, with the threat, the affected systems and the reason the chosen rule reduces it.

Addressable decisions without documented reasoning

Under 45 CFR 164.306(d)(3), an addressable specification requires a documented decision: implement it if reasonable and appropriate, or record why not and adopt an equivalent alternative. Teams often skip the second half, so a password rule is dropped or weakened with no written rationale. Ask for a dated decision record for each password choice, naming who approved it and what alternative measure replaced it.

Shared and service passwords in plain storage

Shared administrator accounts, service accounts and vendor logins frequently live in spreadsheets, wiki pages, chat threads or configuration files. These credentials rarely have an owner, a rotation record or a revocation path when someone leaves. Inventory every shared credential, move it into a secrets store with access logging, and assign a named owner for each one.

Local accounts outside the identity provider

Applications that keep their own user tables create password stores the central identity team never sees. Those stores miss enforcement of the organization's password procedure, lockout settings and offboarding steps. Identify every application with local logins, then check whether it can delegate sign-in to a central identity provider such as authentik through OIDC, SAML or LDAP, and list the exceptions that remain.

Detected secrets left unremediated

Secret scanning in a CI/CD pipeline can flag credentials committed to source repositories, but a report that nobody triages protects nothing. Exposed passwords should be rotated, removed from history where practical and recorded as incidents when ePHI systems are involved. Confirm who reads the secret detection report, how long findings stay open and how each finding is closed.

Procedure exists but nothing proves it

A password policy document shows that a procedure was written, not that anyone followed it. Assessors look for evidence of operation: configuration exports, authentication logs, rotation or vault records, exception approvals and training acknowledgments. Before an assessment, pick three password controls and confirm that each one has a recent artifact an outside reviewer could sample.

Common questions about 164.308(a)(5)(ii)(D) password management

Does HIPAA set a password length or password change interval?

No. The current Security Rule text sets no minimum password length, no complexity rule and no required change interval for 164.308(a)(5)(ii)(D). The standard only calls for procedures for creating, changing and safeguarding passwords. The risk analysis decides how strong those procedures must be, so the answer for your organization comes from the threats to your ePHI systems and the controls you chose to address them. Document the reasoning, because an assessor will ask how the chosen length, rotation and storage rules follow from the risk analysis.

Is password management required or addressable under HIPAA?

It is addressable, which means it is not optional. You must assess whether the specification is reasonable and appropriate for your environment. If it is, you implement it. If it is not, you document why and implement an equivalent alternative measure, provided that alternative is reasonable and appropriate. Under 45 CFR 164.306(d)(3), the documentation of that decision is the evidence. A written decision that says a password rule was not needed, with no alternative and no reasoning, is the weakest position to defend in an OCR review.

How much effort does password management take, and what drives it?

The effort depends mostly on how many systems hold or reach ePHI, how many of them authenticate users with their own local passwords, and how much of the environment already uses a central identity provider. Costs fall into one-time work, such as writing the procedures, inventorying accounts and moving applications to central sign-in, and recurring work, such as reviewing the procedures, rotating service secrets and reviewing exceptions. Ask any consultant or implementation partner for a written scope listing the systems in scope, the deliverables and the evidence they will produce before accepting a figure.

Can a small organization handle password management in-house?

Often yes, provided someone owns the procedures and the evidence. A small practice with a few cloud applications can usually write a password standard, enforce it through its existing identity service and keep a record of the decisions. The work becomes harder when many systems keep separate local accounts, when service credentials sit in scripts or configuration files, or when no one tracks who holds which access. Organizations that lack this capacity can outsource the drafting, the configuration work or the evidence preparation, but the organization still owns the risk decision and the procedures.

What does password management need from staff?

It needs authorization and training records, not just technical settings. Access approvals show who may create or reset credentials for which systems. Training records show that the workforce received instruction on creating, changing and protecting passwords, as 164.308(a)(5) requires for the broader program. Staff should also know how to report a suspected compromised password. Keep these records with the procedures and the risk analysis so an assessor can trace each rule back to a decision.

Does a HIPAA certification prove password management compliance?

No. HHS states that no Security Rule standard requires an entity to certify compliance, that HHS does not endorse or recognize private certifications, and that a certification does not stop HHS from later finding a violation. A vendor's badge or a third-party report can support your evidence, but it does not replace your own risk analysis, your documented password procedures or the records that show they operate. Treat any claim of HIPAA certification with skepticism and ask for the scope and the assessor's findings instead.

How would the proposed multi-factor authentication rule change password management?

The January 2025 proposed rule would require multi-factor authentication for access to ePHI, which would add a second factor on top of passwords rather than replace the password procedures. It was not final as of October 2026, so the current text still governs. Read the proposal in the Federal Register and the latest Unified Agenda entry before planning, because final wording may differ. If finalized as proposed, your password procedures would still need to exist and be documented, and the identity layer would need to enforce the second factor for ePHI systems.

How DeployOpen works on this

DeployOpen plans and implements self-hosted open-source platforms inside your own infrastructure, so the password management procedures, credential tooling and records behind 164.308(a)(5)(ii)(D) can be set up and documented in your environment. We prepare the systems and evidence; your organization owns the policy, the risk analysis decision and the workforce obligations.

How we scope

The written scope lists which systems, identity sources and workforce groups the password procedures will cover.
We confirm with you which password decisions your risk analysis has made, including length, complexity and change rules.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.

How we build

We configure a secrets store such as OpenBao so shared and system credentials are kept encrypted in one place.
We set up identity sign-in through authentik or FreeIPA so applications delegate authentication rather than storing their own passwords.
We enable secret detection in the CI/CD pipeline so committed credentials are found and written to a report artifact.

How we hand over

You receive written procedures for creating, changing and safeguarding passwords, mapped to your risk analysis decisions.
You receive configuration records, test results and sample reports showing how credentials are issued, rotated and revoked.
Your security official and auditors receive an evidence index explaining where each artifact is kept and how often it is reviewed.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
We can review password procedures when the risk analysis changes or when the HHS proposed rule is finalized.
Independent assessors, not DeployOpen, decide whether the evidence meets your obligations under the Security Rule.