Review MFA and recovery controls by account type

# Review MFA and recovery controls by account type

Read an authentication-control inventory and separate enrolment, enforcement, recovery, workload identity and emergency-access controls. An account label alone never proves that its controls are adequate.

**Time:** 30-45 minutes for a first pass; use the later recall task on another day.
**Prerequisites:** Basic file navigation, editing a small JSON worksheet, and introductory networking/security vocabulary. No professional security experience, cloud account, coding background or programming changes are required.

> **Vocabulary:** **MFA**: authentication using distinct factors. **Enrolment**: registering a method. **Enforcement**: requiring a method at login. **Recovery**: regaining access after a method is lost. **Workload identity**: an identity used by software. **Breakglass**: a controlled emergency account. **Phishing resistance**: protection against authentication being relayed to an impostor.

## Evidence and exact semantics

`data` contains `as_of` and nonempty `accounts`. Each account has `id`,
`type` (`human`, `service`, `breakglass`), Boolean `interactive`, `privileged`,
`enforced`, `monitored`, `controlled_storage`, a unique `methods` list,
`recovery`, `owner` (lowercase ID or null), `credential_lifetime`,
`test_age_days` (nonnegative integer or null), and `exception_until` (date or null).

Human/emergency methods are `password`, `totp`, `security-key`. Workloads allow
`password` and `federated-workload`. Recovery is `none`, `helpdesk-verified`,
`backup-codes-secured`, or `shared-mailbox`. Credential lifetime is `none`,
`short-lived`, or `long-lived`. Human/emergency records must be interactive and
use lifetime `none`. Service records use recovery `none` and enforcement false;
their controls are assessed explicitly below. Only emergency records may use
an exception, test age or controlled storage. Unknown fields/types fail.

The fictional policy evaluates these exact decision labels in the listed order.
Join applicable labels with semicolons, without spaces. "Enrolled MFA" in this
model means at least one `totp` or `security-key` method; it is a record claim,
not a test of the actual ceremony.

| Account | Ordered labels and trigger |
| --- | --- |
| Human | `enrol-mfa` if no MFA method; otherwise `enforce-mfa` if not enforced; `use-phishing-resistant-mfa` if privileged without security-key; `repair-recovery` unless helpdesk-verified or backup-codes-secured. |
| Service | `disable-interactive-login` if interactive; `assign-owner` if owner null; `replace-static-workload-credential` unless short-lived federation with no password; `monitor-workload-use` if monitoring false. |
| Breakglass | First the human enrol/enforce rules and `use-phishing-resistant-mfa` if no security-key, unless a current exception waives those three MFA checks; then `assign-owner`, `monitor-emergency-use`, `secure-emergency-material`, `test-emergency-access`, `repair-emergency-recovery` as explained below. |

Emergency ownership, monitoring and controlled storage must be present. Test
age must be at most 90 days inclusive. Recovery must be `none` or secured backup
codes. An exception dated on or after `as_of` is current, including expiry day;
it never waives ownership, monitoring, storage, testing or recovery controls.
With no missing labels, use `exception-current` for an emergency account with
a current exception; otherwise use `meets-lab-controls`. The labels are a
decision vocabulary, not a certification or a universal account policy.

## Run the exercise

From the repository root, enter this folder with `cd labs/mfa-review`.
Use Python 3.10 or newer. On Windows, `py` may replace `python` if that is your
installed launcher. No package install, account, cloud subscription or billing
setup is needed. Commands run entirely offline and change no real service.

```text
python lab.py cases
python lab.py prepare --scenario guided --out run/attempt-01
python lab.py show --case run/attempt-01/case.json
```

Read the case and any extracted `.txt` evidence. Edit the blank
`run/attempt-01/answers.json`: fill every decision with the exact vocabulary
below, write your own explanation, and cite record IDs or line references in
`evidence`. Keep `notes.txt` for prediction, uncertainty and help used.
Only after saving your prediction:

```text
python lab.py analyse --case run/attempt-01/case.json
python lab.py check --case run/attempt-01/case.json --answers run/attempt-01/answers.json
python test_lab.py
python lab.py verify
```

The worksheet has exactly `decisions` (object), `explanation` (text), and
`evidence` (list of text references). For example, an evidence entry can be a
record ID plus its field name. Use your own case IDs, not invented references.
`check` compares decision strings and requires nonempty written fields; a person
must assess their accuracy. `verify` checks shipped fixtures, not learner skill.
Exit codes are 0 for success/match, 1 for differences or incomplete written
fields, and 2 for invalid input. Default `--case` is the guided fixture beside
the script. Explicit input paths are relative to the working directory; `--out`
is relative to this lab and must be a new folder below `run/`.

