Multi-Factor Authentication and Recovery Codes for AFH Software

Multi-factor authentication can reduce account takeover risk for adult family home owners, caregivers, pharmacy users, and administrators, but only when enrollment, daily use, recovery, and removal are designed as one system. A second factor that users can bypass through weak recovery provides limited protection.

This guide covers authentication design, not a claim that one factor meets every organization's legal or contractual requirement. It was reviewed on August 8, 2026. Organizations should choose assurance and recovery controls through current risk analysis, privacy duties, device practices, and operational needs.

Define which roles require MFA

Evaluate owners, managers, caregivers, pharmacy users, billing users, support staff, and platform administrators separately. Consider access to:

• Resident records
• Medication orders and MAR
• Facility and caregiver administration
• Documents and exports
• Pharmacy relationships
• Subscription and payment settings
• Security configuration
• Support elevation

Require stronger authentication for broad, cross-facility, export, access-management, and administrative permissions. Offer MFA to all users even when rollout is phased.

Do not exempt shared workstations by creating a shared account.

Prefer phishing-resistant options

Support passkeys or security keys using WebAuthn when compatible with the user population and device environment. These cryptographic authenticators can bind authentication to the legitimate domain.

The current NIST SP 800-63B explains phishing resistance and recognizes WebAuthn/FIDO2 as an example using verifier-name binding. Passwords and manually entered one-time codes are not phishing-resistant.

Authenticator apps can remain a practical option, while SMS may be a constrained fallback under the organization's risk policy. Label strengths accurately rather than calling every second step equivalent.

Enroll authenticators inside a trusted session

Require recent primary authentication before enrollment. Display the account and facility role context, then bind the authenticator on the server through a challenge-response flow.

For TOTP enrollment:

• Generate a high-entropy secret
• Deliver it only over the authenticated protected session
• Verify one current code before activation
• Encrypt the secret at rest
• Never log the QR code or seed
• Prevent browser analytics from capturing the setup screen

For passkeys, store public credential data, user handle, authenticator metadata needed for policy, and enrollment time—not private keys.

Confirm enrollment with a notification

After adding or removing an authenticator, notify the user through an established channel. Include time, factor type, and how to report an unauthorized change.

Do not include QR codes, recovery codes, resident data, or exact security answers. A notification cannot itself undo the change through an unauthenticated predictable link.

Record delivery status and user-reported concerns in the security workflow.

Issue recovery codes securely

Generate saved recovery codes from a cryptographically secure source. NIST describes saved recovery codes as offline secrets that should be stored hashed, throttled on verification, invalidated after use, and replaced.

Show codes once after verified enrollment and encourage printing or secure offline storage. Do not email them automatically or keep a retrievable plaintext copy.

Each code should be single-use. After one is used, clearly show how many remain and prompt regeneration before the user is stranded.

Regeneration invalidates every old unused code and sends an account-change notice.

Design clear challenge selection

At sign-in, offer enrolled methods without revealing sensitive device detail to unauthenticated users. Remembered device labels should be user-readable but not trusted as authentication.

Support:

• Use passkey or security key
• Use authenticator app code
• Use a saved recovery code
• Begin the controlled recovery process

Do not let repeated “try another way” links silently fall back to email-only authentication for a privileged account.

Bind challenges to the current transaction

Use server-generated unpredictable challenges, short expiration, one-time consumption, expected account, and session binding. Rate-limit failures without disclosing whether a code was nearly correct.

For TOTP, accept only a narrow time window and prevent reuse of the same successful code where practical. Synchronize server time and monitor clock drift.

For WebAuthn, validate origin, relying-party ID, challenge, credential, signature, user presence, and required user verification.

Protect step-up authentication

Request a recent strong factor before high-impact actions:

• Invite or remove administrators
• Change recovery email
• Export a full facility
• Reveal or rotate integration credentials
• Regenerate pharmacy access codes
• Disable MFA
• Begin support impersonation
• Change subscription or payout settings

Bind the step-up result to the user, facility, action, and short time window. A recent sign-in to Facility Alpha should not authorize an unrelated sensitive change in Facility Beta automatically.

Handle trusted devices carefully

A “remember this device” option should create a revocable, protected device credential with a limited lifetime. Do not disable MFA forever through a browser cookie.

Show users their remembered devices and last activity, and let them revoke each one. Revoke trust after password reset, recovery, suspected compromise, role escalation, or administrator action as policy requires.

