Multi-factor authentication

Factors must come from different categories

Common categories are something a person knows, something a person has, and something a person is. A password plus another password remains one factor category. Security questions plus a PIN do too.

An authenticator app, hardware security key, passkey, or device-bound credential can provide possession evidence. Biometrics often unlock an authenticator on a device rather than travel to every application. Document what each product actually verifies.

Phishing resistance changes the quality of MFA

Attackers can trick people into entering passwords and one-time codes on a fake site or approving an unexpected push. CISA's fact sheet recommends phishing-resistant MFA and identifies FIDO/WebAuthn and public-key infrastructure approaches.

Select methods based on risk, vendor support, workforce needs, accessibility, device model, and recovery. SMS or push approval may be a transitional control for some systems, but labeling every method “MFA” hides meaningful differences.

Start with the highest-risk access

Prioritize administrators, email, identity providers, remote access, cloud consoles, billing, payroll, clinical records, file storage, code repositories, and vendor support. Inventory human accounts, shared accounts, service accounts, emergency accounts, and integrations.

For each system, record:

• users and roles, data, business impact, and owner
• supported authenticators and phishing-resistance level
• enrollment, identity proofing, device binding, and replacement
• recovery, help-desk verification, backup method, and emergency access
• exception reason, approver, compensating controls, expiration, and review
• logs, alerts, failed attempts, anomalous prompts, and incident route

Close shared accounts where individual accountability is needed. Protect service accounts with suitable noninteractive credentials, scoped permissions, rotation, and monitoring instead of pretending they can answer a phone prompt.

MFA authenticates; authorization still controls access

MFA helps establish that a claimant controls multiple authenticators. It does not decide whether that person should access a client, export records, change payroll, approve a claim, or administer the system.

Current 45 CFR 164.312 separately addresses access control, audit controls, integrity, person or entity authentication, and transmission security for ePHI. A successful second factor cannot repair excessive permissions or a stale workforce account.

A fictional coverage review

Mei's practice identifies 42 workforce users who are due for phishing-resistant MFA. Thirty-eight have completed enrollment and a recovery test: 38 of 42, or 90.5%.

Two users need accessible hardware. One vendor application lacks support. One emergency account has an expired review. All four stay visible with owners, interim controls, and dates. The percentage measures coverage of this cohort, not protection from compromise.

Secure enrollment and recovery

Account recovery can bypass strong authentication. Verify identity before adding or replacing an authenticator. Notify the account owner through an independent channel. Log enrollment, removal, reset, recovery, and failed attempts.

Prepare for lost devices, staff travel, device replacement, an unavailable identity provider, and a clinical emergency. Emergency access should be limited, monitored, tested, and reviewed after use. A bypass code sitting in a shared document defeats the design.

Make authentication usable. Offer accessible methods and more than one supported authenticator where feasible. Avoid forcing staff to share personal devices without a clear workforce policy, reimbursement analysis, support plan, and approved alternative.

Design for field and shared-device work

ABA staff may move between homes, schools, centers, community settings, and unreliable networks. Test sign-in on the actual managed devices and connectivity patterns. Decide how staff authenticate when a phone is replaced, a security key is unavailable, or the network is intermittent. Preserve a secure path for urgent access while the support desk is closed.

Shared clinical devices need individual sign-in, fast user switching, protected sessions, and reliable logout. A shared device should not lead to a shared identity. Decide whether authenticators can be registered on more than one approved device, how backup authenticators are stored, and how a departing worker's registrations are removed. Include contractors, trainees, temporary staff, and vendor support in the same lifecycle inventory.

Record help-desk hours and escalation contacts for every site and shift.

Measure the due cohort

Useful measures include users with the required method divided by users due, privileged accounts reviewed by target divided by privileged accounts due, recovery tests passed divided by tests due, and exceptions closed by date divided by exceptions due. Report aged exceptions and unsupported systems separately.

NIST SP 800-63-4 provides federal digital-identity guidance covering identity proofing, authentication, and federation. The NIST Cybersecurity Framework offers voluntary outcome-based risk guidance. Neither source certifies a practice's configuration.

Close every exception through a dated decision: enroll an accessible approved method, replace the unsupported system, apply time-limited compensating controls, or accept a documented residual risk through the authorized process. Retest recovery and emergency access after each change.