Does HIPAA require MFA everywhere ePHI lives?

What are HIPAA's MFA requirements today?

As of November 2026, the HIPAA Security Rule does not require MFA by name. HIPAA MFA requirements come from your own risk analysis: the current Security Rule requires procedures to verify that anyone seeking access to electronic protected health information (ePHI) is who they claim to be, but it does not prescribe a method. Whether you need MFA, and where, turns on that risk analysis.

The standard is 45 CFR 164.312(d), person or entity authentication. It sits beside the access control standard in 164.312(a)(1), which requires a unique user identification for every person using systems that hold ePHI. OCR's October 2026 cybersecurity newsletter states plainly that "the Security Rule does not prescribe a specific type of authentication to implement." Its June 2023 newsletter on authentication went further and said that, as a best practice, regulated entities "should consider implementing multi-factor authentication solutions."

That flexibility has limits. The risk analysis required by 45 CFR 164.308(a)(1)(ii)(A) must identify the risks to ePHI, and risk management under (B) requires security measures that reduce those risks to a reasonable and appropriate level. The October 2026 newsletter says "MFA might be needed to sufficiently reduce risk for remote access and local access to more sensitive systems." A risk analysis that names phishing and stolen passwords as leading threats, then leaves remote email access on passwords alone, is hard to defend in front of a client or OCR. Our article on why OCR keeps enforcing the risk analysis covers what that document has to show.

What would the proposed Security Rule change about MFA?

The proposed HIPAA Security Rule would make MFA a required control, with limited exceptions. HHS published the proposal on January 6, 2025, at 90 FR 898, and it is not final.

The HHS fact sheet says the proposal would "require the use of multi-factor authentication, with limited exceptions," alongside encryption of ePHI at rest and in transit. It would also remove the distinction between required and addressable specifications. The proposal adds a definition of MFA to 164.304. As proposed, a final rule would take effect 60 days after publication, and regulated entities would have 180 days after that to comply.

Timing is uncertain. As of November 2026, the federal regulatory agenda lists final action for July 2027 as a long-term action. Our tracker on where the Security Rule update stands follows the changes. Until a final rule is published, the current rule applies and OCR enforces it. A firm that enforces MFA now addresses today's risk-based standard and is already positioned for the proposed one.

Where does ePHI live at a firm that is not a healthcare provider?

At a law firm, accounting firm or nonprofit that handles health records, ePHI usually lives in email, file storage, billing platforms and remote access tools, often in more places than the firm expects. Every system that stores ePHI, or can reach it, is a login that MFA would need to cover.

Law firms handling medical records for litigation or healthcare clients, accounting firms that do billing or audit work for medical practices, and nonprofits running health programs can all be business associates. HHS's direct liability fact sheet confirms that business associates are directly liable for complying with the Security Rule. Our article on whether your law or accounting firm is a business associate walks through the test. Common places ePHI sits at these firms:

• Microsoft 365 or Google Workspace mailboxes, where records arrive as attachments
• SharePoint, OneDrive and document management systems holding case files and workpapers
• Practice management and billing platforms
• Secure file transfer and client portals used to exchange records
• Remote access tools: VPN, remote desktop gateways, Citrix and your IT provider's remote management software
• Backup consoles and cloud storage administration portals

Which logins should get MFA first?

MFA should go first on logins reachable from the internet and on accounts with administrative power, because those are the doors a stolen password opens.

The Change Healthcare attack shows the cost of a single gap. In written testimony to the Senate Finance Committee on May 1, 2024, UnitedHealth Group CEO Andrew Witty stated that on February 12, 2024, "criminals used compromised credentials to remotely access a Change Healthcare Citrix portal," and that "the portal did not have multi-factor authentication." A practical order of work:

• Email and collaboration accounts for every user, including partners, part-time staff and contractors
• Remote access: VPN, remote desktop gateways and web portals
• Administrator and privileged accounts, including those your IT provider uses
• Cloud applications that store records, including client portals and file-sharing tools
• Backup and recovery consoles, since control of backups decides whether you can restore after an attack

MFA only works when every account belongs to one person. HHS's voluntary Healthcare and Public Health Cybersecurity Performance Goals list multifactor authentication among ten essential goals, next to unique credentials and separate user and privileged accounts. Shared logins defeat MFA and conflict with the unique user identification requirement. In its September 17, 2026 settlement with Ambry Genetics, which followed a phishing attack on an employee email account, OCR listed potential violations that included failing to assign unique user identification and failing to conduct an accurate and thorough risk analysis. The company paid $700,000 and agreed to a two-year corrective action plan.

What counts as MFA, and which kinds resist phishing?

MFA combines two different kinds of factor: something you know, something you have or something you are. A password plus a PIN is not MFA, because both are something you know, as OCR's June 2023 newsletter explains.

Second factors also differ in strength. The October 2026 newsletter recommends that organizations "use phishing resistant MFA where available." In practice that means FIDO2 security keys, passkeys or platform authenticators such as Windows Hello for Business, which are tied to the real sign-in site and cannot be replayed from a fake login page. Text message codes and app approvals are better than passwords alone, but administrator accounts are where phishing-resistant methods matter most.

What should a firm do this quarter?

This quarter, a firm can map where ePHI lives, enforce MFA on the highest-risk logins and record each decision in its risk analysis. A workable sequence:

• List every system that stores or can reach ePHI, including vendor portals and your IT provider's tools.
• Confirm every user has a unique account and retire shared logins.
• Enforce MFA on email, remote access and administrator accounts, then on cloud apps that hold records.
• Move administrators to phishing-resistant methods such as FIDO2 keys or passkeys.
• Block older sign-in methods that bypass MFA, such as legacy authentication protocols in Microsoft 365.
• For any system that cannot support MFA, document the reason, the compensating controls and a review date. Security Rule documentation must be kept six years under 45 CFR 164.316(b).
• Ask subcontractors with access to your systems, including your IT provider, how they protect their own logins. Their obligations should appear in the written assurances required by 164.308(b).

Writing down why a control is or is not in place follows the same discipline as documenting an addressable specification decision.

What should your counsel review before you set MFA scope?

Counsel should review your business associate status, vendor assurances and MFA exceptions before you sign or renew a business associate agreement, and before your next risk analysis update. Bring these decisions:

• Which client engagements make your firm a business associate, given that business associates are directly liable for Security Rule compliance under HHS's direct liability fact sheet. Bring engagement letters and any business associate agreements clients have sent you.
• Whether your written assurances with subcontractors, including your IT provider, meet 45 CFR 164.308(b) and 164.314(a). Bring the current agreements and the vendor's security terms covering how its staff sign in to your systems.
• Whether each documented MFA exception, with its compensating controls, reduces risk to a reasonable and appropriate level under 45 CFR 164.308(a)(1)(ii)(B). Bring the risk analysis and the exception records.

How can s90 help?

s90 helps law, accounting and nonprofit firms find every login that reaches ePHI, put MFA on the ones that matter most and document each decision in the risk analysis. If a client's security questionnaire or an OCR inquiry asked today which logins are protected by MFA and why, could you answer with a document? We map where ePHI lives across your Microsoft 365 tenant, file systems and remote access tools, and move administrators to phishing-resistant keys. Our HIPAA compliance work records each decision in your risk analysis, including any system that cannot support MFA yet and the controls that cover it, so you can show a client or OCR what was done and why. If you would like to see where your gaps are, we can start with a short review.