All lessons Leer en español

Security in depth · Unit 19 · Lesson 5 of 8

Recovery belongs in the MFA design

Distinguish recovery notifications from evidence that factor replacement was authorized.

3 minreadyShort lesson

Helpful before thisInitial access and credentials

See all lessons in this topic

After this lesson you can

  • Identify the missing assurance evidence in a factor-replacement record.

One idea. One situation. One reasoned decision.

How it works

Multi-factor authentication strengthens a sign-in by requiring appropriate independent evidence. Its recovery path can become the effective account boundary if it grants access with weaker checks. Define recovery methods, protect recovery codes, and review sensitive changes to enrolled factors. A secure everyday sign-in does not compensate for an account-reset process that cannot reliably establish the requester’s authority.

Enrolled factors → Recovery policy → Restored accessEnrolled factorsRecovery policyRestored access
Follow the relationship: Enrolled factors → Recovery policy → Restored access.

Read the supplied record

The fictional club’s policy requires an approved recovery-verification method before replacing a lost authenticator, plus notification to the existing contact afterward. It also requires a record of the method and result, without storing recovery secrets.

Supplied record What it establishes
Support ticket Replacement marked complete at 10:20
Notification receipt Existing contact received notice at 10:21
Verification record Not included in the review packet

The notice is useful but does not demonstrate that the requester met the recovery requirement. Equally, an incomplete packet does not prove the verification never happened. Record the control as unverified and request the missing method-and-result evidence from the recovery owner.

Keep recovery usable for people who genuinely lose an authenticator: “deny every recovery” is not the policy. The design must define an appropriate alternative, how its authority is established, and what happens to replaced authenticators and related sessions. The ticket alone answers none of those lifecycle questions.

The key distinction: Recovery can restore access and must have its own assurance.

Check yourself

No timer. No penalties. Read the explanation and try again whenever you like.

  1. What is the strongest conclusion supported by this recovery packet?

    Show the answer

    Correct answer: The required verification remains unproved, so the reviewer needs its record before accepting the recovery control. The ticket and notice describe a completed change, while the required assurance step lacks supporting evidence.

Try it

  • WriteWrite a recovery-review note with the approved requirement, the evidence present, the evidence missing, and the owner who must resolve it.
References