HIPAA and multi-factor authentication: what the proposed Security Rule update means for small practices

Multi-factor authentication is currently addressable under HIPAA. The proposed Security Rule update would make MFA mandatory. What that means for a small practice.

By CoreFolio

Published May 5, 2026Updated July 23, 2026Verified July 23, 20266-minute read

The current HIPAA Security Rule requires covered entities to verify that anyone seeking access to electronic protected health information (ePHI) is who they claim to be — the "person or entity authentication" standard at 45 CFR § 164.312(d).¹ The rule does not name multi-factor authentication (MFA), and § 164.312(d) has no separate implementation specification: authentication is simply required, and a practice decides through its risk analysis whether MFA is a reasonable and appropriate way to meet it.

In 2013, when the current rule was published, MFA was a significant operational burden. Passwords plus a hardware token or a callback phone system were the typical options. "Too burdensome for a five-person practice" was arguably a reasonable position.

Today that argument is far weaker. The major electronic health record (EHR) and email platforms support MFA, and smartphones make it nearly free in terms of friction. The Office for Civil Rights (OCR) has noticed.

The U.S. Department of Health and Human Services (HHS) has proposed an update to the HIPAA Security Rule — a Notice of Proposed Rulemaking, or NPRM (90 Fed. Reg. 898). It is still a proposal, not yet law, and is not expected before 2027, but it would name MFA as an explicit requirement in most cases — a control the rule points to directly, rather than one method a practice weighs in its risk analysis.² This article explains what that means for a small practice.

What the current rule requires

The current rule requires covered entities to "[i]mplement procedures to verify that a person or entity seeking access to electronic protected health information is the one claimed" (45 CFR § 164.312(d)).¹

This is a required standard, not an addressable specification — there is no "implement an alternative and document it" option written into § 164.312(d) itself. What the rule leaves open is the method. For many practices, though, declining to turn on MFA that the EHR already supports is a hard call to defend in a risk analysis: it is a clear, low-cost control, and an investigator will expect a strong rationale for skipping it.

Even under the current rule, OCR has included authentication and MFA gaps in its enforcement findings. The proposed change would name MFA directly, leaving far less room to argue the point.

What the proposed rule requires

The proposed rule would require MFA on systems that create, receive, maintain, or transmit ePHI. It allows only a few narrow exceptions — chiefly certain legacy systems and older FDA-authorized medical devices, and even then only when the practice has a written plan to migrate that ePHI onto supported technology.²

For a small practice, "every system that touches ePHI" typically includes:

The EHR. Your primary clinical system. Many modern EHRs (athenahealth, eClinicalWorks, Epic, Dentrix, SimplePractice, RXNT, and others) support MFA. Check your account settings.
Email. If your practice communicates ePHI via email — sending lab results, scheduling messages that include diagnoses, or any patient communication that identifies both the patient and their condition — email is in scope. Microsoft 365 and Google Workspace both support MFA and can be configured for it in minutes.
Remote access. Any VPN, remote desktop, or cloud portal that lets staff access clinical systems from outside the office needs MFA. This is often the weakest link: IT-configured remote access set up years ago without MFA, still in use.
Billing software. If your billing system is separate from your EHR and contains patient identifiers and claim data, MFA applies.
Cloud backup and storage. If your backup destination is accessible via a web portal, MFA applies.

The difference between addressable and required

Under the current rule, authentication is required but MFA is not named, so a thorough risk analysis that documents equivalent controls can, in principle, justify a different approach: "We assessed this and determined that [alternative measure] provides equivalent protection in our environment."

Under the proposed rule, MFA is named directly. On a system in scope, showing your risk analysis and an explanation will not substitute for having MFA in place — unless the system falls within one of the rule's narrow exceptions.

This matters for audit preparation. The more MFA moves from "a method you can reason about" to "a control the rule names," the less a documented rationale protects a practice that simply never turned it on.

What "MFA" means in practice

Multi-factor authentication requires a user to verify their identity using at least two of three categories:

Something you know — a password or PIN
Something you have — a phone receiving an SMS code, an authenticator app (like Google Authenticator or Microsoft Authenticator), or a hardware token
Something you are — a fingerprint or Face ID

The most common implementation for small practices: username + password, plus a six-digit code from an authenticator app or sent via SMS to a registered phone number.

SMS-based MFA is better than no MFA. Authenticator apps are more secure than SMS (SMS is susceptible to SIM-swapping attacks). Hardware tokens are most secure. For most small practice scenarios, an authenticator app is the appropriate choice.

How to enable MFA on your EHR

The process varies by vendor, but the typical path:

