HIPAA MFA requirements are shifting healthcare identity design

At a glance

What this is: This is an analysis of HIPAA’s proposed MFA changes and how they push healthcare identity design toward phishing-resistant authentication and stronger step-up controls.

Why it matters: It matters because healthcare IAM teams must align workforce, vendor, and patient access patterns to a coming explicit MFA requirement without breaking clinical workflows or over-relying on SMS and passwords.

Context

Healthcare identity programmes are being pushed from implied best practice toward explicit MFA design requirements, especially where systems create, receive, maintain, or transmit ePHI. The governance gap is not whether authentication matters, but whether teams can prove that access controls match the risk of the system, the user, and the workflow.

The proposed HIPAA Security Rule would narrow the room for addressable exceptions and make stronger authentication a default expectation for interactive access, business associates, and higher-risk actions. That forces IAM, PAM, and security teams to treat MFA as an architecture decision, not just a login preference.

Key questions

Q: What breaks when healthcare access still depends on passwords?

A: Passwords break down when clinical speed and security are forced into the same rigid workflow. Staff begin reusing credentials, leaving sessions unattended or sharing access to avoid delay, which weakens accountability and expands insider risk. The result is not just a poor user experience; it is a control model that incentivises bypass behaviour.

Q: Why does phishing-resistant MFA matter more than SMS codes for healthcare access?

A: SMS codes remain vulnerable to interception, redirection, and social engineering, so they do not materially reduce phishing risk for high-value healthcare systems. Phishing-resistant methods bind authentication to the real domain and make stolen credentials far less useful outside the legitimate login flow.

Q: How should healthcare teams prioritise MFA rollout across their identity estate?

A: Start with privileged access, remote access, and third-party access to ePHI, because those paths combine the highest impact with the weakest tolerance for compromise. Then extend the model to workforce access and patient-facing journeys where the business process can absorb stronger authentication.

Q: What should organisations do when a legacy clinical system cannot support modern MFA?

A: Treat the exception as a controlled risk decision, not a permanent workaround. Document the constraint, apply compensating controls such as segmentation and restricted access windows, and set a migration plan so the exception does not become a standing weak point.

Technical breakdown

Why password-only access no longer holds up for ePHI systems

The proposed rule matters because it turns authentication from a flexible implementation choice into a baseline control expectation for systems handling ePHI. In practice, password-only access creates an obvious compromise path, but the larger issue is governance: healthcare environments often tolerated exceptions around legacy apps, shared workstations, and acquisition-era portals. Once MFA is explicit, those exceptions become exceptions to a defined security obligation rather than a local preference.

Practical implication: Map every ePHI-touching system to its current authentication method and flag any password-only path as a remediation priority.

Why phishing-resistant MFA is the destination, not just a stronger second factor

Passkeys and hardware security keys change the threat model because they bind authentication to the legitimate domain and reduce phishing replay risk. That is materially different from OTP-based MFA, which still depends on a shared secret or a one-time code that can be intercepted or socially engineered. For healthcare, the practical value is not theoretical strength but reduced susceptibility to credential theft on remote access portals, admin accounts, and business associate connections.

Practical implication: Prioritise phishing-resistant MFA for privileged access, remote access, and vendor sessions before expanding it across lower-risk workflows.

How step-up authentication fits clinical and patient-facing workflows

Blanket MFA on every interaction creates friction, and in healthcare that friction often becomes a security problem of its own because staff work around it. Step-up authentication is the architectural answer: keep routine access light, then add stronger checks when the action, device, or location raises risk. This is especially relevant for export events, privilege changes, unfamiliar devices, and patient portals where user abandonment must be balanced against assurance.

Practical implication: Design step-up policies around risky actions and contexts so the strongest challenge appears only where the risk justifies it.

Threat narrative

Attacker objective: The objective was to gain broader access to healthcare systems, steal data, and extort the organisation through ransomware.

1. Entry began with compromised credentials on a Citrix remote access portal that had no multi-factor authentication, giving attackers a simple way into the environment.
2. Credential use then enabled lateral movement inside the healthcare network, which expanded the attacker’s reach beyond the initial portal.
3. The attack progressed to data exfiltration and ransomware deployment, turning one missing authentication control into a broad operational and privacy incident.

Breaches seen in the wild

• Microsoft Midnight Blizzard breach: Midnight Blizzard (APT29) exploited legacy test account without MFA to breach Microsoft.
• Uber breach 2022: A contractor's stolen password and MFA fatigue gave a Lapsus$-linked attacker Uber's internal tools; Uber rotated keys to many services.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

