Chapter 6 — Multi-factor authentication configuration

Chapter 6 — Multi-factor authentication configuration

Lesson map

Lesson 06 published. Map, example, EX021.

flowchart TD
  N0["Learning outcomes"]
  N1["6.1 Policy design"]
  N2["6.2 Choosing methods"]
  N3["6.3 Rollout and support"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX021"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["6.1 Policy design"]
  N2["6.2 Choosing methods"]
  N3["6.3 Rollout and support"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX021"]

[Learning outcomes]
    |
    v
[6.1 Policy design]
    |
    v
[6.2 Choosing methods]
    |
    v
[6.3 Rollout and support]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX021]

Learning outcomes

You will (1) configure MFA policies; (2) choose methods by role; (3) plan rollout and support.

6.1 Policy design

Tomas configures a directory policy requiring multi-factor authentication for every user on every sign-in from an unmanaged device, and at least daily on managed devices. Administrators must use it on every sign-in. He tests the policy on his own test account and a volunteer before applying it widely, using report-only mode to see who would be affected. Report-only mode shows the impact without blocking anyone, which avoids locking out a whole surgery on the first morning. Tomas records the report-only results and the date enforcement began in the configuration record.

6.2 Choosing methods

NIST SP 800-63B describes authenticator strength. Tomas recommends an authenticator app for most staff and phishing-resistant passkeys or hardware keys, based on FIDO2 and W3C WebAuthn, for the practice manager and IT staff, who hold the most powerful access. Text message codes remain only as a temporary fallback during rollout. He explains the choice to staff in simple terms: passkeys only work with the genuine site, so a fake sign-in page cannot capture them. The practice manager agrees the choices and signs the configuration record that lists them.

6.3 Rollout and support

Rollout happens surgery by surgery over two weeks. Tomas runs short sessions where staff set up their method with help, and he keeps spare hardware keys for staff without suitable phones. He records each person's method in the register so support knows what to expect. A help sheet explains what to do if a phone is lost. Planned support makes staff willing participants, which matters because people who struggle with a new control often find ways around it. Questions raised in the sessions are added to the help sheet.

Worked example

Report-only mode shows 28 users affected; rollout over two weeks gives app-based MFA to most staff and keys to four with the most powerful access.

Synthetic case. Policies and numbers are synthetic; NIST SP 800-63B and W3C WebAuthn are real sources.

Errors and limits

Enforcing a new MFA policy on everyone at once without report-only testing risks mass lockout.

Exercises

• EX021 — Report-only purpose. What does report-only mode do? Rubric: 3 = shows impact without blocking;; 2 = preview;; 1 = blocks;; 0 = none.
• EX022 — Strong method users. Who gets phishing-resistant methods? Rubric: 3 = practice manager and IT staff;; 2 = most powerful access;; 1 = everyone;; 0 = none.
• EX023 — SMS role. What role do text codes play? Rubric: 3 = temporary fallback during rollout;; 2 = fallback;; 1 = main;; 0 = none.
• EX024 — No phone. What helps staff without suitable phones? Rubric: 3 = spare hardware keys;; 2 = keys;; 1 = vague;; 0 = none.

Synthesis

Tested policies, role-based methods and supported rollout make MFA effective and accepted.

Continue studying — chapter 06 of 18

← Chapter 05 (draft) · Course chapter index · Chapter 07 (draft) →