Log in to your EHR as an administrator
Go to Security Settings or Account Settings
Find "Multi-Factor Authentication" or "Two-Factor Authentication"
Enable it for all users (or make it mandatory at the organization level)
Each user will be prompted to enroll on their next login

If you cannot find the setting, contact your EHR vendor's support team. Ask specifically: "How do I enable mandatory MFA for all users at my practice?"

The workflow impact

The realistic impact on a well-implemented MFA setup: each staff member enters their password and then either opens their authenticator app for a code or receives a push notification they tap to approve. This takes about 5–10 additional seconds per login.

On devices that are used regularly (a dedicated front-desk computer), some EHRs offer a trusted device option — MFA is only required on new or unrecognized devices. This reduces friction for staff who log in from the same workstation every day.

The friction of MFA is genuinely small. The protection against unauthorized access, credential stuffing, and phishing-based account takeover is significant.

What to do before the final rule

The proposed rule is not final. Compliance deadlines will be set in the final rule. But:

Assess your current MFA status. Can you enable MFA on your EHR? On your email? On your remote access? Do it now — under the current rule, MFA gaps in your risk analysis need a documented rationale, and "we could enable it but haven't" does not satisfy that standard.
Document the gap. If MFA is not currently enabled and you cannot enable it before your next risk analysis, document the gap, the reason, and your plan to address it.
Prioritize EHR and email. If you have to choose where to start, the EHR (which holds the most comprehensive patient records) and email (which is the most common phishing vector) are the highest-impact.
Brief your staff. MFA only works if staff use it correctly. A two-minute briefing on what MFA is and why you are implementing it reduces resistance and errors.

Sources

45 CFR § 164.312(d) (person or entity authentication) — a required standard with no implementation specifications. https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.312 ↩ ↩²
HHS, HIPAA Security Rule Notice of Proposed Rulemaking (90 Fed. Reg. 898, published January 6, 2025). The proposed multi-factor authentication requirement and its limited exceptions appear in the proposed rule. A proposal, not final law. https://www.hhs.gov/hipaa/for-professionals/security/hipaa-security-rule-nprm/index.html ↩ ↩²

FAQ

Common questions

Is MFA currently required under HIPAA?

Not by name. The current Security Rule requires 'person or entity authentication' — verifying that anyone seeking access to ePHI is who they claim to be (45 CFR § 164.312(d)) — but it does not specify multi-factor authentication. Section 164.312(d) is a required standard with no implementation specifications, so a practice decides through its risk analysis whether MFA is a reasonable and appropriate way to meet it. In practice, many modern EHRs support MFA and not using it is difficult to justify.

Would the proposed Security Rule update make MFA mandatory?

Largely yes. The proposed update — a Notice of Proposed Rulemaking, or NPRM (90 Fed. Reg. 898) — would require MFA on systems that create, receive, maintain, or transmit ePHI, with a few narrow exceptions (for example, certain legacy systems and older FDA-authorized medical devices, and then only with a written plan to migrate the ePHI to supported technology). It is still a proposal, not yet law.

Which systems need MFA under the proposed Security Rule update?

Any system that touches ePHI: the EHR, email (if used for patient communication), remote access portals, billing software, and cloud backup or storage accessible via a web portal.

What type of MFA should I use?

An authenticator app (Google Authenticator, Microsoft Authenticator) is more secure than SMS codes and appropriate for many small practices. SMS-based MFA is better than nothing. Hardware tokens are most secure. Your EHR vendor's recommended MFA method is a reasonable default.

What is the difference between addressable and required under HIPAA?

A required implementation specification must be implemented. An addressable one lets you implement an equivalent alternative or document why the control is not reasonable and appropriate. Person or entity authentication (45 CFR § 164.312(d)) is itself a required standard with no implementation specifications, and MFA is one way to satisfy it. The proposed Security Rule update would name MFA as an explicit requirement, subject to a few narrow exceptions.

Keep learning

Proposed rule updates
Proposed HIPAA Security Rule update: 7 major changes for small practices
The first major Security Rule update since 2013 has slipped to 2027. Here is what is actually proposed, what is law today, and what to do with the extra time.
May 12, 20267-minute read
Proposed rule updates
What the proposed HIPAA Security Rule update means for a solo dental practice
Small dental practices face specific HIPAA challenges: legacy imaging software, shared workstations, and minimal IT support. What the proposed Security Rule update would change.
May 8, 20266-minute read
How-to
How to do a HIPAA risk analysis yourself: a step-by-step guide for small practices
The Security Rule requires every covered entity to conduct an accurate, thorough risk analysis. What it must contain and how to do it yourself, step by step.
May 14, 20266-minute read