For the next cases, prepare fresh folders:

```text
python lab.py prepare --scenario changed --out run/attempt-02
python lab.py prepare --scenario challenge --out run/attempt-03
```

Replace `attempt-01` in `show`, `analyse` and `check` with the chosen folder.
Edit practice copies only. Do not overwrite fixture or reference files.

## Deliverable and handover

Save one completed worksheet and a short evidence note for each case. Include
your prediction, changed judgment, uncertainty, and one next check you cannot
perform from this evidence. Record whether you used the worked example or help.
Ask a reviewer: "Can you reproduce my decision from these record IDs, and which
claim goes beyond the evidence?" Your independent status remains **unassessed**;
matching output is not a qualification, professional experience or proof of
mastery. These are original fictional practice cases, not assessment submissions.

## Limits

No login is attempted. A security-key label does not establish registration quality, user verification, backup arrangements or resistance in every provider flow. The emergency design and 90-day boundary are fictional policy; real organisations need a provider-specific tested design. Workload risk remains even though human MFA is not the workload control.

## Primary references

NIST distinguishes authenticator strength, lifecycle and recovery. The local check labels, workload branch and emergency exception policy are teaching choices and do not claim NIST compliance.

- [NIST SP 800-63B: authentication and authenticator management](https://pages.nist.gov/800-63-4/sp800-63b.html)

Links are optional further reading, checked 2026-10-23. Running this lab does
not fetch them. See [the worked example](WORKED-EXAMPLE.md) after your prediction
and [the drills](DRILLS.md) for varied practice.

# Worked example: Review MFA and recovery controls by account type

Open this after saving a prediction for the guided case. The reference explains
these fictional records; it does not assess your independent performance.

1. `helpdesk-user` has `password` and `totp`, but `enforced=false`. Record
   `enforce-mfa`, not `enrol-mfa`. Its recovery is a shared mailbox, so add
   `repair-recovery`: `enforce-mfa;repair-recovery`.
2. `platform-admin` is privileged. TOTP is enrolled and enforced, but this
   fictional privileged-account policy requires `security-key`. Use
   `use-phishing-resistant-mfa`. This does not claim all MFA methods are equal.
3. `nightly-export` is a service identity with interactive login, no owner,
   password-based long-lived credentials, and no monitoring. In order, use
   `disable-interactive-login;assign-owner;replace-static-workload-credential;monitor-workload-use`.
   Declaring it a service identity is not an exemption from these controls.
4. `emergency-owner` has a dated exception expiring on the review day,
   `2026-10-23`. It remains current today. The named owner, monitoring,
   controlled storage and 30-day test meet this model's other conditions.
   Recovery `none` is allowed for this emergency design. Use `exception-current`.

The handover should distinguish an observed inventory gap from a verified login
failure. Cite the actual fields and request provider-specific validation rather
than claiming the accounts are globally secure after a label changes.

After comparison, keep your original prediction and add a correction in
`notes.txt`. State the evidence that changed your judgment. Copying the answer
without reconstructing the evidence leaves independent understanding unassessed.

# Practice progression: Review MFA and recovery controls by account type

Use the exact prepare/show/check commands in [README.md](README.md). Save a
prediction before running `analyse`. Fresh folders preserve earlier attempts.

1. **Guided (10 minutes):** inspect each guided account type, predict missing
   labels in policy order, and explain enrolment separately from enforcement.
2. **With prompts (5 minutes):** Does recovery create a weaker access route?
   Who owns the workload? Does its password remain usable? Which emergency
   controls does a dated exception leave mandatory?
3. **Independent (10 minutes):** use `challenge`. Explain why the current
   emergency exception cannot excuse missing monitoring/storage, and why a
   workload with both federation and a password still has a credential finding.
4. **Changed evidence (5 minutes):** use `changed`. Compare the review date to
   exception expiry and 91-day test age. In a copied case, set test age to 90;
   predict exactly which label disappears and which ones remain.
5. **Teach back (5 minutes):** explain why "MFA enrolled" is incomplete evidence
   and why "service account" does not answer the security question.
6. **Later recall (next day, 5 minutes):** list the four service controls and
   five emergency controls without the reference. Describe the expiry boundary.

For each pass record: evidence references, decision, reason, uncertainty, help
used and one next check. Have another person review the explanation and one
unfamiliar case if possible. Until that occurs, independent completion is
unassessed even if every decision matches. Keep all attempts below `run/`.