Multi-factor Authentication and Healthcare Compliance Requirements: What Healthcare Organizations Need to Know

Multi-factor Authentication and Healthcare Compliance Requirements: What Healthcare Organizations Need to Know

Multi-factor authentication (commonly known as MFA) is now one of several important safeguards in healthcare cybersecurity. However, there is an important distinction that healthcare organizations need to understand. The HIPAA Security Rule does not contain a finalized, universal MFA mandate…yet. In its December 2024 "Notice of Proposed Rulemaking", the Department of Health and Human Services (HHS) proposed MFA to become a required safeguard of the revised HIPAA Security Rule.[1] Until the final rule is published, it remains a highly encouraged industry best practice.

Healthcare organizations must protect electronic protected health information (ePHI) with appropriate administrative, physical, and technical safeguards. The Office of Civil Rights' (OCR's) current guidance also makes clear that a Security Risk Analysis (SRA) may determine MFA is necessary to reduce unauthorized access risk for some software systems[2].

For hospitals, medical practices, health plans, clearinghouses, and business associates, the immediate need is to understand both the current rule and the direction of the proposed revisions to the rule. A defensible healthcare compliance program should protect high risk access, carefully document any exceptions, and be ready to adjust when the OCR finalizes the proposed Security Rule changes. As of the date of this blog article, the HIPAA Security Rule's Final Rule updates are scheduled for publication in July 2027[3].

Why MFA Matters For Compliance

MFA requires a user to prove their identity using at least two different factors, such as something they know, something they possess, or something they are. A password plus an authenticator app approval or generated code is a common example. A password plus a phishing resistant hardware security key is another good example. The proposed rule describes MFA in terms of using at least two of these authentication factor categories.

It is no surprise healthcare organizations remain a frequent target for credential theft, ransomware, and unauthorized remote access because ePHI has high value on the black market and clinical operations often depend on systems always being available. MFA helps reduce the damage from a stolen password because the password alone should not be enough to enter the account.

This matters operationally as much as it does technically. A compromised email account is an easy starting point for phishing other workforce members, resetting passwords, accessing cloud storage, or reaching systems that support patient care. MFA is therefore not merely an IT project. It is an access control safeguard that should be incorporated into the organization's HIPAA risk management process.

Current Rule vs. Proposed Rule

The current HIPAA Security Rule requires covered entities and business associates to implement procedures that verify a person or entity seeking access to ePHI as the person they claim to be.[4] The existing regulation does not require MFA by its name. Instead, it requires regulated entities to select safeguards that are reasonable and appropriate, based on their SRA and risk management processes. A basic username and password system may not be enough of a reasonable control for every use case, especially where remote, privileged, cloud, or vendor access creates a high likelihood of credential compromise.

The proposed HIPAA Security Rule[5] would make MFA a specific requirement with limited exception. OCR's proposal would also remove the current distinction between "required" and "addressable" implementation specifications, making implementation specifications required unless a specific limited exception applies.

Topic	Current HIPAA Security Rule	Proposed Security Rule Updates
Person/Entity Authentication	Requires procedures to verify identity before ePHI access	Would retain and strengthen authentication expectations
MFA	Not named as a blanket regulatory mandate but may be necessary based on risk[6]	Would require MFA with limited exceptions
Compliance Posture	Risk-based and evidence-driven	More prescriptive and broader in scope
Immediate Action	Assess risk and deploy MFA where needed to reduce risk	Build scalable controls now so expansion is manageable if finalized

The practical message is straightforward: Do not claim MFA is already universally mandated by a final 2026 HIPAA rule. Instead, treat MFA as a priority risk management expectation and prepare for the proposed requirement.

Where MFA Should Apply Now

The proposed rule would require MFA for access to systems which create, receive, maintain, or transmit ePHI, as well as technology assets with the potential to affect ePHI's confidentiality, integrity, or availability. This scope is broader than simply requiring MFA for an electronic health record login.

Organizations can begin now by mapping every identity pathway reaching ePHI or materially affecting an ePHI environment.

