Chapter 12 — Multi-factor authentication
Lesson map
Lesson 12 published. Map, example, EX034.
flowchart TD
N0["Learning outcomes"]
N1["12.1 Choosing factors"]
N2["12.2 Staged rollout"]
N3["12.3 Supporting users"]
N4["12.4 Lost devices"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX034"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["12.1 Choosing factors"]
N2["12.2 Staged rollout"]
N3["12.3 Supporting users"]
N4["12.4 Lost devices"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX034"]
[Learning outcomes]
|
v
[12.1 Choosing factors]
|
v
[12.2 Staged rollout]
|
v
[12.3 Supporting users]
|
v
[12.4 Lost devices]
|
v
[Worked example] --> [Exercise EX034]
Learning outcomes
You will (1) choose second factors for different users; (2) deploy multi-factor authentication in stages; (3) support users and handle lost devices.
12.1 Choosing factors
Jamal compares second factors for Riverbend. App-based codes suit office staff with smartphones. Hardware keys suit the two IT staff, whose accounts are the most powerful and most targeted. Text message codes are weaker but may suit casual staff who do not want apps on personal phones. Ms. Grant explains that the choice balances protection, cost and practicality, and that phishing-resistant methods such as hardware keys give the strongest protection against fake login pages. He summarises the options in a table with cost, strength and ease of use for each group.
12.2 Staged rollout
Jamal plans the rollout in stages: IT staff first, then managers, then office staff, then all remaining staff. Each stage has a date, a guide and a support session. He starts with the email system, because compromised email accounts are commonly used to send fraudulent invoices. The IT manager approves the plan. Jamal learns that staging lets the team fix problems with a small group before they affect everyone. He writes a short message for each stage explaining why the change matters, and the IT manager sends it two weeks before the stage begins.
12.3 Supporting users
Some staff struggle with setup. Jamal writes a one-page guide with screenshots and runs drop-in sessions at each centre. He finds that older phones cannot install the authenticator app, so he provides text message codes as an alternative for those staff. Support requests peak in the first week and then fall. Ms. Grant notes that good support reduces resistance and stops staff looking for ways around the new control. He records each support request with its cause, and the most common one, a phone clock set incorrectly, is added to the guide.
12.4 Lost devices
Phones get lost. Jamal writes a procedure: staff report the loss to IT, IT removes the lost device from the account after confirming identity through a known phone number or in person, and the staff member registers a new device. He sets up backup codes for IT staff, stored securely. He learns that recovery procedures must be as secure as the login itself, because attackers often target recovery rather than the main login. He tests the procedure with a colleague who pretends to have lost a phone.
Worked example
Jamal chooses factors by user group, stages a rollout starting with email, supports staff with guides and alternatives and writes a secure lost-device procedure.
Synthetic case. The rollout is synthetic.
Errors and limits
A weak recovery procedure lets attackers bypass multi-factor authentication.
Exercises
- EX034 — IT factor. Which factor suits IT staff? Rubric: 3 = hardware keys;; 2 = partly correct;; 1 = other;; 0 = none.
- EX035 — First system. Which system gets multi-factor authentication first? Rubric: 3 = email;; 2 = partly correct;; 1 = other;; 0 = none.
- EX036 — Old phones. What alternative suits staff with old phones? Rubric: 3 = text message codes;; 2 = partly correct;; 1 = other;; 0 = none.
Continue studying — lesson 12 (chapter 12 of 30)
← Chapter 11 · Course chapter index · Chapter 13 →
Continue to the next authored lesson.