Staff Account Recovery and Session Revocation for AFH Software

Account recovery in adult family home software must restore the right caregiver or manager without giving an attacker a simpler path around authentication. Session revocation must remove access from lost devices, former staff, compromised accounts, and changed roles while preserving historical authorship on resident records.

This guide covers identity-system design, not employment decisions or a universal authentication standard. It was reviewed on August 8, 2026. Organizations should set controls from current risk, privacy duties, contracts, device practices, and operational needs.

Separate recovery from ordinary sign-in

Recovery is an exceptional process for a user who cannot use an enrolled authenticator. It should not behave like a second weak login form.

Define supported cases:

• Forgotten password
• Lost or replaced phone
• Lost passkey or security key
• Unavailable email or recovery address
• Locked or disabled account
• Compromised credentials
• Administrator-assisted recovery
• Staff reactivation after an approved return

Each case needs evidence, permitted roles, delays, notifications, and session consequences.

Return neutral recovery responses

Public forms should not reveal whether an email belongs to an owner, caregiver, pharmacy user, or administrator. Return a consistent message and similar timing for known and unknown accounts.

The OWASP Forgot Password guidance recommends uniform responses and random, securely stored, single-use, expiring reset tokens.

Rate-limit by account reference, network, device, and risk without locking a legitimate user out merely because an attacker submits repeated requests.

Issue purpose-bound reset credentials

Generate a cryptographically random token, store a secure digest, bind it to one account and purpose, and set a short lifetime. Do not reuse invitation, email-verification, access-code, or session tokens for recovery.

The reset page should create a limited recovery session that permits only the approved credential change. It cannot open resident records or accept facility invitations.

Invalidate the token after success, replacement, expiration, account disablement, or relevant identity change. Never log the token or full URL.

Verify the destination and identity state

Send reset messages only to a previously verified recovery destination. If a user requests a destination change while locked out, use a stronger assisted process rather than sending the reset to the newly supplied address.

Preserve original address, normalized comparison, verification time, and change history. Do not merge accounts through aggressive email normalization.

For privileged roles, require another bound authenticator, saved recovery code, administrator approval, or repeated identity proofing appropriate to risk.

Notify users about recovery events

Send a notice after recovery is requested when appropriate, and always after credentials or authenticators change. Include time, general device or location context, what changed, and how to report unauthorized activity.

Do not include resident, medication, or facility details in the message. A notification is not authentication and cannot reverse the change by a predictable public link.

Route suspicious notices to an authorized security process and preserve delivery status separately from user acknowledgement.

Model sessions explicitly

Store a session family or refresh-token record with:

• Opaque session identifier
• User
• Creation and last-use times
• Authenticator strength
• Device label supplied or safely derived
• Facility grants at issuance
• Rotation lineage
• Expiration and revocation state
• Revocation reason and actor

Do not store raw session secrets in logs or administrative tables. Hash or protect lookup material appropriately.

Short-lived access tokens should reference server-checkable revocation state for sensitive operations.

Revoke sessions after recovery

After a password reset or authenticator recovery, revoke other active sessions automatically or require an explicit risk-based choice. For privileged or suspected-compromise recovery, revoke all existing sessions.

Rotate refresh tokens and prevent reuse of older members in the family. A stolen pre-reset token must not continue opening resident records.

The user signs in through the normal flow after recovery rather than receiving a broad authenticated session automatically.

Support a “sign out other devices” view

Let users view coarse device, browser, creation, last activity, and location information for their own sessions. Provide actions to revoke one session or all other sessions.

Avoid precise location claims from unreliable IP data. Do not reveal full IP addresses or session IDs in ordinary UI.

Require recent authentication before revoking or renaming trusted devices when practical. Confirm the result and record it in the security audit.

Connect staff offboarding

When a caregiver leaves or a facility removes access:

• End the facility assignment at the verified time
• Revoke active sessions and refresh families
• Cancel pending invitations and recovery tokens
• Remove future notifications and on-call routes
• Transfer open operational tasks where authorized
• Preserve authorship on past resident records
• Record the manager, reason category, and effective time

Do not delete the user account to simulate offboarding. The record history still needs an attributable author.

Handle role changes and portfolio access

A role demotion or facility removal should take effect on the next protected request, not after the current session expires days later. Recalculate grants from server-side assignments.

