Quantum-Safe Enterprise Architecture

A cryptographic inventory records, for every asset, which algorithms and key lengths are in use, where keys are stored, who owns the asset, what data lifetime it protects and what depends on it. Sources include network scanning and TLS fingerprinting, code scanning for library calls, configuration management databases, vendor questionnaires and certificate transparency logs.

Expect gaps. Cryptography hides in firmware, in third-party libraries bundled years ago, in appliances whose console shows a port number and nothing more. Treat the first inventory as an estimate with confidence levels, and plan a second pass focused on the assets you could not see, because that is where the schedule risk lives.

Prioritise by exposure multiplied by data lifetime. Long-lived confidential data on externally reachable systems migrates first; internal transport with short-lived sessions follows; signatures and code signing are sequenced against certificate and tooling lifecycles. This ordering is defensible to auditors and produces early wins.

Crypto-agility means algorithms, key sizes and providers are configuration rather than code. Practically that requires an abstraction layer, policy definitions, provider interfaces and a test harness that can exercise alternative algorithms. Retrofitting agility into a monolithic application is expensive; adding it during a migration is comparatively cheap, which is the argument for doing both at once.

PKI migration touches root and intermediate CAs, certificate templates, revocation infrastructure and every relying party. Larger post-quantum signatures affect certificate chains, so chain length and trust store behaviour must be tested. Code signing adds timestamping and packaging formats that may not accept larger signatures without tool updates.

Hardware security modules are the pacing constraint. Many deployed devices cannot store or generate post-quantum keys, and firmware upgrades may be unavailable for end-of-life models. Realistic plans dual-run classical and post-quantum material, use software keystores for non-production and schedule hardware refresh into the capital plan with dates, not intentions.

OT and critical infrastructure contain long-lived devices with no cryptography upgrade path. The architectural answer is segmentation and protocol gateways that terminate and re-establish cryptography at a boundary, so legacy segments stay isolated while the perimeter becomes agile. That must be designed without weakening existing segmentation controls.

Governance converts engineering into assurance: a risk register, an approved policy, a roadmap with owners and dates, migration metrics reported quarterly, and audit evidence per phase. Zero Trust principles — explicit verification, least privilege, assume breach — apply unchanged; post-quantum algorithms replace primitives inside that architecture rather than redefining it.

A quantum-safe architecture starts from a threat model with two timelines. The first is retrospective: data captured today and decrypted later, which makes confidentiality of long-lived information urgent now. The second is prospective: signature forgery once a cryptographically relevant machine exists, which threatens authentication, software supply chains and identity systems at the moment of attack rather than before it.

Separating these timelines changes the investment order. Confidentiality work is dominated by key exchange, protocol versions and data-retention decisions. Authentication work is dominated by certificate authorities, code signing, device identity and document signing — systems with long replacement cycles and heavy process inertia. Treating them as one migration is the most common architectural error.

The threat model should also state what the architecture does not protect. Endpoint compromise, misconfiguration and insider access remain the dominant causes of breaches and are untouched by a cryptographic upgrade. An architecture document that implies otherwise creates false assurance, which is worse than an honest statement of residual risk.

You cannot migrate what you cannot see. Inventory work must cover libraries, protocols, certificates, hardware security modules, embedded firmware, third-party services and machine identities — and machine identities are usually the largest and least documented population. Service accounts, API keys, TLS client certificates and workload identities frequently outnumber human users by an order of magnitude.

Map dependencies rather than listing assets. Which service terminates TLS, which validates certificates, which signs artefacts, which verifies them, and where keys live. The interesting findings appear at boundaries: a vendor appliance that pins a specific curve, an SDK that cannot negotiate a new group, a monitoring agent with an embedded certificate that has never been rotated.

Keep the register in the same system as change management. An inventory maintained separately decays within two quarters, and a stale inventory is more dangerous than none because it produces confident answers that are wrong. The measurable test is whether a new service cannot reach production without its cryptographic dependencies recorded.

A quantum transition is an opportunity to reduce blast radius, not only to swap algorithms. Segmentation limits how far a compromised credential travels; identity-based access with strong, migratable authentication reduces dependence on any single cryptographic mechanism; and short-lived credentials shrink the value of harvested material. These controls are classical, and they make the cryptographic migration less load-bearing.

