Authentication and Identity for Patients and Providers

This is engineering guidance, not legal advice. Confirm specifics with qualified counsel.

Why this matters

Authentication is the front door to every piece of protected health information your platform holds, and attackers know it: stolen or weak credentials are the leading way health-care systems get breached. For a telemedicine product the stakes are doubled, because the same login also decides whether the person on the video call is really the patient and whether the clinician is really licensed to be there. Get it wrong and you face a reportable breach, a failed audit, and — in the worst case — care delivered to or by the wrong person. This article is for founders, product managers, and engineering leads who need to make concrete decisions about login, identity proofing, and recovery without a security PhD. It is the security-focused companion to our integration-focused article on identity, SSO, and provider directories.

Two questions, not one: identity versus authentication

Start by separating two ideas that everyday language blurs together. Identity proofing is the one-time act of establishing who a person is when they first get an account — the equivalent of a bank checking your passport before opening an account. Authentication is the repeated act of confirming, at each login, that the person at the keyboard is the same person the account belongs to — the equivalent of typing your PIN every time you use the card.

You can be strong on one and weak on the other, and the failure modes are different. A platform that proofs identity rigorously but then protects the account with only a guessable password has a strong front door with a flimsy lock. A platform that demands a hardware key at every login but let anyone create the account with a fake name has a great lock on a door that was never the right door. Healthcare needs both calibrated on purpose.

The US government's guideline for doing this is NIST Special Publication 800-63, "Digital Identity Guidelines," whose fourth revision (SP 800-63-4) was finalized in July 2025 after nearly four years and 6,000 public comments. It gives you three dials:

• Identity Assurance Level (IAL) — how confident you are about who someone is. IAL1 is self-asserted ("I say I'm Jane"); IAL2 requires real evidence, like a government ID checked against the person.
• Authenticator Assurance Level (AAL) — how confident you are that the right person is logging in. AAL1 is a single factor (a password); AAL2 requires two different factors; AAL3 requires a hardware-based, phishing-resistant factor.
• Federation Assurance Level (FAL) — how strongly a login handed off from another system (say, a hospital's single sign-on) can be trusted. This matters most for providers and is covered in depth in our identity and SSO article.

HIPAA itself names the requirement but not the level. The Security Rule's "person or entity authentication" standard (45 CFR §164.312(d)) requires you to "verify that a person or entity seeking access to electronic protected health information is the one claimed" — it tells you that you must authenticate, and leaves the strength to your risk analysis. NIST is how you decide what "strong enough" means.

Figure 1. Identity proofing answers "who are you" once; authentication answers "prove it" every time. Patients and providers sit at different assurance levels for both.

Proofing the patient: enough, not too much

For patients, the goal is to be confident enough that the right person reaches the right record without making sign-up so painful that people give up before their first visit. Most direct-to-consumer telemedicine sits at IAL1 with a verified contact channel: the patient self-asserts their name and date of birth, confirms a working email and phone, and that is the account. The real identity check happens later, when the clinical and billing data must be tied to a specific human — matching the new account to an existing medical record, or verifying insurance, is where stronger proofing kicks in.

Two pitfalls deserve a callout. First, knowledge-based verification is no longer acceptable as a primary check. Asking "which of these streets did you live on?" — questions sourced from credit files — was standard for years. SP 800-63-4 deprecates it, because the underlying data has been breached so many times that the answers are often easier for an attacker to find than for the real patient to remember. Replace it with a document check or a verified channel, not trivia.

Second, identity matching is a safety problem, not just a security one. When a patient self-registers and your system links them to the wrong existing record — a different Jane Smith with the same birth month — you have not leaked data to an outsider; you have shown one patient another patient's history. Telemedicine platforms that connect to a hospital record system should treat patient matching as a clinical-safety control, with a human review step when the match is uncertain.

For higher-risk services — remote prescribing, mental-health care, anything where impersonation has serious consequences — step up to IAL2, where the patient presents a government ID that is checked, often by photographing the ID and a selfie that are compared. Reserve this for where it is warranted; applied to every routine cold-and-flu visit, it just lowers completion rates.

Proofing and authenticating the provider: the higher bar

Providers are the higher-value target — one compromised clinician account can reach hundreds of patients' records — so both dials turn up. Identity proofing for a clinician is rarely a selfie; it is verification against authoritative sources: a checked medical license, the national provider registry, and credentialing through the hospital or group. Our identity and SSO article covers how that verification and the provider directory are wired; here we focus on the login itself.

In almost every serious deployment, providers do not get a username and password on your platform at all. They log in through their organization's single sign-on (SSO) — the hospital's own identity system — using standards like SAML or OpenID Connect, and your platform trusts that login. This is better security and better experience: the hospital enforces its own MFA and can switch off a departed clinician's access in one place. The trade-off is that your assurance now depends on theirs, which is exactly what the Federation Assurance Level measures.

One provider workflow has a legally fixed authentication floor: electronic prescribing of controlled substances (EPCS). The Drug Enforcement Administration's rules (21 CFR §1311.115) require two-factor authentication before a controlled-substance prescription can be signed, using two of three categories — something you know, something you have, something you are — with the "have" factor meeting a hardware or cryptographic standard. If your telemedicine product prescribes controlled substances, this is not a design choice; it is a federal requirement, detailed in our e-prescribing and EPCS article.

Multi-factor authentication and the 2026 proposal

Multi-factor authentication (MFA) means proving identity with at least two different kinds of evidence: something you know (a password), something you have (a phone or hardware key), or something you are (a fingerprint or face). The point is that an attacker who steals one factor — say, a reused password from another breach — still cannot get in.

Today, HIPAA's Security Rule treats most safeguards as either "required" or "addressable," and authentication strength falls under the flexible "addressable" category — you must address it, but you choose how based on your risk analysis. That is poised to change. On December 27, 2024, HHS's Office for Civil Rights issued a proposed rule — the first Security Rule update since 2013 — that would, among many changes, require multi-factor authentication for nearly all systems that access electronic protected health information and largely remove the "addressable" escape hatch. The agency's stated motivation is stark: large breaches rose 102% from 2018 to 2023, the number of people affected rose more than 1000%, and 2023 set a record with over 167 million individuals affected, capped by the Change Healthcare breach — the largest in US health-care history.

The critical caveat: this rule is still a proposal as of June 2026, not final law. The comment period closed in March 2025; a final rule is widely expected during 2026 but has not been published, and the existing Security Rule remains in effect until it is. The right engineering posture is to build MFA in now — it is already best practice, your security-conscious customers already demand it, and it would put you ahead of the rule — while writing any compliance claim as "the proposed 2026 update would require MFA," never as settled law. We treat this the same way across our HIPAA Security Rule 2026 article.

Not all second factors are equal

The biggest practical decision is which second factor, because they differ enormously in how well they resist phishing — the attack where a fake login page tricks a user into handing over their code. The ladder, weakest to strongest:

SP 800-63-4 explicitly recognizes passkeys (the consumer-friendly form of the FIDO2/WebAuthn standard) as phishing-resistant, and they are the most important shift in this table. A passkey is a cryptographic credential stored on the patient's phone or laptop and unlocked with their fingerprint or face; because it is mathematically tied to your real domain, a fake look-alike site cannot use it. For patients, a passkey is often easier than a password — no code to type — while being far stronger. For staff and prescribers, hardware security keys remain the gold standard at AAL3.

A common mistake is to treat "we have MFA" as a finished checkbox. SMS codes are MFA, and they are dramatically better than a password alone, but they are also the most phishable and hijackable second factor; NIST has discouraged SMS for years. Offer it as a fallback for patients who cannot use anything else, and steer everyone toward passkeys.

Figure 2. The authenticator ladder: SMS is the weakest second factor and hardware keys the strongest. Phishing-resistant factors — passkeys and hardware keys — are the goal.

Assurance levels meet the clinic: the session-timeout tension

Choosing an AAL is not only about login; it carries rules about how long a session may stay open before the user must prove themselves again. NIST sets these timeouts precisely, and they collide with how clinics actually work.

At AAL2 — the right baseline for most clinical access — a session must be re-authenticated at least once every 12 hours regardless of activity, and after any 30 minutes of inactivity the user must log in again. At AAL3, the inactivity window tightens to about 15 minutes, and re-authentication must use both factors. These are not arbitrary: a logged-in session left open is a door left unlocked.

Here is the tension. A clinician seeing patients all day on a shared workstation will hit a 15-minute inactivity logout constantly, and the predictable human response to friction is to defeat it — propping sessions open, sharing logins, taping a badge over the proximity reader. Security that clinicians route around is worse than security calibrated to their reality. The fix is not to weaken the timeout but to make re-authentication nearly frictionless: tap-to-unlock proximity badges, passkeys that re-auth with a fingerprint in under a second, and "fast user switching" so a shared exam-room machine logs one clinician out and the next one in without a full restart. Set the assurance level by risk, then spend engineering effort making the resulting re-auth painless.

A worked example of the inactivity math, to make it concrete. Suppose a clinical workstation enforces a 15-minute inactivity timeout (AAL3) and a clinician steps away for documentation 18 times in an 8-hour shift. Without a fast re-auth path, each return costs a full password-plus-code login of, say, 25 seconds:

18 logins/day × 25 seconds = 450 seconds = 7.5 minutes/day of pure login friction

Multiply across a 30-clinician practice and you lose nearly four clinician-hours a day to logins — which is exactly why those clinics defeat the timeout. Swap the 25-second login for a 2-second passkey or badge tap and the same 18 re-auths cost 36 seconds total. The timeout stays compliant; the friction nearly vanishes. The lesson: assurance level is a security decision, re-auth speed is an engineering decision, and you need both.

Step-up authentication for the sensitive moments

Not every action inside a telemedicine app carries the same risk, so not every action needs the same proof. Step-up authentication asks for an extra factor only at the moment a user does something sensitive — signing a prescription, exporting a full record, changing the bank account that receives payments — even though they are already logged in. The everyday session stays light; the dangerous actions get a fresh, strong check.

This pattern resolves much of the timeout tension. You can run a comfortable AAL2 session for ordinary browsing and consults, then demand a phishing-resistant re-auth precisely when a prescriber signs a controlled-substance order (which the EPCS rule requires anyway). It also limits blast radius: if a session is somehow hijacked, the attacker still cannot perform the highest-risk actions without passing the step-up.

Account recovery: the door everyone forgets to lock

Here is the hardest truth in this article: your account-recovery flow is usually the real authentication strength of your system, because an attacker will simply attack the weakest path in. You can mandate hardware keys and passkeys, but if "I lost my phone" lets someone reset the account with a date of birth and the last four digits of a Social Security number — both of which are in countless breach dumps — then your true assurance level is whatever recovery requires, not whatever login requires.

Two rules keep recovery from becoming the side door.

First, recovery must match the assurance of the account it restores. If providers authenticate at AAL2 or higher, recovering a provider account must clear a comparable bar — ideally re-proofing through the hospital's IT desk or the SSO provider, not a self-service form. For patients, recovery can be lighter but should still use a verified channel established at sign-up, never a knowledge-based quiz.

Second — and this is the telemedicine-specific trap — recovery messages must never leak protected health information. A "reset your password" email or SMS that says "regarding your dermatology appointment with Dr. Lee" has just disclosed a health condition, a provider, and a specialty to whoever holds that inbox or phone, which may not be the patient. Remember, protected health information is any health detail tied to an identifiable person; an appointment specialty qualifies. Keep recovery and notification messages generic — "there is an update to your account, sign in to view" — and put the clinical detail behind the authenticated wall. This is a frequent finding in real breach investigations and an easy one to get right.

Figure 3. Account recovery is the weakest link attackers target. The safe pattern re-proofs the user and keeps all health detail behind the login; the leaky pattern reveals it in the recovery message.

Common mistakes

A short gallery of the authentication failures we see most in telemedicine builds, each avoidable:

• Treating SMS as "MFA, done." It is better than nothing and worse than everything else. Offer passkeys and treat SMS as the last-resort fallback.
• Proofing patients harder than the risk warrants. IAL2 selfie checks on a routine visit just lower completion. Match the proofing to the service.
• A recovery flow softer than the login. Hardware keys at login mean nothing if recovery accepts a breached date of birth. Equalize them.
• PHI in notification and recovery messages. "Your therapy session is confirmed" in an SMS is a disclosure. Keep messages generic.
• Ignoring the shared-workstation reality. A 15-minute logout with a 25-second login guarantees workarounds. Pair the timeout with sub-second re-auth.
• Letting a federated login (SSO) outrun your trust in it. If you accept a hospital's SSO, your assurance is theirs — verify their MFA, and design for prompt deprovisioning.

Where Fora Soft fits in

Telemedicine is one of the verticals Fora Soft has built since 2005, alongside video conferencing, streaming, e-learning, and surveillance, and authentication is where our real-time-video work meets the compliance layer. We design login and identity around the requirement first — person-or-entity authentication under 45 CFR §164.312(d), the assurance levels in NIST SP 800-63-4, the EPCS two-factor floor for prescribing, and the MFA direction of the proposed 2026 Security Rule — then choose the capability that meets it with the least friction for patients and clinicians. That means passkey-first patient login, SSO and step-up for providers, session timeouts calibrated to clinical workflow, and recovery flows audited for PHI leakage. The aim is a front door that auditors respect and that patients and clinicians do not fight.

What to read next

• Identity, SSO, and provider directories — the integration side of identity.
• The 2026 HIPAA Security Rule update for video — where the MFA mandate sits.
• Threat modeling a telemedicine platform — why credentials are the first thing attackers go for.

Call to action

• Talk to a telemedicine engineer — book a 30-minute scoping call to talk through your telemedicine authentication plan.
• See our case studies — 250+ shipped projects across video streaming, WebRTC, OTT, telemedicine, e-learning, surveillance, and AR/VR.
• Download the Telemedicine Authentication & Identity Readiness Checklist — One page, two columns: setting identity and authentication assurance levels for patients and providers, choosing phishing-resistant factors, calibrating session timeouts to clinical workflow, and closing the account-recovery gap without….

References

1. NIST, Special Publication 800-63-4: Digital Identity Guidelines (final, July 2025) — IAL/AAL/FAL framework, passkeys as phishing-resistant, deprecation of knowledge-based verification. https://pages.nist.gov/800-63-4 (Tier 1 — standards body)
2. NIST, Special Publication 800-63B-4: Authentication and Authenticator Management — AAL definitions, reauthentication and session timeouts (AAL2: 12 h / 30 min; AAL3: 12 h / 15 min, two factors). https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63B-4.pdf (Tier 1 — standards body)
3. HHS Office for Civil Rights, HIPAA Security Rule NPRM to Strengthen the Cybersecurity of ePHI, 89/90 FR (issued Dec 27, 2024; published Jan 6, 2025), RIN 0945-AA22, doc. 2024-30983 — proposed MFA requirement, removal of the addressable/required distinction, breach statistics. https://www.federalregister.gov/documents/2025/01/06/2024-30983/ (Tier 1 — proposed rule; not final as of June 2026)
4. HHS Office for Civil Rights, HIPAA Security Rule NPRM landing page and fact sheet — first Security Rule update since 2013; current rule remains in effect during rulemaking. https://www.hhs.gov/hipaa/for-professionals/security/hipaa-security-rule-nprm/index.html (Tier 1 — agency guidance)
5. 45 CFR §164.312(d), Person or entity authentication — Security Rule technical safeguard requiring verification of the person or entity seeking ePHI access. https://www.ecfr.gov/current/title-45/section-164.312 (Tier 1 — CFR)
6. 45 CFR §164.308(a)(5)(ii)(D), Password management — administrative safeguard for managing credentials. https://www.ecfr.gov/current/title-45/section-164.308 (Tier 1 — CFR)
7. DEA, 21 CFR §1311.115, Additional requirements for two-factor authentication (EPCS) — two-of-three factor requirement for signing controlled-substance prescriptions. https://www.ecfr.gov/current/title-21/section-1311.115 (Tier 1 — CFR)
8. W3C, Web Authentication (WebAuthn) Level 2 / FIDO Alliance passkeys — the cryptographic standard behind phishing-resistant passkeys. https://www.w3.org/TR/webauthn-2/ (Tier 3 — standards author)
9. NIST CSRC, NIST Revises Digital Identity Guidelines (SP 800-63-4) announcement, 2025 — confirms final release and key changes. https://csrc.nist.gov/News/2025/nist-revises-digitial-identity-guidelines-sp-800-6 (Tier 2 — agency announcement)
10. HHS, Change Healthcare Cybersecurity Incident FAQs — context for the largest health-care breach in US history, cited in the NPRM rationale. https://www.hhs.gov/hipaa/for-professionals/special-topics/change-healthcare-cybersecurity-incident-frequently-asked-questions/index.html (Tier 1 — agency guidance)

Where popular guidance disagreed with the rule, the rule won. Many vendor pages still describe SMS one-time codes as adequate "MFA"; NIST SP 800-63B (Tier 1) has discouraged SMS as a restricted authenticator for years, so this article steers toward phishing-resistant factors. Several articles also state that "HIPAA requires MFA" — as of June 2026 that is the proposed 2026 Security Rule, not the current rule (Tier 1 NPRM, ref 3), and the article frames it accordingly.