Access Scenario	Practical Compliance Priority	Recommended Approach
Remote access, VPN, remote desktop	Critical	Require MFA for every user and eliminate shared accounts
Email and cloud productivity suites	Critical	Require MFA as email compromise often enables broader attacks
EHR, practice management, billing, imaging, and patient portals	High	Enable platform MFA where available and assess supporting identity controls
Privileged administrator accounts	Critical	Use separate admin accounts, MFA, least privilege, and enhanced logging
Cloud hosting and backup consoles	Critical	Require phishing resistant MFA where supported.
Vendors and business associates	Critical	Require named accounts, MFA, time-limited access, and access logging
Shared clinical workstations	High	Use secure workflows that preserve speed while preventing unattended access
Legacy applications	High	Document limitations, apply compensating controls, and maintain remediation plans

Here is a useful testing tip: If an attacker compromised this account, could they view ePHI, alter ePHI, interrupt systems containing ePHI, reset credentials, or gain a pathway to another system that can? If the answer is yes, MFA should be evaluated as a priority control.

Choosing the Right MFA Method

Not all MFA is equally resistant to phishing or account takeover. Text message codes are better than password only access, however, they can be vulnerable to social engineering, SIM-swapping, and phishing. Authenticator applications, push approvals with number matching, device bound credentials, and hardware security keys can provide stronger protection when deployed correctly.

Healthcare organizations should select methods based on the sensitivity of the access, the clinical setting, available technology, and workforce usability. The goal is not to impose friction for its own sake. The goal is to make unauthorized access significantly harder without disrupting safe patient care.

Strong implementation practices incorporate MFA requirements for administrator, remote access, cloud console, email, and vendor accounts first. It should also include favor phishing resistant methods for privileged accounts and high impact systems. Threat actors have also been known to try and circumvent MFA by requesting password resets from an organization's help desk. Take the time to build a process to prevent help desk password reset procedures from becoming a method to bypass MFA.

Internal threats to ePHI security can also be a problem. Make it clear in your policies and procedures that your organization prohibits sharing usernames, passwords, or any other login/authentication information. Setting a session timeouts and automatic logoff safeguards is also a highly recommended practice to ensure internal and external threats are mitigated. Take the time to effectively train your workforce members to recognize MFA fatigue attacks, suspicious push prompts, and social-engineering attempts and maintain a process for lost phones, replacement tokens, emergency access, and terminated workforce access.

Managing Legacy System Exceptions

Legacy technology is not automatically exempt from HIPAA security obligations. If a system cannot support MFA directly, the organization should document the limitations and use compensating controls to reduce the risk to a reasonable and appropriate level.

Possible compensating controls could include network segmentation, jump servers, tightly restricted access lists, unique accounts, strong passwords, privileged access management, enhanced logging, continuous monitoring, physical access restrictions, and vendor access windows. The right combination for these controls depends on the specific system and threat scenario.

The key is documentation. An auditor is not going to be persuaded by "the application is old" as a complete explanation of why safeguards were not implemented. Stronger documentation identifies the asset, confirms whether it creates, receives, maintains, transmits, or affects ePHI, explains why MFA is unavailable, assesses the residual risk, lists compensating controls, assigns a remediation owner, and establishes a targeted review date.

This approach aligns with OCR's emphasis on an accurate and thorough SRA. The HIPAA Security Rule requires regulated entities to assess potential risks and vulnerabilities to ePHI, then implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level.

Building an Audit-Ready MFA Program

An effective MFA program is more than a technology rollout. It is a documented process connecting the SRA, system inventory, access management, workforce training, monitoring, and corrective action.

Healthcare organizations should retain evidence showing how they made MFA decisions and how they verify ongoing implementation. Useful audit evidence can include:

• A current inventory of systems, applications, devices, cloud services, and vendors involving ePHI.
• A workforce and third-party access map showing who can access each environment.
• SRA documentation identifying credential theft and unauthorized access as threats.
• Written authentication, access control, remote access, vendor access, and emergency access policies
• MFA configuration records, screenshots, system reports, and enrollment evidence
• Exception records and compensating control assessments for unsupported systems
• Access review records for terminated users, privileged accounts, and third parties.
• Training records addressing password security, phishing, MFA prompts, and reporting.
• Incident response records showing how authentication incidents are investigated and corrected.

