Passwordless Authentication in Healthcare

I recommend passkeys for routine healthcare sign-ins, hardware keys for higher-risk access, and email magic links only for low-risk tasks. Choose based on who needs access, what they can do, and how they work - not the tool alone.

Here’s how I’d approach the rollout:

• Match the method to the user: Plan for patients, caregivers, clinicians, vendors, and older systems. Biometrics can activate a passkey or key; they aren’t a separate sign-in method.
• Protect sensitive access: Use phishing-resistant methods, named accounts, and added checks for higher-risk actions. Passwordless does not automatically mean MFA or HIPAA compliance.
• Plan for failures: Test lost devices, recovery, outages, and time-limited emergency access. Provide options that don’t require biometrics or a personal smartphone.
• Measure before expanding: Compare sign-in time, failed attempts, support requests, and care interruptions during a pilot.

My bottom line: <u>protect patient data without slowing care</u>. Start with a small pilot, check results by role and device, and expand only when access, recovery, and clinical workflows work together.

Authenticate2020 Presentation: Journey towards Passwordless Authentication at CVS Health

sbb-itb-535baee

Passwordless Methods for Healthcare

Choose each method based on the workflow, enterprise risk profile, and the assurance level it supports.

Passkeys and Local Biometric Checks

Use passkeys for patient portals, clinician SSO, and remote access where WebAuthn is supported. Passkeys use WebAuthn/FIDO2 public-key credentials: the service stores the public key, while the authenticator protects the private key. Synced passkeys can make device replacement easier. Device-bound credentials offer tighter control, but they need replacement if lost.

Approve passkey providers and manage workforce devices used for passkey issuance. Use credential attestation only when the assurance level requires it. Verify account ownership before enrollment, notify users of credential changes, and require re-enrollment after device loss.^{[5][8][10][13]} Use hardware keys for higher-risk access.

Biometrics unlock the authenticator; they do not prove that the account belongs to the enrolled person. Keep biometric templates protected locally whenever possible, and avoid unnecessary collection or retention by the healthcare organization. NIST specifies a false-match rate of 1 in 1,000 or better for relevant biometric configurations. Offer PIN or approved hardware alternatives for users affected by gloves, wet hands, injuries, masks, or accessibility barriers.^[7]

Hardware Keys for Sensitive Access

FIDO2 security keys keep credentials non-exportable. They suit administrators, clinical-system support teams, and vendors with elevated access. Require PIN or biometric activation where supported, and enforce that verification in the authentication policy. Before issuing keys, check compatibility with thin clients, remote desktops, mobile devices, and clinical applications. Carrying a key may not be practical for some patients.^[6][8]

Verify identity before registration and assign each key to a named individual. Track ownership, serial numbers, issuance, and revocation. Maintain a controlled spare-key process, and revoke lost or returned keys immediately. For vendors, limit privileges and access windows, and review key ownership during access recertification.^[8][13] Keep magic links for low-risk, one-time tasks.

Magic Links for Lower-Risk Tasks

Use magic links for appointment tasks, enrollment initiation, and other narrowly scoped access. Their security depends on the receiving mailbox and its account controls. They do not independently prove patient or caregiver identity, and email is not a valid out-of-band factor under NIST guidance.^[7]

Use short-lived, single-use tokens, TLS, rate limits, and session binding where feasible. Keep PHI out of URLs and tokens out of logs. To account for forwarding and mail scanners, require deliberate confirmation instead of granting access on the first request.

Require stronger checks before contact changes or access to sensitive records. Never use magic links alone for privileged administration, high-risk clinical actions, or sensitive vendor work.^[7][11][12]

Choose Methods by Access Context

Choose methods based on application support, risk, and accessibility. Document support for WebAuthn, federation, badge taps, device management, and audit logging.

Step-up authentication must add independent assurance. Another email link does not increase assurance.^[14] Use the table below to match each method to the workflows it supports.

The sections below explain the edge cases and controls behind each row.

Patient Portals and Caregiver Access

Give caregivers separately authorized proxy accounts with permissions that can be reviewed independently. On shared devices, require sign-out, session expiration, and reauthentication for sensitive actions.

Before sensitive record access or recovery, apply identity proofing that matches the risk. Limit magic links to low-risk tasks. Offer accessible, supervised alternatives without needlessly delaying patients’ access to their records.

Clinician Sign-In and Clinical Systems

In clinical settings, fast access matters only if each action remains tied to the right person through every handoff. Map EHR, PACS, pharmacy, e-prescribing, VPN, VDI, and admin-console access to supported SSO and authentication integrations. The goal is fast access without losing individual accountability.

Badge taps can unlock a workstation or identify a user, but they do not, by themselves, provide MFA or phishing resistance. General SSO also does not automatically meet controlled-substance prescribing rules. Check it against federal, state, payer, and organizational requirements.

For legacy applications, use an identity-aware gateway, federation broker, VDI layer, or segmented access path where feasible. Restrict direct access and monitor privileged sessions. Document any remaining passwords, affected users, the risk owner, compensating controls, residual risk, and replacement date.

Keep emergency access time-limited, logged, and subject to review. It must not depend on unmanaged shared accounts.

Vendor Access and Third-Party Risk

Require phishing-resistant authentication for privileged or sensitive remote access. Manage third-party vendor security risks with named accounts, least privilege, defined access windows, and prompt offboarding.

Plan, Test, and Deploy Passwordless Access

