Chapter 39 — Critical infrastructure and sector security: maintainability
Lesson map
Lesson 39 published. Map, example, EX078.
flowchart TD
N0["Learning outcomes and connection"]
N1["39.1 Long lifecycles"]
N2["39.2 Technical debt and obsolescence"]
N3["39.3 Cryptographic agility"]
N4["39.4 Secure decommissioning"]
N5["39.6 Practical activity"]
N6["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Worked example"]
EX --> Q["Exercise EX078"]
Logical drawing
flowchart LR
N0["Learning outcomes and connection"]
N1["39.1 Long lifecycles"]
N2["39.2 Technical debt and obsolescence"]
N3["39.3 Cryptographic agility"]
N4["39.4 Secure decommissioning"]
N5["39.6 Practical activity"]
N6["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX078"]
[Learning outcomes and connection]
|
v
[39.1 Long lifecycles]
|
v
[39.2 Technical debt and obsolescence]
|
v
[39.3 Cryptographic agility]
|
v
[39.4 Secure decommissioning]
|
v
[39.6 Practical activity]
|
v
[Chapter synthesis]
|
v
[Worked example] --> [Exercise EX078]
Learning outcomes and connection
After this chapter you can (1) design for maintainability over long lifecycles — updates, spares, skills, documentation; (2) manage technical debt and obsolescence in OT; (3) plan cryptographic agility and the transition to post-quantum cryptography; and (4) plan decommissioning securely. It builds on Chapters 8, 14 and 31 and prepares Chapters 41 and 44.
39.1 Long lifecycles
Infrastructure assets last decades; software and threats change in months. Maintainability means the system can be kept secure and functional for its whole life: components replaceable without redesign; updates possible without long outages; documentation current; skills available. Design choices that harm maintainability include proprietary protocols with a single supplier, undocumented custom code, and hardware with no update path.
For TMRP, RTUs installed now may still run in the 2040s, so the gateway design, the message format and the key management must all be maintainable over that span.
39.2 Technical debt and obsolescence
Technical debt is the future cost of shortcuts taken now: a hard-coded configuration, a skipped test, a gateway built "temporarily" for legacy RTUs. Record debt items with owner, cost to fix and risk of leaving them. Obsolescence management tracks end-of-sale and end-of-support dates for every component and plans replacement before support ends, holding spares where replacement is slow.
TMRP's gateways for the legacy RTU-A units at PS1 and PS2 are recorded as debt with a three-year horizon. Spares are bought before end of sale.
39.3 Cryptographic agility
Algorithms weaken and standards change. Cryptographic agility is the ability to change algorithms and key sizes without redesigning the system: algorithm identifiers in message formats, firmware update paths, and key management that can provision new key types. NIST published its first post-quantum cryptography standards (FIPS 203, 204 and 205) in August 2024 (NIST announcement); infrastructure equipment purchased now may still be operating when quantum-capable adversaries are plausible, so public-key mechanisms in long-lived devices need a migration path. Symmetric MACs such as HMAC-SHA256 are much less affected; key exchange and signatures are where migration matters.
39.4 Secure decommissioning
Retired devices contain keys, configurations and network details. Decommissioning steps: revoke keys and certificates; remove accounts; wipe or destroy storage according to policy; update inventory, models and allowlists; and remove firewall rules that served the device. Stale rules for decommissioned devices are a classic path for attackers who place a new device at an old address.
TMRP's maintainability review found that no decommissioning procedure existed, so one was written and linked to change management. It will be used first when PS2's legacy RTU-A and its gateway are replaced, as EX078 describes.
39.5 Worked example: TMRP maintainability review (synthetic)
The review finds: (1) the PS1/PS2 gateways are technical debt with a three-year horizon — recorded with replacement plan; (2) the message format in Lab 8 lacks an algorithm identifier — changed to include a one-byte suite ID (version 1 = HMAC-SHA256-128) before fleet roll-out, costing one byte per message; (3) RTU-B firmware signing uses a classical signature scheme — vendor asked for a post-quantum migration roadmap as a contract condition; (4) no spare LTE modems are held and the model reaches end of sale next year — buy spares now, plan replacement; (5) decommissioning procedure missing — written and linked to change management.
39.6 Practical activity
Build an obsolescence register for TMRP components (RTUs, gateways, modems, SCADA servers, OS, HSM) with assumed dates, support status, spares held and replacement plan.
Include every component the TMRP review mentions: RTU-A and RTU-B, the gateways, the LTE modems, the SCADA servers and their operating system, and the hardware security module. For each, record the assumed end-of-sale and end-of-support dates, the spares held and the replacement plan. Flag any component whose support ends before its planned replacement, as the review found for the LTE modems. Keep the register under change control so it stays current.
39.7 Common errors and limits
- Designs that require the original supplier forever.
- Technical debt that is not recorded.
- Message formats without versioning or algorithm identifiers.
- Decommissioned devices leaving keys and firewall rules behind.
TMRP's review found the third error in the Lab 8 frame and fixed it with a one-byte suite identifier before fleet rollout. It also recorded the legacy gateways as debt and wrote the missing decommissioning procedure. Spare LTE modems are bought before the model's end of sale. The new procedure revokes keys and removes stale firewall rules.
Exercises — chapter 39
EX077 — Agility retrofit. Objective: add cryptographic agility. Inputs: Lab 8 frame format. Steps: add a one-byte suite ID and a receiver policy that accepts only configured suites; show how suite 2 (a different MAC) could be introduced during a transition period, and how suite 1 would be retired. Expected evidence: design and short code sketch. Rubric: 3 = suite ID authenticated (inside MAC), per-station allowed-suites policy, downgrade prevention, retirement step; 2 = suite ID not authenticated; 1 = description only; 0 = none.
EX078 — Decommissioning checklist. Objective: retire a device securely. Inputs: PS2's legacy RTU-A and gateway being replaced by RTU-B. Steps: write a checklist of at least eight steps with evidence for each. Expected evidence: checklist. Rubric: 3 = keys revoked, accounts removed, storage wiped, inventory/model/allowlist updated, firewall rules removed, monitoring baselines updated, spares disposition, sign-off; 2 = missing rules or keys; 1 = generic; 0 = none.
Chapter synthesis
Design for decades: replaceable components, updatable software, current documentation, available skills. Record technical debt, manage obsolescence ahead of end of support, build cryptographic agility into formats and update paths with a post-quantum migration plan, and decommission so that nothing — keys, accounts, rules — outlives the device.
Continue studying — chapter 39 of 50
← Chapter 38 · Course chapter index · Chapter 40 →
Continue to the next authored lesson.