MFA Enrollment and Account-Recovery Security Review
Authenticator change ceremony and recovery challenge
Review enrollment, removal, replacement, backup-code issue, lost-device recovery, and support override as high-impact account changes. Require recent authentication or a documented recovery ceremony before changing an authenticator. NIST SP 800-63B describes authenticator lifecycle and step-up concepts; risk owner sets assurance for account impact rather than treating email possession as universal identity proof.
Test stale session enrollment, attacker with active email session, reused recovery code, rapid factor replacement, and support agent operating alone. A pass means no new passkey, OTP device, or backup code becomes usable until required proof and approval complete. Display a backup code once, keep only protected representation, consume it once, and notify through an independent channel after factor changes. Audit record should identify event, account, approver, and outcome without storing authenticator secret.
Remediation may add step-up, cooldown, dual approval, recovery attempt limits, and review queue. Avoid permanent lockout from one shared network signal. Closure replays used recovery code and confirms factor removal invalidates intended sessions. A documented exception for emergency recovery must expire, require separate approver, and create a mandatory post-event review; it cannot be a quiet support shortcut.
Recovery design must state which channel is independent. A notice sent only to account email may be useful but cannot warn a person whose email session was compromised. Test factor-add notification, cancellation route, and delay behavior with synthetic users. Support evidence should show who verified case, who approved change, and which authenticated channel received notice. Do not collect recovery secrets in tickets. Measure false-positive lockouts before increasing friction.
Bind enrollment to current assurance
Adding, removing, or replacing an authenticator changes who can control an account. Require recent authentication or a documented recovery ceremony before showing an enrollment secret, registering a passkey, accepting an OTP seed, or removing the last strong factor. Bind enrollment challenge to current account, browser or device context where applicable, intended authenticator type, and short expiry. A QR secret or activation link must not be reusable after successful binding.
Use synthetic account with one existing factor to exercise normal enrollment. Expected evidence includes recent-authentication result, new-factor identifier, event time, independent notification attempt, and session decision. Then test stale session, a request that substitutes another account ID, expired enrollment challenge, repeated challenge, and two simultaneous enrollment attempts. Invalid cases must not create an authenticator record or remove an existing factor. If replacement first removes old device, a failed new enrollment must leave a recoverable safe state rather than no factor or two unintended factors.
Recovery codes and factor replacement
Recovery codes are one-time lookup secrets, not reusable passwords. Generate sufficient unpredictable values, display each only at issuance, store a protected representation, mark each consumed atomically, and avoid logs, browser cache, screenshots in support systems, or email delivery of plaintext values. Redeem one code, repeat it, then use a second code. Expected outcome is one success per code, audit evidence without secret material, and session or factor action defined by policy.
A factor-replacement workflow needs a challenge proportional to account impact. NIST SP 800-63B discusses authenticator lifecycle; this article does not prescribe a universal proofing method. Test lost-device recovery, active email-session attacker, cooldown before sensitive replacement, cancellation of a pending change, and notification failure. Notice through an independent channel is stronger than notice sent solely to account channel being recovered. If notification cannot be sent, record recovery state for authorized follow-up rather than silently declaring completion.
Helpdesk and session outcomes
Helpdesk staff should follow a documented identity-proofing workflow approved by risk owner; a caller-provided account number or public profile data alone is weak proof. Separate requester verification from agent approval where risk warrants, record case ID, evidence category, approver, scope, and outcome without copying secrets into ticket. Test that a single agent cannot bypass required second decision.
After factor addition, removal, recovery, or support override, decide which sessions remain valid. Replay pre-change sessions from two devices and check protected actions. Remediation may add step-up, cooldown, dual approval, recovery attempt limits, and revocation. Closure reruns stolen-session, reused-code, pending-replacement, and helpdesk-single-agent cases. Any temporary recovery exception names account scope, proofing method, expiration, independent review, and post-event notification requirement.
Recovery ceremony case record
| Recovery event | Owner | Evidence | Expected result | Observed result / status | Exception | Closure |
|---|---|---|---|---|---|---|
Lost-device factor replacement for synthetic account acct-mfa-17 | Identity risk owner | Case MFA-071; proof category, approver audit, notification receipt, session replay | Replacement waits for second approval; used code fails; prior sessions revoked | Approval enforced; replay denied; 2 prior sessions revoked — closed | None | Independent notice delivered; reused-code and single-agent retests passed 2026-06-18 |