Skip to main content
CoreFolioHIPAA
The 2026 rule

HIPAA and multi-factor authentication: what the 2026 rule means for small practices

Multi-factor authentication is currently 'addressable' under HIPAA — meaning you can document why you didn't implement it. The proposed 2026 rule would make it mandatory. Here is what that means in practice.

5-minute read

The current HIPAA Security Rule lists multi-factor authentication (MFA) as an "addressable" implementation specification under 45 CFR § 164.312(d). Addressable means a covered entity must assess whether implementing it is a reasonable and appropriate safeguard for their specific environment — and if they decide not to, document why.

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.

In 2026, that argument does not hold. Every major EHR has MFA built in. Every email platform has MFA built in. Smartphones make MFA nearly free in terms of friction. OCR has noticed.

The proposed 2026 rule (90 Fed. Reg. 898) would make MFA a required specification — not addressable, not optional with documentation. Required. This article explains what that means for a small practice.

What the current rule requires

The current rule requires covered entities to implement "procedures for verifying that a person or entity seeking access to electronic protected health information is the one claimed" (45 CFR § 164.312(d)).

The implementation specification is "addressable," which means you have to implement it or document an equivalent alternative. For most practices in 2026, "I do not have MFA on my EHR login" is difficult to document as a reasonable alternative — your EHR almost certainly supports MFA, and not using it is a clear security gap that any investigator will flag.

Even under the current rule, OCR has included MFA gaps in its enforcement findings. The 2026 rule change simply eliminates the option to argue otherwise.

What the proposed rule requires

The 2026 NPRM would require MFA on every system that creates, receives, maintains, or transmits ePHI. No exceptions, no addressable flexibility.

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

  • The EHR. Your primary clinical system. Most 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

When a specification is addressable, you have a defense: "We assessed this and determined that [alternative measure] provides equivalent protection in our environment." With appropriate documentation, you can skip MFA under the current rule.

When a specification is required, there is no defense. No documentation saves you. Either you have MFA or you do not.

This matters for audit preparation. Under the current rule, a thorough risk analysis documenting your alternative controls can satisfy an investigator. Under the proposed rule, showing your risk analysis and explanation will not be enough if MFA is absent.

What "MFA" means in practice

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

  1. Something you know — a password or PIN
  2. Something you have — a phone receiving an SMS code, an authenticator app (like Google Authenticator or Microsoft Authenticator), or a hardware token
  3. 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:

  1. Log in to your EHR as an administrator
  2. Go to Security Settings or Account Settings
  3. Find "Multi-Factor Authentication" or "Two-Factor Authentication"
  4. Enable it for all users (or make it mandatory at the organization level)
  5. 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 2026 rule is not final. Compliance deadlines will be set in the final rule. But:

  1. 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.

  2. 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.

  3. 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.

  4. 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) (authentication); NPRM: HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information, 90 Fed. Reg. 898 (Jan. 6, 2025). Final rule has not been published as of 2026-05-05.