HIPAA Just Made MFA Mandatory for Every System. Does Your Identity Stack Have Gaps? 

For more than a decade, the HIPAA Security Rule gave healthcare organizations and their business associates a fair amount of latitude. Many of the controls that protect electronic protected health information (ePHI) were labeled “addressable,” which meant an organization could weigh the cost and risk of a given safeguard and document why an alternative approach was reasonable. Multi-factor authentication fell into that category. So did several of the access control requirements that IT and security teams have quietly worked around for years. 

That latitude is going away. 

In January 2025, the Department of Health and Human Services published a Notice of Proposed Rulemaking that represents the most significant rewrite of the HIPAA Security Rule since 2013. The proposal eliminates the distinction between “required” and “addressable” specifications altogether. If finalized as expected in 2026, nearly every technical safeguard becomes mandatory, with a compliance window that gives organizations well under a year to get there. For executives overseeing IT, security, and compliance at universities, government agencies, and any organization that touches ePHI through a hospital system, student health center, research program, or benefits administration, this is no longer a future planning item. It is a near-term operational deadline. 

What the Proposed Rule Actually Asks For 

Strip away the legal language and the proposed rule asks for things that should sound familiar to anyone who has spent time in identity and access management. The headline items include: 

• Multi-factor authentication for every user and every system that creates, receives, maintains, or transmits ePHI, with no exceptions and no alternative compensating controls. 

• A documented technology asset inventory and network map, updated at least annually, showing where ePHI lives and how it moves. 

• Network segmentation that limits which workstations and systems can reach ePHI in the first place. 

• Stronger access controls, including unique identifiers for every user and technology asset, and automatic suspension of access after repeated failed authentication attempts. 

• Annual written verification from business associates and subcontractors confirming they have the required technical safeguards in place. 

• Incident response and recovery capabilities that can restore critical systems within 72 hours. 

Read through that list again and notice how many of these items are, at their core, identity problems. Knowing who and what has access to a system. Verifying that identity with more than a password. Limiting access based on role and location. Producing a record that proves all of this is happening. This is not a checklist that lives entirely in the network security team’s lap. It lives squarely in identity governance. 

The Pain Point: Compliance on Top of a Fragmented Identity Environment 

Here is where most organizations run into trouble, and it is rarely the regulation itself that causes the headache. It is the environment the regulation lands on. 

A typical university or government agency has accumulated identity infrastructure in layers over many years. On-premises Active Directory handles staff and faculty. A separate cloud directory handles a subset of SaaS applications. The student health center or HR benefits system runs its own login. Legacy applications that touch ePHI, sometimes older clinical or case management systems, were never built with modern authentication in mind and cannot easily be retrofitted for MFA without vendor involvement or custom code. 

When a CISO or IT director is asked to enforce MFA everywhere, produce a current asset inventory, demonstrate segmentation, and show audit trails for access reviews, the honest answer is often that no single system in the environment has visibility into all of it. The identity data is scattered. Enforcing a consistent policy means touching a dozen systems individually, and legacy applications that cannot support modern authentication standards become the weak link that an auditor, or worse, an attacker, will find first. 

This is the gap between what the rule asks for and what most identity environments were built to deliver. 

Closing the Gap Without Ripping Everything Out 

The good news is that the technology to close this gap already exists, and it does not require replacing every application that touches ePHI. The approach that works is identity orchestration: a layer that sits between users, applications, and your existing directories, applying consistent authentication and access policy across all of them regardless of how old or new each system is. 

A few specific capabilities matter most for HIPAA readiness: 

A virtual directory that connects to existing identity stores such as Active Directory without requiring synchronization or duplication means your asset and identity inventory stays accurate without a parallel data store to maintain. When the technical safeguards eventually require an annual network map and asset inventory, an environment with one authoritative identity layer is far easier to document than one with five. 

Native identity orchestration allows MFA to be enforced at the access layer in front of legacy applications that were never designed for it, rather than waiting on a vendor roadmap or rewriting application code. This directly addresses the proposed rule’s elimination of MFA exceptions, because it removes the technical excuse for not having MFA on an older system. 

Centralized access policy, including role-based and attribute-based controls, gives you the mechanism to demonstrate segmentation and least-privilege access when an auditor or business associate asks for evidence. Behavioral authentication methods, such as typing biometrics, add a layer of continuous verification that strengthens the “person or entity authentication” standard without adding friction for end users who are already managing enough passwords and prompts. 