HIPAA’s MFA shift is really an identity governance reset, not just a compliance update. Once MFA becomes explicit across ePHI systems, the question changes from whether teams can justify exceptions to whether they can still defend password-based access paths at all. The practical implication is that healthcare programmes must align authentication policy, vendor access, and system classification under one governance model.

Password-era exception handling created the control gap the proposed rule is designed to close. Addressable authentication let organisations document their way around strong controls on legacy and operationally sensitive systems. That assumption no longer scales when ePHI access spans workforce, business associate, and patient-facing journeys. The implication is that teams must stop treating exceptions as routine design patterns and start treating them as temporary risk positions.

Phishing-resistant authentication should be the default design target for healthcare access, not an aspirational enhancement. Passkeys, security keys, and other domain-bound methods change the economics of credential theft because they are much harder to replay through fake login pages. For healthcare IAM teams, the meaningful shift is toward methods that reduce both user friction and attacker leverage at the same time.

Healthcare MFA is also an orchestration problem, not a single-control problem. The same organisation can need different authentication strengths for clinicians, billing teams, contractors, vendors, and patient portals. The right governance model preserves speed for routine care while reserving stronger challenges for privileged actions, risky locations, and sensitive transactions. Practitioners should think in terms of authentication policy design, not one-size-fits-all rollout.

From our research library:

• Across one million observed logins, 1 in 4 were password-based rather than SSO, 2 in 5 were not protected by MFA and 1 in 5 used a weak, breached or reused password.

What this signals

Healthcare MFA now sits at the intersection of identity governance and clinical usability. The programme question is no longer whether to add a second factor, but how to reduce phishing exposure without forcing staff into unsafe workarounds. Teams that ignore workflow design will recreate the very exception patterns the proposed rule is trying to eliminate.

Passkeys shift the control conversation from code delivery to domain-bound authentication. That matters because healthcare environments are full of remote access, vendor connectivity, and patient-facing journeys where OTP friction is high and phishing risk is persistent. The practical signal is that MFA strategy should increasingly be written as an architecture roadmap, not a tool preference.

For practitioners

• Inventory every ePHI access path List all systems that create, receive, maintain, or transmit ePHI, including remote portals, admin consoles, vendor connections, patient portals, and legacy clinical apps.
• Classify current authentication methods by risk Document where the environment still relies on passwords, SMS, shared accounts, local credentials, or vendor-managed access, then rank those paths by exposure.
• Move privileged and remote access to phishing-resistant MFA Start with administrator accounts, remote access portals, and business associate sessions, then use passkeys or security keys where the workflow can support them.
• Define step-up triggers for high-risk actions Require additional verification for exports, privilege changes, unfamiliar devices, unusual locations, and other sensitive transactions that raise the assurance bar.
• Document compensating controls for legacy exceptions For systems that cannot yet support modern MFA, record the limitation, the compensating controls, and the migration plan so the exception is deliberate and auditable.

Key takeaways

• Healthcare MFA is moving from implied good practice to explicit governance expectation across ePHI systems.
• The main risk is not just weaker authentication, but the exception culture that let legacy access paths persist after acquisition and workflow pressure.
• Teams that want to be ready should prioritise phishing-resistant MFA, step-up logic, and auditable exception handling now.

Key terms

• Phishing-Resistant MFA: Phishing-resistant MFA uses authentication factors that cannot be easily replayed, intercepted, or socially engineered. In regulated environments, this usually means device-bound or cryptographic methods rather than push prompts or SMS codes, because the control must hold up under realistic attack conditions.
• Step-up Authentication: Step-up authentication is an additional verification step triggered when a session becomes higher risk or a user attempts a sensitive action. It is used to reduce exposure without forcing extra friction across every interaction, which makes it useful for runtime access governance.
• Compensating Control: A compensating control is a measure that reduces risk when the ideal fix, such as immediate patching or redesign, is not possible. In OT, compensating controls often include session recording, access restriction, and tighter monitoring. They do not eliminate the underlying issue, but they narrow exposure until safer remediation can happen.
• ePHI: ePHI means electronic protected health information, the digital form of health data that must be safeguarded under healthcare privacy and security requirements. It includes records, identifiers, and associated information that can be exposed through compromise of systems, applications, or connected devices handling clinical and administrative data.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.