Choose a method for each access context, then test it in a pilot before rolling it out broadly. Clinical leadership owns workflow and downtime requirements. Security owns assurance and recovery.

Assign an executive sponsor, clinical safety owner, IAM lead, application owners, and leads for privacy, accessibility, service desk support, and vendor access. Budget for integration, issuance, enrollment, training, replacement, and support. Don't count password-reset savings until pilot data prove them.

Map Access and Set Assurance Levels

Expand the access inventory to cover service accounts, clinical interfaces, device ownership, session length, and downtime dependencies. Set assurance requirements based on PHI exposure, patient-safety impact, privilege, and device trust. Check WebAuthn/FIDO2 support separately from SAML or OpenID Connect integration. Federation alone does not make sign-in phishing-resistant.

Before enrollment, define identity proofing, authenticator registration, session and logout rules, revocation, and exceptions. Keep nonhuman accounts on a separate credential path.^[4][3][9] Then define what happens when enrollment, devices, or identity systems fail.

Plan Recovery and Emergency Access

Test recovery for lost keys, replacement phones, failed biometric sensors, inaccessible email, lockouts, role changes, termination, or separation. Require verified identity, recovery logging, user notification, and revocation of missing authenticators. Personal details supplied by a caller must not authorize credential replacement. Recovery must restore access without creating a way around identity controls.

Keep recovery separate from emergency access. Document what remains available during identity-provider and EHR outages. An alternate sign-in method cannot restore an unavailable clinical app. Assign someone to review emergency-access records and confirm that temporary access ends.^[4][11][15]

Test Workflows and Measure Results

Pilot the workflow under real clinical conditions - not just a successful login. Include clinicians across shifts, patients, caregivers, administrators, and vendor-access owners. Test PPE use, accessibility, biometric opt-out, workstation handoffs, degraded connectivity, and recovery. Train users and help-desk staff before launch.

Measure whether the workflow helps or disrupts care. Compare baseline and pilot results for enrollment completion, adoption, sign-in time, failure rate, help-desk contacts, recovery time, break-glass events, audit-log completeness, and care interruptions. Break down results by role, unit, device type, and authentication method.

Set expansion and rollback criteria before testing: no unresolved safety issues, complete privileged-access audit trails, peak-workflow performance within set limits, and support demand within capacity. Review expiring exceptions at each rollout stage.

Compare Methods After the Pilot

Use pilot results to confirm which method fits each access pattern. The categories overlap: a passkey can reside on a hardware key, and biometrics only unlock the authenticator.^[3][4] Compare implementation demands in the table before expanding. Under NIST guidance, synced authenticators can support AAL2, but they cannot achieve AAL3 because their keys are exportable.^[16]

Conclusion: Match Security to Clinical Workflows

Protect PHI without slowing care: match phishing-resistant authentication to access risk, clinical workflows, and recovery needs. Keep each user accountable through a named account. Use clinical pilot results and regular risk reviews to decide where passwordless access should expand next, rolling it out in phases.

Passwordless Readiness Checklist for Rollout and Review

• Governance and technology: Approve authentication and identity-proofing methods based on risk. Give each legacy exception an owner and expiration date, and test SSO, enrollment, and privileged-access controls. Use standardized risk assessment questions to evaluate these controls consistently.
• Clinical operations: Confirm that each clinician signs in separately on shared workstations. Train staff on sign-in, recovery, and downtime procedures. Keep emergency access logged, time-limited, and subject to review.
• Patient access: Offer accessible options that don’t require biometrics, keep caregiver and proxy permissions separate, and use short-lived, single-use magic links.
• Vendor access and continuous monitoring: Require named accounts, sponsor approval, least privilege, and prompt access revocation. Regularly review logs, recovery activity, overrides, and risk assessments, with Censinet RiskOps™ supporting those assessments and continued risk tracking.

FAQs

How do we choose passwordless methods for each healthcare role?

Start with risk: map the workflows that access protected health information, then choose authentication methods that fit each role and work setting.

For clinicians using shared workstations, badge taps or biometrics can ease sign-in. High-risk actions require step-up MFA, such as hardware security keys. Patient portals typically use passkeys, while machine-to-machine traffic requires mutual TLS or X.509 certificates.

Limit access by role using least privilege, provide emergency fallback options, and pair passwordless methods with a second factor.

What evidence supports HIPAA compliance after going passwordless?

Evidence includes individual user identification, strong authentication through MFA or identity proofing, encryption for ePHI, and complete audit logs. Censinet’s guidance stresses tying passwordless authentication to named users, limiting shared credentials, and using least-privilege access controls.

Protected logs or a SIEM should record enrollment, verification attempts, failures, administrative changes, emergency or fallback use, and exports. These records support monitoring and forensics. ^[1][2]

How can we prevent account recovery from becoming a security gap?

Plan how to revoke authenticators, provide fallback access, and issue secure replacements. Test every recovery path before deployment, and don’t use shared fallback passwords. If an account is compromised, revoke all linked authenticators and keep a clear record of each person’s actions.

Require step-up verification for high-risk actions, including changes to authentication settings or MFA methods. Track all recovery attempts in one place and audit them. Log what triggered each attempt, its outcome, and the personnel involved.

Related Blog Posts

• HIPAA Compliance and Biometric Data in Clinical Apps
• How MFA Prevents Email Phishing in Healthcare
• How Digital Identity Protects Patient Data
• Checklist for MFA Implementation in Healthcare Clouds