Zero-trust architecture and post-quantum cryptography are complementary but not substitutes. Zero trust assumes the network is hostile and verifies every request, which limits damage when a key is compromised but does not prevent retrospective decryption of data in transit. Post-quantum cryptography protects the channel but assumes endpoints behave. Deploying one and claiming the other is a recurring confusion in architecture reviews.

Design the key hierarchy for replacement. Root keys, intermediate authorities, workload identities and session keys should have independent lifetimes and independent migration paths, so that rotating one does not require reissuing everything. Flat hierarchies are cheap to build and expensive to migrate, which is exactly the cost discovered during a transition.

Boards and regulators ask three questions: what is exposed, when will it be fixed, and how do you know. Answering the third requires evidence rather than intent — test results from hybrid handshakes, inventory coverage percentages, drill recovery times, exception registers with expiry dates and independent validation of critical implementations.

Assurance should include cryptographic correctness testing and implementation testing. Correctness is covered by test vectors and known-answer tests; implementation is covered by side-channel assessment, fault-injection resistance and configuration review. These are different disciplines, and a scheme that passes test vectors can still leak through timing.

Finally, make exceptions visible and time-bounded. Every migration has legacy systems that cannot be updated, and the difference between a managed programme and an audit finding is whether the exception has an owner, a compensating control and an expiry date. Publish those internally; informal exceptions become permanent by default.

Produce an asset-level cryptographic inventory with confidence levels.

Scan a set of containerised services, map algorithms, record owners and data lifetimes, and produce the register with a coverage estimate.

Convert a hard-coded crypto call path into policy-driven selection.

Take a small service with hard-coded algorithms, introduce a provider interface, and demonstrate an algorithm swap by configuration.

Preserve segmentation while modernising cryptography at the boundary.

Design and document a gateway that terminates legacy protocols and re-establishes hybrid TLS outward, with threat model and failure modes.

Context: Long-lived citizen records under classical cryptography.

Method: Risk-tiered inventory with data-lifetime prioritisation and hybrid transport.

Findings and status: Inventory surfaced legacy systems with no upgrade path, requiring compensating controls.

Transferable lesson: Legacy systems define the programme's tail.

Context: OT devices cannot be upgraded.

Method: Protocol gateways terminating legacy links with modern cryptography at the perimeter.

Findings and status: Perimeter modernised without touching field devices; segmentation preserved.

Transferable lesson: Gateway patterns solve OT constraints that direct upgrades cannot.

Context: Thousands of internal service-to-service links using TLS.

Method: Service mesh with policy-driven algorithm selection and automatic hybrid support.

Findings and status: Fleet-wide migration achieved through platform change rather than application rewrites.

Transferable lesson: Platform-level agility is the cheapest migration route at scale.

Context: Payment terminals with fixed firmware lifetimes.

Method: Compensating controls and refresh-aligned migration schedule.

Findings and status: Migration follows terminal replacement cycles over several years.

Transferable lesson: Align cryptography work to capital replacement, not to ambition.

Context: No inventory existed, and the migration plan prioritised customer-facing portals over the internal systems holding the longest-lived data.

Method: Built a cryptographic bill of materials, then re-sequenced migration by data lifetime and introduced hybrid key exchange at the gateway tier first.

Findings and status: Long-retention systems were protected first, and inventory coverage became a measurable programme metric rather than an aspiration.

Transferable lesson: Sequencing by data lifetime protects the exposure that actually matters.

Context: Code-signing keys sat on long-lived hardware tokens with no agility and no independent implementation review.

Method: Moved signing to a hardware module supporting post-quantum schemes, added known-answer tests and side-channel assessment to the release gate, and drilled key rotation.

Findings and status: Release signing became quantum-resistant with a tested rotation path and documented assurance evidence.

Transferable lesson: Signing infrastructure is the slowest element and must be started before it becomes urgent.

Work through these in order — each builds evidence the capstone requires. Record assumptions, code versions, shots or sample counts, and validation results; the reasoning is assessed, not only the answer.

A regulated operator must present a defensible quantum-safe plan to its board and regulator.

Problem: Produce a complete architecture, inventory approach, prioritisation, target design and phased roadmap with evidence requirements.

Objectives: Demonstrate programme-level competence across discovery, architecture, migration and assurance.

Deliverables: Inventory model, risk scoring, target architecture, roadmap with owners and dates, metrics and audit evidence plan.

Assessment: Discovery rigour 25%, architecture quality 25%, roadmap realism 30%, assurance plan 20%.