Chapter 31 — Security architecture and engineering: implementation II
Lesson map
Lesson 31 published. Map, example, EX091.
flowchart TD
N0["Learning outcomes"]
N1["31.1 Automating device certificates"]
N2["31.2 Linking to asset management"]
N3["31.3 Legacy exceptions"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX091"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["31.1 Automating device certificates"]
N2["31.2 Linking to asset management"]
N3["31.3 Legacy exceptions"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX091"]
[Learning outcomes]
|
v
[31.1 Automating device certificates]
|
v
[31.2 Linking to asset management]
|
v
[31.3 Legacy exceptions]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX091]
Learning outcomes
You will (1) implement certificate life-cycle automation for devices; (2) integrate revocation with asset management; (3) handle legacy components that cannot meet the target design.
31.1 Automating device certificates
The metrics in chapter 29 showed slow revocation of retired validators. In Implementation II, Sofia's team automates the device certificate life cycle. New validators receive certificates through an enrolment process that requires an asset record and an approved installation ticket. Certificates have short validity and renew automatically while the device is in service. The design follows key management phases from SP 800-57 Part 1 Rev. 5. Automation reduces both the manual work that caused delays and the chance of human error, but it also concentrates trust in the enrolment service, which must itself be protected and monitored.
31.2 Linking to asset management
Revocation now triggers from the asset management system: when a validator is marked retired, lost or stolen, an event calls the internal authority to revoke its certificate and adds it to the ingestion deny list. Sofia writes integration tests for each status change. She also adds a daily reconciliation that compares active certificates with in-service assets and alerts on mismatches. Integration across systems is where many security processes fail, because each team assumes another handles the step, so the reconciliation acts as a safety net for missed events.
31.3 Legacy exceptions
About one hundred older validators cannot support automatic renewal. Sofia does not pretend they meet the design. She documents them as exceptions with compensating controls: longer-lived certificates stored in their secure elements, ingestion rules limiting their accepted record rates, quarterly manual checks and a replacement date in year five. Each exception has an owner and an expiry date. Daniel explains that honest exception management is a sign of mature architecture; designs that claim full compliance while hiding legacy gaps leave the organisation exposed to risks nobody is tracking.
Worked example
Sofia's team automates validator enrolment and renewal, triggers revocation from asset status changes with daily reconciliation and documents one hundred legacy validators as owned, expiring exceptions.
Synthetic case. Devices, systems and counts are synthetic; SP 800-57 Part 1 Rev. 5 is real.
Errors and limits
Automated enrolment becomes a high-value target. Reconciliation depends on asset records being accurate.
Exercises
- EX091 — Enrolment condition. What must exist before a validator receives a certificate? Rubric: 3 = an asset record and an approved installation ticket;; 2 = both;; 1 = vague;; 0 = none.
- EX092 — Reconciliation purpose. What does the daily reconciliation catch? Rubric: 3 = mismatches between active certificates and in-service assets from missed events;; 2 = mismatches;; 1 = vague;; 0 = none.
- EX093 — Exception contents. What does each legacy exception include? Rubric: 3 = compensating controls, owner and expiry or replacement date;; 2 = three;; 1 = vague;; 0 = none.
Synthesis
Implementation II closes measured gaps through automation and integration while managing legacy exceptions honestly.
Continue studying — chapter 31 of 50
← Chapter 30 (draft) · Course chapter index · Chapter 32 (draft) →