Do not treat an MFA dashboard as the entire compliance program. A dashboard might show 95 percent of users are enrolled, but it may not reveal that five administrator accounts, service accounts, third-party accounts, or emergency access workflows remain outside of the control.

A Practical Timeline

Although there is no final federal deadline for a universal MFA mandate as of 2026, that does not mean healthcare organizations should ignore the proposed changes. Many of them are relevant, effective practices to maintain the security of ePHI. Take the time to evaluate and plan now using a risk-based implementation schedule, like this one:

Timeframe	Priority Actions
First 30 days	Inventory ePHI systems, identify privileged and remote access, confirm MFA status, and identify shared accounts
Days 31 to 60	Enable MFA for email, VPN, remote desktop, cloud administration, backups, and privileged users
Days 61 to 90	Address EHR and business applications, implement vendor access controls, and document exceptions
Ongoing	Review access, test emergency workflows, monitor failed authentication events, retrain users, and update the SRA

Make the effort to monitor OCR rulemaking activity rather than relying solely on vendor marketing summaries. All this information is publicly available with a simple search. HHS has expressly stated the existing Security Rule remains in effect while the Department undertakes the proposed rulemaking.

Risk of Non-Compliance

A security incident involving ePHI can create operational disruptions, patient safety concerns, remediation costs, breach notification obligations, contractual consequences, and OCR scrutiny. MFA does not eliminate these risks. However, it is a well-established safeguard against common credential-based attacks.

From a HIPAA perspective, the risk is not limited to whether an organization can point to a password policy. The OCR expects a risk-based program with safeguards appropriate to the organization's environment. If credential theft is foreseeable and an organization has not assessed or addressed the risk, the absence of MFA or similarly effective control may be difficult to defend.

The proposed rule also signals OCR's expectation for regulated entities to modernize cybersecurity safeguards. Organizations that build mature MFA governance will be better positioned when the proposed rule is finalized and better protected regardless of the final regulatory outcome.

FAQs

Is MFA required by HIPAA in 2026?

No. The current HIPAA Security Rule requires identity verification procedures for access to ePHI, but it does not impose a universal MFA mandate. HHS has proposed requiring MFA with limited exceptions and the current rule remains in effect during rulemaking.

Does MFA apply only to the EHR?

No. A mature MFA assessment includes email, remote access, cloud systems, backup consoles, billing systems, imaging platforms, patient portals, administrator accounts, and vendor pathways that can access or affect ePHI. The proposed rule's scope would include systems handling ePHI or those that could affect its confidentiality, integrity, or availability.

Are business associates affected?

Yes. The HIPAA Security Rule applies to covered entities and business associates that create, receive, maintain, or transmit ePHI. HHS's proposed rule also applies to covered entities and business associates.

What if a legacy system does not support MFA?

Document the limitation, perform a risk assessment, implement compensating controls, assign a remediation owner, and review the exception regularly. The OCR has recognized organizations may need a third-party MFA solution where the operating system or software does not provide an included MFA option.

Are text message codes sufficient?

Not necessarily. They can improve security over passwords alone, but they are generally less resistant to phishing and SIM-swapping than authenticator applications or hardware security keys. Privileged and high impact access should use stronger, phishing resistant methods where feasible.

Should clinicians use MFA at shared workstations?

Yes, but the workflow should be designed around patient care. Consider fast reauthentication methods, automatic logoff, proximity-based controls (where appropriate), individual accounts, and secure emergency access procedures. Convenience should not become a reason for shared passwords or unmanaged access.

What documentation should be retained?

Maintain the SRA, risk management plan, system inventory, MFA policy, configuration evidence, access review records, exception documentation, vendor access records, training evidence, monitoring reports, and all corrective action records. This documentation demonstrates MFA is part of a managed HIPAA security program instead of a one-time technical deployment.

How does your organization currently verify each privileged, remote, and third-party account is protected by MFA or another documented compensating control?