For organizations managing this on top of an already stretched IT team, having a managed service partner that monitors and maintains the identity environment can be the difference between a compliance program that is reactive every time a deadline shifts and one that is simply ready when the final rule publishes. 

Where This Capability Exists Today 

Organizations evaluating their options do not need to wait for the final rule to start this work, and they do not need to choose between a multi-year application overhaul and doing nothing. Platforms built specifically around identity orchestration already provide the pieces described above. 

The Virtual Identity Server (VIS) is built to sit in front of existing directories such as Active Directory, LDAP, and HR systems without requiring synchronization. For an organization trying to produce an accurate identity and asset inventory, that matters because there is no second data store to keep in sync or reconcile during an audit. It also means legacy applications that authenticate against an existing directory can be brought under a unified policy layer without modification. 

The OptimalCloud builds on that foundation with centralized single sign-on, MFA (including options like typing biometric behavioral authentication for continuous verification), and role and attribute-based access policies that can be applied consistently across cloud and on-premises applications, including systems that were never designed to support modern authentication. For organizations in higher education or government that operate as PaaS-agnostic, privately hosted environments, the OptimalCloud’s dedicated cloud deployment model also gives IT and compliance teams more direct control over where identity data resides, which is useful when documenting segmentation and data flow for ePHI. 

For teams that are already stretched thin, the OptimalCloud’s concierge managed service model means the work of configuring, monitoring, and adjusting these policies does not fall entirely on internal staff during an already demanding compliance cycle. 

Start the Conversation Now 

The final rule has not been published as of this writing, and the exact compliance date may still shift. But the direction is set, and the underlying problem, identity sprawl across legacy and modern systems, does not go away regardless of when the deadline lands. Organizations that begin consolidating identity visibility and extending MFA and access governance to every system now will treat the final rule as a documentation exercise. Organizations that wait will be doing identity architecture work under deadline pressure, which is rarely where good security decisions get made. 

If your environment includes any system that touches ePHI, whether that is a university health center, a research program handling patient data, or a government benefits system, it is worth taking an honest inventory now of which applications can support MFA today, which cannot, and what would be required to bridge that gap without a multi-year application replacement project. That assessment is the real starting point, and it is one most organizations can complete faster than they expect. 

Contact us for more information.

Frequently Asked Questions 

Does HIPAA require multi-factor authentication (MFA)? The current HIPAA Security Rule does not explicitly name MFA as a requirement, but the Person or Entity Authentication standard under 45 CFR 164.312(d) requires verifying the identity of anyone accessing ePHI, and OCR regularly cites the absence of MFA during breach investigations. The proposed 2025 update to the Security Rule would make MFA an explicit, mandatory requirement for every system that creates, receives, maintains, or transmits ePHI, with no exceptions. 

What counts as “access control” under the HIPAA Security Rule? Access control refers to the technical safeguards under 45 CFR 164.312(a) that limit who can view or use ePHI, including unique user identification, automatic logoff, and encryption. The proposed 2025 update would expand this to require unique identifiers for technology assets as well as users, along with network segmentation to physically and logically limit which systems can reach ePHI. 

How does identity and access management (IAM) help with HIPAA compliance? IAM gives organizations a centralized way to verify user identity, enforce least-privilege access, apply MFA, and produce the audit trails that HIPAA’s technical safeguards require. Because many HIPAA Security Rule requirements (authentication, access control, audit controls) map directly to identity management functions, a unified IAM platform makes it significantly easier to demonstrate compliance during a risk assessment or audit. 

Are business associates required to meet the same HIPAA IAM requirements as covered entities? Yes. Business associates, including IT vendors, cloud hosting providers, and EHR platforms, must implement the same technical safeguards required of covered entities under HIPAA. The proposed 2025 Security Rule update goes further, requiring covered entities to obtain written verification at least once every 12 months that each business associate has these safeguards in place. 

What is a virtual directory, and how does it support HIPAA compliance? A virtual directory connects to an organization’s existing identity stores, such as Active Directory or LDAP, without copying or synchronizing the data into a separate database. For HIPAA compliance, this matters because it gives organizations a single, accurate view of users and access rights, which simplifies the technology asset inventory and access control documentation that the Security Rule requires.