A password and authentication policy aligned to §164.312(d) and current NIST guidance, not 2003 complexity folklore.
What is in the download
- Format: DOCX
- Length: 4 page(s) / file(s)
- Includes: rule citations, fill-in guidance in the margin, and a completed example
- Licence: free to modify and use commercially
What is in the template
§164.312(d) requires you to verify that a person seeking access to ePHI is who they claim to be, and password management appears among the Security Rule’s training specifications — but the rule, written before smartphones, names no lengths, rotations, or character classes. That silence is a feature: it lets you write a policy aligned to current NIST guidance instead of the folklore that hardened into corporate defaults twenty years ago. The template’s sections: password standards — length over complexity, a screen against known-breached and trivially guessable passwords, and no forced periodic rotation without evidence of compromise, with rotation on suspicion instead; multi-factor authentication — required for anything internet-reachable that touches ePHI, with the acceptable factor types listed and SMS flagged as the floor rather than the preference; password manager expectations, because a policy that demands unique strong passwords without providing a manager is demanding reuse; service accounts and API keys — the non-human credentials most password policies forget; shared-credential prohibition, cross-referencing unique user identification under §164.312(a); and the reset and recovery procedure, which is where attackers actually go when the front door is strong.
How to use it
- Read it end to end before filling anything in.
- Delete every clause describing a control you do not have. An untrue policy is evidence against you.
- Assign an owner and a review date to each section.
- Publish it, collect acknowledgements against the version number, and retain both for six years.
The classic step-two violation in this document category: a policy mandating 90-day rotation that no system enforces, or an MFA requirement your legacy EHR cannot meet. Write what is enforced; put the rest in the remediation plan with a date.
How to customise it
Start from your identity provider’s actual configuration and make the policy describe it — then tighten the configuration where it falls short of the template’s defaults, rather than weakening the words. Decide the MFA boundary deliberately: “everything behind SSO” is clean if your SSO coverage is genuinely complete; list the exceptions honestly if it is not, each with an owner and an end date. Name your approved password manager and state whether it is mandatory for workforce credentials. For service accounts, assign each one an owner and a rotation trigger (on personnel departure at minimum). And align the legacy-systems section with reality — older clinical systems with eight-character limits exist, and the defensible move is documenting the compensating controls around them, not pretending the policy applies uniformly.
Common mistakes
- Keeping 2003 rules because they feel strict. Forced 90-day rotation produces
Winter2026!and sticky notes. Current guidance trades rotation theatre for length, breach-screening, and MFA — and your policy citing that guidance reads as more competent, not less. - MFA on the perimeter only. SSO with MFA in front, and direct database credentials or legacy VPN accounts behind it without, is a policy that protects the login page rather than the data.
- Forgetting non-human credentials. The API key in a repository and the service account with a five-year-old password are the highest-privilege identities you have and the least governed.
- Recovery weaker than login. A help desk that resets passwords on a friendly phone call has replaced your MFA with social engineering. Define identity verification for resets.
- No enforcement check. The annual review should sample the configuration against the policy; drift between them is the most common technical-safeguard finding.
Related templates
This policy is one leg of the identity stack: the access control policy decides who gets accounts, this one secures the credentials, and the encryption policy protects the data behind them. The BYOD and remote work policies extend the rules to the devices where credentials live, and the technical safeguards guide covers the §164.312(d) context in full.
The honest limitation
A template is a starting point, not a program. It cannot record who acknowledged it, prove it was followed, or update itself when your environment changes. Those three things are what the platform does, and they are the difference between having documents and having compliance.
Start where you are
Take the free readiness assessment — 24 questions, about eight minutes, no call required. You get a scored report identifying which required specifications you are missing and what to fix first. If it turns out you are further along than you thought, we will tell you that too.