MFA for Healthcare: Where It Matters Most and Where Clinics Get It Wrong

The Control That Stops the Most Common Breach

If you could deploy exactly one security control across a medical or dental practice, multi-factor authentication (MFA) would be the one to choose. The reason is simple: the overwhelming majority of breaches that hit small healthcare practices begin with a stolen or guessed credential. A phishing email harvests a password. A password reused across personal and work accounts shows up in a data dump. An attacker sprays common passwords against an exposed login portal. In each case, MFA is the control that turns a stolen password from a full compromise into a failed login attempt.

The current HIPAA Security Rule does not name MFA explicitly — it predates the modern threat landscape — but it requires “reasonable and appropriate” technical safeguards for access control and authentication. The HHS/OCR proposed updates to the Security Rule, published in early 2025, would make MFA far more explicit as an expected control. HHS has stated that the current Security Rule remains in effect while that rulemaking proceeds, but the direction of travel is unmistakable: regulators, cyber insurers, and auditors increasingly treat MFA as a baseline rather than an enhancement.

The encouraging part is that MFA is no longer hard to deploy. The challenge for clinics is not implementing it — it is implementing it everywhere it matters and avoiding the predictable gaps.

Where MFA Matters Most

Not all accounts carry equal risk. A practice with limited time and budget should prioritize MFA in roughly this order.

The Electronic Health Record (EHR)

The EHR is where the most concentrated ePHI lives, so it is the highest-value target and the highest priority for MFA. Many cloud-hosted EHR platforms now support MFA natively or through an identity provider — but the feature is frequently left disabled because it adds a step to clinical workflow. That friction is real, but the trade-off favors enabling it. Look for EHR MFA options that support push notifications or hardware tokens rather than SMS, and pair them with reasonable session timeouts so providers are not re-authenticating constantly during a shift.

Microsoft 365 and Google Workspace

Email and the productivity suite are the second priority, and often the most overlooked. A compromised mailbox is a launching pad: attackers use it to read PHI sitting in old emails, to send convincing internal phishing, and to reset passwords on other services. Both Microsoft 365 and Google Workspace offer robust MFA and conditional access at no meaningful extra cost. Enabling MFA tenant-wide — and turning off legacy authentication protocols that bypass it — closes one of the most exploited doors in healthcare IT.

VPN and Remote Access

Any remote access path into the practice network — a VPN, a remote desktop gateway, a remote-access appliance — must require MFA. These portals are exposed to the internet by design, which means they are constantly probed. A remote access portal protected only by a username and password is one credential leak away from giving an attacker a foothold inside the clinical network.

RMM and IT Management Tools

Remote monitoring and management (RMM) tools, which MSPs and internal IT use to administer endpoints, are powerful by design — they can push software, run scripts, and reach every managed device. That power makes them a prime target. RMM consoles, and the administrator accounts that access them, must have MFA enforced without exception.

“The accounts most likely to be skipped for MFA are the ones that hold the most power: the global administrator, the backup console login, the vendor portal. Attackers know this, and they go straight for them.”

Backup Consoles

A ransomware attacker’s first objective, after gaining access, is often to destroy or encrypt backups so the victim cannot recover without paying. The backup console — whether cloud-based or on-premises — is therefore a critical account to protect with MFA. A practice that has solid backups but an unprotected backup login has a single point of failure that defeats the entire recovery strategy.

Vendor and Payer Portals

Billing clearinghouses, payer portals, lab interfaces, and pharmacy systems frequently contain or transmit PHI, and they are accessed with credentials that often go unmanaged. Where these portals support MFA, enable it. Where they do not, that is a vendor risk worth documenting and raising.

Passkeys and Passwordless: The Strongest Form of MFA

A passkey is cryptographically bound to the website it was created for. If a clinician is lured to a convincing fake login page, the passkey simply won’t work there — even a perfectly crafted fake captures nothing useful.

Most of this post assumes the familiar model: a password plus a second factor. But the direction the entire industry is moving — and the form of authentication clinics should understand now — is passwordless login using passkeys. Rather than bolting a second factor onto a password, passkeys remove the password from the equation entirely and replace it with something far harder to steal.

What a Passkey Actually Is

A passkey is a credential based on public-key cryptography. When you create one, your device generates a pair of keys: a private key that never leaves the device (stored in secure hardware, such as a phone’s secure element, a laptop’s TPM, or a hardware security key), and a public key that is registered with the service you’re logging into. To sign in, the service sends a challenge, your device signs it with the private key after you unlock it — typically with a fingerprint, face scan, or device PIN — and the service verifies the signature with the public key. No shared secret is ever transmitted or stored on the server.

In practical terms, a passkey combines two factors into one smooth step: something you have (the device holding the private key) and something you are or know (the biometric or PIN that unlocks it). For a clinician, signing in can be as simple as a fingerprint touch — no password to type, no code to copy from a phone. Passkeys are built on the FIDO2/WebAuthn standards, and they’re now supported across major platforms and a growing number of healthcare-relevant systems: Microsoft 365, Google Workspace, and an increasing number of EHR and identity providers.

How Passkeys Help

The security gains are substantial, and several of them directly address the gaps described elsewhere in this post.

They’re phishing-resistant by design. This is the headline benefit. A passkey is cryptographically bound to the specific website it was created for. If a clinician is lured to a convincing fake login page, the passkey simply won’t work there — the domains don’t match, so the device refuses to sign the challenge. This neutralizes the single most common attack on healthcare practices: credential phishing. Even a perfectly crafted fake page captures nothing useful.