Shared caregiving devices should default to short trust or no trust, with fast user switching that never shares sessions.

Make lost-factor recovery stronger than login

Recovery may use an unused saved code, another enrolled authenticator, verified recovery contact plus additional evidence, or a documented assisted process.

Do not let a help-desk user disable MFA based on name, email, or facility knowledge alone. Require a case, identity evidence, approver, waiting period when appropriate, and notification.

The staff account recovery guide explains reset tokens, session revocation, offboarding, and assisted recovery.

After recovery, revoke old sessions and compromised authenticators, bind a new factor, rotate recovery codes, and notify the user.

Support device replacement without downtime

Allow an authenticated user to enroll a new factor before removing the old one. Require reauthentication and prevent removal of the last factor when policy requires MFA unless the controlled recovery flow completes.

Show all enrolled authenticators with user-friendly labels, enrollment time, and last use. Do not display secret material or full credential identifiers.

For organizational security keys, document issuance, return, loss, and replacement without storing resident information.

Roll out MFA safely

Use stages:

1. Offer enrollment and education.
2. Require privileged roles.
3. Prompt remaining users before enforcement.
4. Verify recovery readiness.
5. Enforce at sign-in and step-up.
6. Monitor lockouts and suspicious bypass attempts.

Provide accessible instructions, compatible methods, and a staffed recovery process. Do not surprise overnight caregivers with an untested mandatory factor.

Measure enrollment and recovery readiness by facility without exposing individual secrets.

Protect accessibility and usability

Support password managers and paste for one-time codes. Use permanent labels, clear time remaining, understandable errors, and keyboard-accessible method selection.

Do not require transcription from one device when a passkey or security key can complete the challenge. Avoid short countdown animations that reset the entire form.

Recovery codes should be printable in high contrast and copyable one at a time, with a warning that each is single-use. Never depend on color alone to mark used codes.

Audit and monitor authenticator events

Record:

• Enrollment started and completed
• Factor type and protected identifier
• Challenge success and failure class
• Recovery code generated, used, and regenerated
• Factor removed or renamed
• Trusted device issued and revoked
• Step-up action authorized
• Recovery and administrative override
• Notification delivery

Exclude TOTP secrets, QR codes, recovery code plaintext, challenges, session tokens, and resident data from logs.

Alert on repeated failures, new factor followed by broad export, recovery followed by role change, and factor removal from privileged accounts.

Test authentication and recovery

Use demonstration identities to verify:

1. Passkey enrollment and sign-in.
2. TOTP enrollment confirms a valid first code.
3. QR secret never reaches telemetry.
4. Wrong origin fails WebAuthn.
5. Replayed challenge fails.
6. Reused TOTP is rejected under policy.
7. Saved recovery code works once.
8. Regeneration invalidates old codes.
9. User removes one of several factors.
10. Last required factor cannot be removed casually.
11. Trusted device can be revoked.
12. Password recovery revokes trusted devices.
13. Step-up is bound to facility and action.
14. Privileged assisted recovery requires approval.
15. Screen reader completes method selection.
16. No secret appears in logs or support bundles.

Inspect identity records, sessions, notifications, audit events, and facility permissions after each path.

Frequently asked questions

Is SMS the same strength as a passkey?

No. Passkeys can provide phishing resistance through cryptographic domain binding; manually entered codes do not. Offer accurate choices based on risk and accessibility.

Should recovery codes be stored in the app?

Store secure hashes for verification and show plaintext only once. Users should keep them offline or in an appropriate secure manager.

Can one recovery code be reused?

No. Invalidate it after successful use and encourage regeneration when the remaining set becomes low or exposed.

Should every user be forced into MFA immediately?

Prioritize privileged roles, prepare recovery, test usability, and use a communicated rollout. The destination can still be broad MFA adoption.

Does MFA remove the need for session revocation?

No. Stolen sessions can bypass a new login challenge. Revoke sessions after compromise, recovery, offboarding, and relevant role changes.

Make strong authentication recoverable without making it weak

Effective MFA uses phishing-resistant options, trusted enrollment, transaction-bound challenges, one-time recovery codes, step-up protection, device revocation, accessible workflows, and strong assisted recovery.

Explore AFH Manager to test passkeys, authenticator apps, saved recovery codes, trusted devices, facility-bound step-up, rollout, and security-event auditing with demonstration accounts.