Does HIPAA Require MFA? What the Security Rule Actually Says

The Security Rule does not name MFA

The HIPAA Security Rule was published as a final rule on February 20, 2003, with a compliance date of April 20, 2005 for most covered entities. The technical authentication standard at 45 CFR 164.312(d)) requires a covered entity to implement procedures to verify that a person or entity seeking access to electronic protected health information is the one claimed. The standard itself is required (not addressable), but the rule does not specify how — it does not require passwords, MFA, smart cards, or biometrics.

The Security Rule is intentionally technology-neutral on this question. The risk analysis at 164.308(a)(1)(ii)(A)(1)(ii)(A)) drives the choice of authentication mechanism. If the risk analysis concludes single-factor passwords are not reasonable and appropriate given current threats, the practice has to implement something stronger.

What HHS guidance says

The HHS Office for Civil Rights publishes its Cybersecurity Newsletter covering recurring topics. Several newsletters explicitly recommend MFA in the context of phishing, ransomware, and remote access. The agency's Cybersecurity guidance hub and the 405(d) Health Industry Cybersecurity Practices (HICP) document — published by the HHS 405(d) program — recommend MFA as a baseline practice for any system holding ePHI accessed remotely.

The 405(d) Health Industry Cybersecurity Practices: Managing Threats and Protecting Patients document explicitly identifies MFA among its top-tier practices for small organizations.

NIST SP 800-66 r2 is more direct

NIST SP 800-66 Revision 2, the 2024 update to the HIPAA Security Rule cybersecurity resource guide, walks through authentication and points to NIST SP 800-63B for the authoritative federal authentication framework. SP 800-63B defines three Authenticator Assurance Levels: AAL1 (single or multi-factor with relaxed assurance), AAL2 (two-factor required), and AAL3 (multi-factor with one factor a hardware-based cryptographic authenticator). OMB and federal-agency guidance built on SP 800-63B requires at least AAL2 when personal information is made available online — the practical baseline that healthcare practices following NIST conventions would adopt for ePHI exposure.

A risk analysis that follows the NIST framework will almost always conclude MFA is reasonable and appropriate for systems holding ePHI, particularly for:

• Remote access to the EHR or practice management
• Email systems holding PHI
• Cloud platforms accessed over the public internet
• VPN access into the practice network
• Privileged administrator accounts
• Access from personal or unmanaged devices

The proposed Security Rule update would change this

HHS published a notice of proposed rulemaking in 2024-2025 that would update the Security Rule. The proposal, available through the OCR HIPAA Regulatory Initiatives page, would make multi-factor authentication an explicit requirement for many systems holding ePHI rather than an inferred best practice. The proposal would also strengthen documentation expectations and tighten encryption requirements.

As of the last review date on this article the proposed rule is not final. The current Security Rule controls. Practices should track the rulemaking and plan as though MFA will become a named requirement.

Practical MFA deployment for a small practice

MFA does not need to be elaborate. The defensible patterns for a small practice:

• EHR and practice management: enable the vendor's built-in MFA for all users. Almost every modern EHR supports SMS, TOTP authenticator app, or push notification.
• Email: enable MFA at the identity provider (Microsoft 365 or Google Workspace), with TOTP or app-based prompts as the second factor. SMS is acceptable but weaker; phishing-resistant FIDO2 or WebAuthn is stronger.
• VPN: enforce MFA on any VPN or remote-desktop entry point.
• Cloud storage and document portals: enable MFA at the SSO layer.
• Admin accounts: phishing-resistant MFA where supported (security keys).
• Service and shared accounts: minimize, document the few that exist, restrict their use to read-only or operational tasks, and rotate credentials when staff change.

What MFA does not solve

MFA reduces credential-stuffing and phishing risk substantially but does not eliminate it. A determined phishing campaign can still bypass MFA with prompt-bombing, session-cookie theft, or social engineering. The Security Rule's broader program — training, audit log review, incident response, sanction policy — addresses what MFA does not.

Documenting the decision

The risk analysis should record:

• Which systems require MFA
• The authentication factors used (TOTP, push, FIDO2, SMS)
• Coverage gaps and the remediation plan
• For any system without MFA, the compensating control chosen instead and the reasoning. Authentication itself is a required standard at 164.312(d)); the specific mechanism is left to the practice under the Security Rule's flexibility provision at 164.306(b)), driven by the risk analysis findings.
• Date of last verification

A practice that has MFA on every ePHI-bearing system and documents the decision is ahead of the proposed rule and aligned with NIST guidance under the current rule.

Restraint about claims

MFA is one technical control inside the Security Rule's program. It is high-leverage but not sufficient on its own. No vendor's MFA implementation, by itself, makes a practice compliant.

How D3rx fits

D3rx SRA Binder Studio walks each authentication decision in plain English, asks for the specifics (which systems, which factors, coverage gaps), records the decision against the risk analysis, and assembles the documentation linked back to the HHS, OCR, eCFR, and NIST sources. It is a point-in-time administrative documentation aid; the practice remains responsible for actually deploying the authentication controls.

Next steps

See where your practice currently stands with the free 5-question readiness check, or review the full workflow and pricing on the main SRA page.