Chapter 10 — Engineering ethics and safety | Engineering Quantum and post-quantum security

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 10 — Engineering ethics and safety

Lesson map

Lesson 10 published. Map, example, EX019.

flowchart TD
  N0["Learning outcomes"]
  N1["10.1 Duties"]
  N2["10.2 Who bears the risk"]
  N3["10.3 Safety interactions"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX019"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["10.1 Duties"]
  N2["10.2 Who bears the risk"]
  N3["10.3 Safety interactions"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX019"]

[Learning outcomes]
    |
    v
[10.1 Duties]
    |
    v
[10.2 Who bears the risk]
    |
    v
[10.3 Safety interactions]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX019]

Learning outcomes

You will (1) apply professional ethics to cryptographic migration decisions; (2) identify who bears the risk of "harvest-now, decrypt-later"; (3) handle vulnerability findings responsibly; and (4) avoid overstating quantum risk to sell products. It closes the first foundations block and informs every design decision later.

10.1 Duties

Engineering codes of ethics place public welfare first. In PQC work this means protecting people whose data will remain sensitive for decades — medical, legal, customs and personal records — even though harm, if it comes, comes years after the engineer's decision. It also means honesty: neither minimizing the risk ("quantum is science fiction") nor inflating it to sell ("RSA will be broken next year").

For a BPA engineer, honesty means stating the range of expert estimates and the 25-year record lifetime side by side, without picking the date that suits the budget.

10.2 Who bears the risk

Data subjects bear harvest-now-decrypt-later risk, but they rarely decide migration budgets. An ethical engineer makes this asymmetry visible in decision memos: "If we postpone, customs declarants' commercial data recorded from now until migration may become readable by a future adversary."

The memo then names who decides and who would be harmed, so the board sees that postponing transfers risk to people outside the room. Quantifying exposure, as in the 8.0 versus 16.3 TB comparison, makes the transfer concrete. It also gives declarants' representatives something to ask about when BPA reports on data protection.

10.3 Safety interactions

Cryptographic changes can break availability: an oversized handshake that a middlebox drops, a firmware signature that a bootloader cannot verify, a certificate that a medical device rejects. In safety-related systems — cranes, port traffic control — a failed update can stop operations or create hazards. Change management with rollback plans, testing in isolated environments and staged rollouts is an ethical duty, not bureaucracy.

In practice, BPA's crane firmware change is tested on a spare controller, rolled out to one crane, and held for a week before the rest.

10.4 Responsible disclosure and testing limits

If testing reveals a vulnerability in a product, report it to the vendor and give time to fix before publishing. Never test systems you are not authorized to test, and never run downgrade experiments on production traffic.

For BPA's teams, authorization means a written scope that names systems, dates and allowed techniques. A downgrade test that strips the hybrid group from a ClientHello belongs in a lab copy of the portal, not on the live service where it could break partners' sessions. Findings in vendor products go to the vendor first, with a disclosure date agreed in advance.

10.5 Worked example

A vendor offers BPA a "quantum-proof" appliance using an unpublished algorithm. Ethical evaluation: an unvetted algorithm offers no assurance (Rainbow and SIKE were broken despite years of public scrutiny — Beullens 2022, Castryck and Decru 2022); the marketing overstates; the engineer's duty is to recommend standardized algorithms and to say why, even if the vendor is a friend of management.

The written evaluation goes to the board, not only to the vendor, so the reasons survive any later pressure to reverse it.

10.6 Common errors and limits

Deferring migration because the harm is far away.
Accepting marketing terms like "quantum-proof".
Rolling out cryptographic changes to safety systems without rollback.

Deferral feels safe because nobody is harmed this year, but recorded customs traffic accumulates exposure every month the decision waits. "Quantum-proof" claims should prompt a request for the algorithm, its standard and its review history. Safety systems such as crane controllers need tested rollback before any firmware signature change, since a device that rejects its own update can halt operations.

Exercises

EX019 — Risk bearers. For BPA, list three groups who bear quantum risk and how each is represented in decisions. Rubric: 3 = groups distinct, representation gap identified.
EX020 — Vendor letter. Write a polite letter declining an unvetted "quantum-proof" algorithm. Rubric: 3 = cites standards and the breaks, offers a path forward.

Synthesis

Ethical PQC engineering protects long-lived data on behalf of people who cannot see the risk, communicates honestly, treats availability and safety as part of security and rejects unvetted cryptography.

Continue studying — chapter 10 of 50

← Chapter 09 (draft) · Course chapter index · Chapter 11 (draft) →