Chapter 7 — Quantum and post-quantum security: organizational integration
Lesson map
Lesson 07 published. Map, example, EX031.
flowchart TD
N0["Learning outcomes"]
N1["7.1 Not a project, a capability"]
N2["7.2 Policy-driven platforms"]
N3["7.3 Practical activity — Lab A"]
N4["7.4 Governance and decision rights"]
N5["7.5 Refresh cycles and budget"]
N6["7.6 Measuring progress"]
N7["7.7 Worked case"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX031"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["7.1 Not a project, a capability"]
N2["7.2 Policy-driven platforms"]
N3["7.3 Practical activity — Lab A"]
N4["7.4 Governance and decision rights"]
N5["7.5 Refresh cycles and budget"]
N6["7.6 Measuring progress"]
N7["7.7 Worked case"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX031"]
[Learning outcomes]
|
v
[7.1 Not a project, a capability]
|
v
[7.2 Policy-driven platforms]
|
v
[7.3 Practical activity — Lab A]
|
v
[7.4 Governance and decision rights]
|
v
[7.5 Refresh cycles and budget]
|
v
[7.6 Measuring progress]
|
v
[7.7 Worked case]
|
v
[Worked example] --> [Exercise EX031]
Learning outcomes
You will (1) integrate PQC migration into architecture, change, procurement and risk processes; (2) build crypto-agility into platforms through policy; (3) design governance roles and decision rights; (4) align migration with refresh cycles and budgets; and (5) measure programme progress meaningfully.
7.1 Not a project, a capability
A migration run as a separate project ends with a report and leaves the organization as rigid as before. Integrated into normal processes, it leaves a capability: architecture reviews ask about algorithms and agility; change management records cryptographic changes; procurement requires inventories and algorithm support; risk management tracks quantum exposure. CSWP 39 frames this as crypto-agility at the organizational as well as technical level.
At NRHT the Cryptography Authority is the mechanism for this: it owns the cryptographic standard and reviews architecture decisions, while procurement adds clauses to contracts. Measure integration by whether normal processes now ask cryptographic questions without the programme team prompting them.
7.2 Policy-driven platforms
Platforms that read cryptographic choices from policy let the organization change algorithms by configuration. The algorithm identifier must travel with data and be authenticated, so that a verifier can refuse a retired algorithm.
Lab A shows the pattern with message authentication codes, but the same design applies to KEMs and signatures. A platform built this way can move from classical to hybrid, and later to a new algorithm, with a policy change and a transition period. Hard-coded algorithms require code releases for every change.
7.3 Practical activity — Lab A
# Lab A (ch 7): crypto-agility through a policy-driven registry instead of hard-coded algorithms.
import hashlib, hmac
REGISTRY = {"hmac-sha256": lambda k, m: hmac.new(k, m, hashlib.sha256).digest(),
"hmac-sha3-256": lambda k, m: hmac.new(k, m, hashlib.sha3_256).digest()}
POLICY = {"tag-algorithm": "hmac-sha256", "accept": ["hmac-sha256", "hmac-sha3-256"]}
def protect(key, msg):
alg = POLICY["tag-algorithm"]; return alg, REGISTRY[alg](key, msg)
def check(key, msg, alg, tag):
if alg not in POLICY["accept"]: return False # algorithm identifier is authenticated by policy
return hmac.compare_digest(REGISTRY[alg](key, msg), tag)
k, m = b"k" * 32, b"discharge summary 42"
a1, t1 = protect(k, m)
POLICY["tag-algorithm"] = "hmac-sha3-256" # migration = one policy change
a2, t2 = protect(k, m)
print("old tag still verifies during transition:", check(k, m, a1, t1))
print("new tag verifies:", check(k, m, a2, t2), "| algorithms:", a1, "->", a2)
POLICY["accept"] = ["hmac-sha3-256"] # retire the old algorithm
print("old tag after retirement:", check(k, m, a1, t1))
Expected output:
old tag still verifies during transition: True
new tag verifies: True | algorithms: hmac-sha256 -> hmac-sha3-256
old tag after retirement: False
The same pattern — registry, policy, accepted list, retirement — applies to KEMs and signatures in real platforms.
The lab records the algorithm identifier with each tag and checks it against the accepted list, so a retired algorithm can be refused. During the transition both algorithms verify; after retirement the old tag fails. In a real platform the identifier must be protected by the tag or signature itself, so that an attacker cannot change it. Try retiring the old algorithm before switching the default, and note what breaks.
7.4 Governance and decision rights
Define who decides cryptographic policy (a cryptography authority or board), who owns each platform's implementation, who approves exceptions, and who accepts residual risk. Publish a cryptographic standard listing approved algorithms and parameters, transition dates and the exception process.
Write the decision rights into the standard and publish them so that platform owners know whom to ask. Exceptions should be time-limited and recorded in a register that the Cryptography Authority reviews. At NRHT the CISO chairs the authority and the accountable executive signs residual-risk acceptances.
7.5 Refresh cycles and budget
Most hardware is replaced on cycles of five to ten years. Aligning PQC requirements with those cycles avoids premature replacement; it requires procurement clauses now so that equipment bought in 2027 does not need replacing in 2031. Software subscriptions are faster; require roadmaps with dates.
Map each tier-1 platform to its next refresh date and the clause that will apply to its replacement. Where a refresh falls after the date by which migration is needed, plan an interim measure such as a gateway or PSK. At NRHT the infusion pump fleet replacement in 2031 is planned this way.
7.6 Measuring progress
Count outcomes, not activities: share of tier-1 flows with hybrid key exchange (grade A/B evidence); share of new contracts with PQC clauses; median time to change an algorithm on policy-driven platforms; tier-1 unknown share. Avoid vanity metrics such as "number of meetings held".
Report each metric with its source and its evidence grade, and show trends over quarters. At NRHT's year-two review tier-1 hybrid coverage was 64 % with grade A or B evidence, and unknown share was 7 %. Metrics without a denominator or a source should not appear in board reports.
7.7 Worked case
NRHT establishes a Cryptography Authority chaired by the CISO with architecture, PKI, clinical engineering and procurement members. Its standard (synthetic) sets ML-KEM-768 hybrid as the default for new key establishment, requires algorithm identifiers in new data formats, and adds PQC clauses to all contracts above a threshold. Progress metrics are reviewed quarterly by the audit committee.
The authority's first decisions are recorded with their reasons and review dates, so that later members can see why the defaults were chosen. Its standard is short enough for platform owners to read and includes the exception process. Membership spans the teams whose systems will change.
7.8 Common errors and limits
- Treating migration as a one-off project.
- No exception process, leading to silent non-compliance.
- Activity metrics instead of outcome metrics.
Each error has a guard. Integrate cryptographic questions into architecture, change and procurement processes. Publish an exception process with expiries. Report outcomes such as coverage with evidence grades, not counts of meetings or documents produced. At NRHT the Cryptography Authority's standard includes an exception process with expiry dates, and its progress metrics are reviewed quarterly by the audit committee. Check each new metric for a denominator and a source before adding it to the board report.
Exercises
- EX031 — Process hooks. Name four existing processes into which PQC requirements should be integrated, with one requirement each. Rubric: 3 = four processes, concrete requirements.
- EX032 — Decision rights. Draft a RACI for "approve an exception to hybrid key exchange". Rubric: 3 = responsible, accountable, consulted, informed sensibly assigned.
- EX033 — Refresh alignment. A PACS replacement is scheduled for 2029. What must the 2026 tender include? Rubric: 3 = algorithm support, agility, inventory, update commitments.
- EX034 — Outcome metric. Convert "PQC awareness sessions delivered" into an outcome metric. Rubric: 3 = measurable behaviour or state change.
- EX035 — Agility test. Design a quarterly test showing that a platform can switch algorithms by policy. Rubric: 3 = procedure, evidence, pass criterion.
Synthesis
Integration turns migration into an organizational capability: policy-driven platforms, clear decision rights, procurement aligned with refresh cycles and outcome metrics.
Continue studying — chapter 07 of 12
← Chapter 06 (draft) · Course chapter index · Chapter 08 (draft) →