TL;DR: HIPAA’s proposed Security Rule would make MFA explicit across systems that create, receive, maintain, or transmit ePHI, with limited exceptions, and it points healthcare teams toward phishing-resistant methods such as passkeys and security keys, according to Authsignal. Password-only access and SMS-based fallback strategies are becoming harder to defend as durable healthcare identity controls.
At a glance
What this is: This is an analysis of proposed HIPAA MFA changes and the practical shift toward stronger authentication for ePHI access.
Why it matters: It matters because healthcare identity teams must reconcile compliance, clinical workflow, vendor access, and phishing-resistant authentication in one programme.
By the numbers:
- 27 days
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
👉 Read Authsignal's analysis of HIPAA MFA requirements and healthcare passkeys
Context
HIPAA MFA is no longer just a technical preference, it is becoming a governance requirement for every system that touches electronic protected health information. The real issue is not whether authentication exists, but whether the control is strong enough, consistent enough, and adaptable enough for clinical and vendor-heavy environments.
Healthcare programmes fail when they treat all access the same. Remote portals, privileged admin paths, shared workstations, legacy clinical applications, and third-party access each carry different risk, so a single uniform login pattern creates friction without providing equal protection.
Key questions
Q: How should healthcare teams implement MFA for ePHI access without breaking clinical workflows?
A: Start by separating routine access from high-risk access. Use risk-based step-up authentication for privilege changes, new devices, unusual locations, and data export, while moving admin and remote paths to phishing-resistant methods first. That reduces friction where it matters and avoids forcing every clinical login through the same heavy process.
Q: Why is SMS not a durable long-term MFA strategy for healthcare identity?
A: SMS is better than password-only access, but it remains vulnerable to interception, SIM swap, and social engineering. In healthcare, that weakness matters because compromise can expose ePHI at scale. Treat SMS as a transitional option and plan a move toward passkeys or hardware security keys for higher-risk access.
Q: What breaks when healthcare systems rely on addressable authentication exceptions too long?
A: The programme starts to fragment. Teams document why MFA is not reasonable on one system, then repeat the exception across legacy apps, vendor portals, and shared workstations until the identity model no longer matches the actual risk. That creates an audit gap and leaves the highest-value access paths under-protected.
Q: Who is accountable when business associates access ePHI without strong MFA?
A: The covered entity remains accountable for the access path, even when the third party operates the system. Business associate agreements, evidence collection, and access reviews need to show that vendors use the same authentication standard or an approved compensating control. Accountability does not transfer with the login.
Technical breakdown
Why addressable authentication controls leave a gap
The current HIPAA Security Rule lets organisations treat some implementation specifications as addressable, which means they can implement an alternative control or document why the original control is not reasonable and appropriate. In practice, that flexibility created room for weak authentication decisions on systems that access ePHI. The proposed rule removes most of that discretion for authentication, turning MFA from a documented option into a baseline expectation. That change matters because security programmes often collapse under ambiguity, not under missing technology alone.
Practical implication: inventory every ePHI-touching system and identify where addressable logic has been used to justify weaker authentication.
Why phishing-resistant MFA is the real target state
The distinction that matters is not MFA versus no MFA, but phishing-resistant versus replayable MFA. SMS codes, email OTPs, and simple push flows raise the bar but remain vulnerable to interception, social engineering, and prompt fatigue. Passkeys and hardware security keys use public-key cryptography, bind authentication to the legitimate domain, and remove the shared secret that attackers most often steal or coerce. For healthcare, that makes them better suited to privileged and remote access, where the impact of account compromise is highest.
Practical implication: prioritise passkeys and hardware keys for privileged and remote users before extending them broadly.
How step-up authentication fits clinical workflow
Step-up authentication is the mechanism that lets healthcare teams avoid blanket friction while still tightening access where risk rises. Instead of challenging every login equally, the identity layer can request additional verification when a user changes device, location, privilege level, or attempts a sensitive action such as exporting data. That is an important architectural choice in healthcare because shared stations, shift-based work, and emergency care do not tolerate constant interruption. Risk-based prompting is what makes stronger authentication operationally survivable.
Practical implication: define high-risk events that trigger stronger authentication and reserve extra prompts for those moments only.
Threat narrative
Attacker objective: The attacker objective was broad access to healthcare data and operational disruption through ransomware.
- Entry began with compromised credentials used against a Citrix remote access portal that had no multi-factor authentication, giving attackers a simple path into the environment.
- Escalation followed as the attackers moved laterally, expanded their access, and positioned themselves to exfiltrate data before deploying ransomware.
- Impact was realised nine days later through data theft and ransomware, with the incident ultimately becoming the largest healthcare data breach ever reported in the US.
Breaches seen in the wild
- Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
- Microsoft Midnight Blizzard breach — Midnight Blizzard (APT29) exploited legacy test account without MFA to breach Microsoft.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
HIPAA MFA is becoming an identity governance problem, not just a login problem. The proposed rule pushes healthcare security teams to treat authentication as a control layer that must be inventoried, evidenced, and risk-scoped across humans, vendors, and clinical systems. Once MFA becomes explicit, the question is no longer whether to add a factor, but how to prove the control applies where ePHI risk is highest.
Phishing-resistant authentication is the operational baseline that healthcare has been delaying. SMS and simple OTP flows remain bridge mechanisms, not durable end states, because the threat model now assumes credential theft, social engineering, and session abuse as routine. The implication is that healthcare IAM roadmaps must shift from compliance minimums to domain-bound, public-key authentication for privileged and remote access.
Shared workstations expose the identity blast radius problem in its clearest form. A single login design that assumes one user, one device, and one low-friction path does not fit nursing stations, vendor support, or emergency care. The practitioner lesson is that healthcare identity architecture must be segmented by workflow, not flattened into one authentication pattern for all access.
Step-up authentication is the named concept that healthcare teams should adopt now. It captures the reality that access risk changes during the session, especially when users move from routine chart access to privilege changes or data export. The governance value is simple: MFA policy has to become context-aware if it is going to survive real clinical operations.
Vendor access without lifecycle offboarding is where healthcare programmes often fail quietly. The proposed rule makes third-party ePHI access impossible to treat as an exception carved out of the main identity model. If business associate access is not bound to the same authentication, review, and evidence standards as internal users, the compliance gap becomes an operational one.
From our research:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
- For a broader identity lens, the Ultimate Guide to NHIs , The NHI Market helps situate authentication and lifecycle decisions across machine and human access.
What this signals
Healthcare identity teams should read this as a warning that compliance timelines will compress architecture decisions. The control set needs to be mapped now across EHRs, portals, vendor access, and legacy clinical tools, because the hardest work is proving which systems can support phishing-resistant authentication and which require a controlled exception.
Step-up authentication boundary: the session has become the governance unit that matters most. When a clinical workflow moves from routine access to export, privilege change, or external access, the policy engine needs to recognise that the risk profile has changed and respond without forcing blanket friction across the whole estate.
NHI Mgmt Group’s view is that healthcare IAM programmes will increasingly be judged on evidence, not policy language. With 6 distinct secrets manager instances on average in organisations, fragmented control surfaces are a reminder that distributed identity operations need explicit ownership, review, and logging before regulators ask for proof.
For practitioners
- Map every ePHI touchpoint to an authentication state Document whether each system uses SSO, local passwords, MFA, shared access, or vendor-managed login, then identify where authentication evidence is missing.
- Prioritise phishing-resistant MFA for privileged and remote access Move admin accounts, remote portals, and high-volume ePHI paths onto passkeys or hardware security keys before expanding to lower-risk workflows.
- Define step-up triggers around sensitive actions Trigger stronger authentication for privilege changes, unusual devices, suspicious locations, and large data exports so clinical work stays usable.
- Document legacy exceptions with compensating controls For applications that cannot support modern MFA, record the constraint, restrict access windows, segment the network, and preserve the migration plan.
- Extend the same standard to business associates Make sure vendor access to ePHI is covered in contracts, review cycles, and logging so offboarding and accountability do not stop at the firewall.
Key takeaways
- HIPAA’s proposed MFA rule turns authentication into a mandatory governance control for every ePHI path, not just a best-practice checkbox.
- Phishing-resistant methods such as passkeys and hardware keys are the practical target state, while SMS and basic OTP remain transitional at best.
- Healthcare teams that map systems, segment risk, and document exceptions now will be better positioned to absorb the final rule without disrupting care.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-53 Rev 5 set the technical controls, while GDPR define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | SP 800-63B | The article explicitly points to phishing-resistant authentication and authenticator strength. |
| NIST CSF 2.0 | PR.AC-1 | Identity proofing and authentication sit at the centre of this proposed HIPAA change. |
| NIST Zero Trust (SP 800-207) | The article’s risk-based access model aligns with continuous verification and least privilege. | |
| NIST SP 800-53 Rev 5 | IA-2 | Interactive authentication controls are directly implicated by the proposed rule. |
| GDPR | Art.32 | Healthcare identity controls often protect personal data and need strong security of processing. |
Where personal data is in scope, align stronger authentication and logging with Art.32 security obligations.
Key terms
- Phishing-resistant MFA: Authentication that cannot be replayed on a fake login page because the factor is cryptographically bound to the real domain. In practice, this usually means passkeys or hardware security keys, which are stronger than OTP-based methods for healthcare access and privileged workflows.
- Step-up authentication: A risk-based pattern that asks for stronger verification only when a session becomes more sensitive. Healthcare teams use it to protect privilege changes, data exports, unusual devices, and remote access without turning every clinical login into a high-friction event.
- Addressable specification: A control that may be implemented, replaced with an equivalent alternative, or documented as not reasonable and appropriate in the environment. In healthcare identity governance, addressable logic is often where weak authentication decisions survive longer than they should.
What's in the full article
Authsignal's full blog post covers the operational detail this post intentionally leaves for the source:
- A practical breakdown of how the proposed HIPAA MFA rule maps to healthcare access patterns across workforce, vendor, and patient-facing systems.
- Specific guidance on passkeys, hardware keys, TOTP, and SMS fallback choices for different healthcare workflows.
- The compliance timing model, including the proposed effective date, transition windows, and what teams should document before final publication.
- Implementation detail on using step-up authentication around risk events such as device changes, data exports, and privileged actions.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on 2026-06-19.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org