◇ OpenCyber Academy
Engineering · Chapter 31 · English

Chapter 31 — Information security: implementation II

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 31 — Information security: implementation II

Lesson map

Lesson 31 published. Map, example, EX091.

flowchart TD
  N0["Learning outcomes"]
  N1["31.1 Rollout plan"]
  N2["31.2 Warehouse terminals"]
  N3["31.3 Exceptions"]
  N4["31.4 Tracking adoption"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX091"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["31.1 Rollout plan"]
  N2["31.2 Warehouse terminals"]
  N3["31.3 Exceptions"]
  N4["31.4 Tracking adoption"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX091"]
[Learning outcomes]
    |
    v
[31.1 Rollout plan]
    |
    v
[31.2 Warehouse terminals]
    |
    v
[31.3 Exceptions]
    |
    v
[31.4 Tracking adoption]
    |
    v
[Worked example] --> [Exercise EX091]

Learning outcomes

You will (1) roll out multi-factor authentication at scale; (2) manage exceptions; (3) track adoption against a plan.

31.1 Rollout plan

In her fourth year, Lindiwe helps implement the multi-factor authentication plan approved earlier. Administrators come first with hardware keys, then office staff with app codes, then warehouse staff, who share terminals and need a different approach. She writes a schedule by depot, with training sessions, help desk preparation and a date after which passwords alone stop working. Prof. Hale asks her to plan communication as carefully as configuration, because surprised users generate support calls and workarounds. The security lead approves the schedule and the training dates.

31.2 Warehouse terminals

Warehouse staff use shared terminals with gloves on, so phone prompts are impractical. Lindiwe's team tests short-lived badge tap logins combined with a personal code, so each person is identified individually and shared accounts disappear. The test depot reports faster logins than the old shared password. She learns that security improvements that also remove friction spread quickly, while those that add friction need strong justification and support to be accepted by busy staff. The badge readers are added to every warehouse terminal over the following two months.

31.3 Exceptions

Some accounts cannot use multi-factor authentication immediately: an old scanner integration and two service accounts used by suppliers. Lindiwe records each exception with an owner, a reason, compensating controls such as network restrictions and an expiry date. Prof. Hale explains that exceptions without expiry dates become permanent weaknesses. She sets reminders three weeks before each expiry so owners must either fix the issue or justify an extension to the security lead. The scanner integration's exception is closed after three months, when the supplier delivers an update supporting certificates.

31.4 Tracking adoption

Lindiwe tracks adoption weekly: the share of accounts enrolled, the share of logins using a second factor and the number of open exceptions. Adoption among administrators reaches all accounts in the first fortnight, office staff follow over two months and warehouse depots move one at a time. She reports progress against the plan to the security lead. She notes that counting enrolments alone could mislead, since enrolled users might still log in with old methods until those are disabled. Disabling old methods follows.

Worked example

Lindiwe phases multi-factor rollout by group, uses badge taps for warehouse terminals, records exceptions with expiry dates and tracks both enrolment and actual second-factor use.

Synthetic case. The rollout is synthetic.

Errors and limits

Exceptions without expiry dates become permanent weaknesses.

Exercises

Continue studying — lesson 31 (chapter 31 of 50)

← Chapter 30 · Course chapter index · Chapter 32 →

Continue to the next authored lesson.