For multi-facility users, revoke only the intended facility when the identity remains authorized elsewhere. Clear active facility context, cached results, open resident forms, and pending exports for the removed facility.

The caregiver access permissions guide explains facility-scoped role grants and historical authorship.

Protect administrator-assisted recovery

Support staff should not set a permanent password, reveal recovery codes, or bypass MFA through an undocumented switch. Use a case-bound workflow with requester identity evidence, approver, limited action, expiration, notification, and audit.

Separate facility-owner authority from platform-administrator authority. A facility manager cannot recover a platform admin, and support cannot silently grant a facility role.

Require step-up authentication for the assisting administrator and review unusual volume.

Prevent race conditions

Use atomic state transitions when recovery, sign-in, email change, disablement, and session refresh occur concurrently.

Examples:

• Account disabled while reset page is open
• Token replaced just before old token submits
• Two devices use the same reset token
• Session refresh occurs during global revocation
• Role removed while an export is rendering

Exactly one valid transition should win. Later attempts receive a safe terminal result without restoring revoked access.

Keep unsaved work honest

When a session is revoked, a tab may still display cached resident data. Immediately block new reads and writes, clear protected client state, and show a signed-out message.

Do not upload pending offline records under a revoked identity automatically. Quarantine them for authorized reconciliation using their original author and event times.

Never redirect through repeated login flicker that briefly exposes protected content.

Audit and monitor recovery

Record:

• Recovery request and generic outcome
• Token issue, replacement, expiration, and use
• Authenticator change
• Recovery notification delivery
• Session and refresh-family revocation
• Use after revocation
• Administrator assistance and approval
• Facility assignment changes
• Failed and throttled attempts

Use opaque user and session references in technical logs. Do not store raw reset tokens, passwords, resident names, or email bodies.

Alert on high-volume requests, repeated token failures, recovery followed by unusual export, and old-token reuse.

Prepare a recovery runbook

Document who handles after-hours lockouts, which roles can approve assisted recovery, how identity evidence is protected, when a waiting period applies, and how an urgent caregiving shift continues without sharing credentials. Include escalation for unavailable email, lost MFA devices, former staff, owner disputes, and suspected compromise.

The runbook should identify the minimum safe diagnostic fields and prohibit staff from asking for passwords, reset tokens, or resident information. Practice with demonstration accounts so support can distinguish a simple reset from a high-risk ownership or administrator recovery.

After each assisted case, verify that only intended facility assignments remain, old sessions and recovery credentials are revoked, notifications were sent, and the case record contains approval and outcome without excess identity documents.

Test complete recovery paths

Use demonstration accounts to verify:

1. Known and unknown emails return neutral responses.
2. Reset token is random, expiring, and single-use.
3. Replaced token invalidates the older one.
4. Account disabled before token use.
5. Two devices submit one token concurrently.
6. Recovery revokes prior sessions.
7. Old refresh token cannot rotate.
8. User revokes one device.
9. Global sign-out keeps only the current session when allowed.
10. Caregiver removal preserves historical authorship.
11. One facility is removed from a portfolio user.
12. Delayed export is denied after revocation.
13. Offline pending event enters reconciliation.
14. Assisted recovery requires case and approval.
15. Notification reports unauthorized recovery path.
16. Revoked tab shows no protected flash.

Inspect authentication records, resident access, notifications, exports, queues, and audit history.

Frequently asked questions

Should recovery reveal whether an email is registered?

No. Use a neutral response and similar timing to reduce account enumeration.

Should password reset sign the user in automatically?

Prefer normal sign-in after the credential changes. This reduces recovery-session complexity and confirms the new authentication works.

What happens to other sessions after recovery?

Revoke them automatically for suspected compromise and privileged accounts, or apply a documented risk-based policy with a clear user choice.

Does offboarding delete the caregiver?

No. End access and revoke sessions while preserving their attributable history on care records.

Can support bypass account security?

Only through a narrow, approved, time-limited recovery workflow with strong support authentication, user notification, and audit—not an invisible override.

Restore access without weakening the facility boundary

Secure recovery uses neutral responses, purpose-bound tokens, verified destinations, recovery notifications, atomic session revocation, facility-aware offboarding, and protected assisted workflows.

Explore AFH Manager to test staff recovery, device sessions, global sign-out, role changes, offboarding, delayed export denial, and recovery audit history with demonstration accounts.