There’s no shared secret to steal. Because the private key never leaves the device and the server only holds a public key, there is no password database to breach, no reusable secret to dump, and nothing for an attacker to replay. A breach of the service provider doesn’t hand attackers a credential they can use.

They defeat the weaknesses of SMS and push. Passkeys aren’t vulnerable to SIM-swapping the way SMS codes are, and they aren’t susceptible to “MFA fatigue” attacks, where an attacker who already has the password spams a user with push prompts until they tap approve. There’s no prompt to approve and no code to intercept.

They reduce friction, which improves adoption. Security controls that slow clinicians down get worked around. A fingerprint touch is faster than typing a password and waiting for a code, which means passkeys can actually be easier to live with than the MFA they replace — a rare case where the more secure option is also the more convenient one.

The Strengths, Plainly

• Phishing-resistant — the strongest practical defense against the attacks that hit clinics most.
• No reusable secret — nothing to steal in transit or in a server breach.
• Resistant to SIM-swap and MFA-fatigue attacks.
• Fast and low-friction, which drives real-world adoption.
• Standards-based (FIDO2/WebAuthn) and increasingly supported across the systems a practice already uses.

The Weaknesses and Trade-offs to Plan For

Passkeys are excellent, but they are not magic, and a practice should go in with clear eyes.

Uneven support. Not every system a clinic relies on supports passkeys yet — some older EHRs, niche clinical applications, and vendor or payer portals still require passwords. You will likely run a hybrid environment for some time, with passkeys where supported and strong traditional MFA everywhere else.

Account recovery becomes the critical question. With passwords, recovery is easy (and, as noted later, often dangerously weak). With passkeys, you must plan for the lost or replaced device: what happens when a clinician drops their phone in the parking lot? The answer is to register more than one authenticator — a second device or a hardware security key as backup — and to design a recovery process that is convenient enough to use but strong enough that it doesn’t become the new weak link. A poorly designed passkey recovery path can quietly reintroduce the very phishing risk passkeys were meant to eliminate.

Device dependency and shared workstations. Passkeys are tied to devices, which complicates environments where staff share a single workstation or rotate through machines. Synced passkeys (backed up to a platform account and available across a user’s devices) ease this, but introduce a dependency on the security of that platform account — which itself must be strongly protected. Device-bound passkeys (such as those on a hardware key) don’t sync, which is more secure but less flexible. Choosing between them is a real decision for a clinical environment.

Lifecycle and management overhead. Onboarding, offboarding, and managing passkeys across a workforce requires process and, ideally, an identity provider that supports them well. For a small practice, this is very manageable — but it is not zero effort, and it’s worth treating as a deliberate project rather than a switch you flip.

The sensible posture for most practices in 2026 is to adopt passkeys where they’re well supported — especially on email, the productivity suite, and any EHR or identity provider that offers them — while keeping strong traditional MFA in place for everything that isn’t ready yet. Passkeys are where authentication is heading, and getting comfortable with them now positions a practice well for where both the threat landscape and HIPAA expectations are going.

Where Clinics Get It Wrong

Deploying MFA is only half the work. These are the recurring mistakes that undermine it.

Relying on SMS as the only factor. Text-message codes are far better than no MFA, but they are vulnerable to SIM-swapping and interception. For high-value accounts — EHR, email admin, backup console, RMM — prefer an authenticator app with push or number-matching, or hardware security keys. Reserve SMS for lower-risk accounts or as a fallback.

Leaving admin accounts exempt. A common pattern: MFA is rolled out to clinical staff but the global administrator account, used “only occasionally,” is left exempt for convenience. That account can disable MFA for everyone else. It needs the strongest protection in the building, not the weakest.

Forgetting service and shared accounts. Shared logins at the front desk, generic accounts used by multiple staff, and service accounts that run integrations often slip through MFA rollouts because they do not map cleanly to one person. These need a deliberate plan — ideally elimination of shared accounts in favor of named users, and conditional access policies for service accounts.

Skipping the recovery path. If MFA is enforced but the account recovery process is weak — a help desk that resets MFA on a single phone call, security questions with guessable answers — attackers will simply target the recovery path instead. Recovery procedures must be as strong as the primary control.

Treating “MFA is on” as the finish line. MFA coverage drifts. New applications get added without MFA. Exemptions granted “temporarily” become permanent. Without periodic review, a practice that was fully covered a year ago can develop gaps. MFA coverage belongs in the regular security review.

A Practical Rollout Sequence for a Small Practice

1. Enforce MFA on email and the productivity suite first — tenant-wide, with legacy authentication disabled. This is fast, low-cost, and closes the most exploited door.
2. Enable MFA on the EHR, using push or token methods, with sensible session timeouts to protect clinical workflow.
3. Require MFA on every remote access path — VPN, remote desktop gateway, remote-access appliances.
4. Lock down the powerful accounts — global administrators, RMM consoles, backup consoles — with the strongest available factors.
5. Inventory vendor and payer portals and enable MFA wherever supported; document the ones that don’t.
6. Adopt passkeys where they’re well supported — starting with email and the productivity suite — and register backup authenticators so device loss doesn’t lock anyone out.
7. Schedule a recurring review of MFA coverage as part of your ongoing security program.

The Byzantine Takeaway

MFA is the highest-leverage security investment a healthcare practice can make, and the current direction of HIPAA rulemaking only reinforces that. But the value is in the coverage, not the checkbox. The EHR, email, remote access, administrator accounts, backup consoles, and vendor portals are where it matters most — and the admin account left exempt “for convenience” is exactly where attackers look first. Get MFA everywhere that matters, prefer strong factors over SMS for high-value accounts, protect the recovery path, and review coverage on a schedule. Do that, and you have neutralized the most common way small practices get breached.