Services / Post Quantum Cryptography & Cryptographic Resilience
In August 2024, the United States National Institute of Standards and Technology published FIPS 203, FIPS 204, and FIPS 205 — the first standardised post-quantum cryptographic algorithms. This event marks the end of a 26-year period of preparation and the beginning of a migration requirement that will affect every organisation that relies on RSA, ECDSA, ECDH, or Diffie-Hellman key exchange for the security of its communications, data, or systems. The migration is not optional. The question is whether your organisation will undertake it in a planned, controlled manner or whether it will discover the urgency after a cryptographically relevant quantum computer renders its current protections worthless.
The commonly misunderstood aspect of quantum cryptographic risk is the harvest-now-decrypt-later attack. Nation-state adversaries — and sophisticated non-state actors — are collecting encrypted traffic today. They cannot decrypt it today. When a cryptographically relevant quantum computer exists, they will decrypt everything they collected. This means that data encrypted today under RSA or ECC that must remain confidential for more than the expected timeframe to quantum capability — typically estimated at 5–15 years, with significant uncertainty — is already compromised in principle. The breach has happened. The decryption is deferred.
This service covers the complete post-quantum migration: cryptographic asset inventory, vulnerability assessment against the quantum threat model, migration strategy and prioritisation, algorithm selection and implementation specification, hybrid classical-PQC transition architecture, and ongoing cryptographic agility design that allows future algorithm migration without repeating the full programme. It also addresses the classical cryptographic weaknesses that organisations expose during a rushed or poorly-scoped post-quantum migration — because the most common outcome of a partial PQC migration is a system that is quantum-resistant in one layer and classically vulnerable in another.
Price Range
£28,000 – £380,000+
Cryptographic inventory, vulnerability assessment, migration strategy, implementation specification, and cryptographic agility design. Implementation of PQC algorithms in production systems is additional.
Cryptographic inventory, vulnerability assessment, migration strategy, implementation specification, and cryptographic agility design. Implementation of PQC algorithms in production systems is additional.
Duration
8 – 36 weeks
Assessment phase only. Implementation of the migration across production systems adds 6–24 months depending on infrastructure complexity.
Assessment phase only. Implementation of the migration across production systems adds 6–24 months depending on infrastructure complexity.
Urgency
Harvest-now-decrypt-later attacks are active. Data encrypted today with long confidentiality requirements is already at risk. The question is not whether to begin — it is how far behind you currently are.
Standards
NIST FIPS 203 (ML-KEM / Kyber) · FIPS 204 (ML-DSA / Dilithium) · FIPS 205 (SLH-DSA / SPHINCS+) · NCSC guidance · ETSI QSC · BSI recommendations
Contract
Fixed-price. 50% on signing, 50% on delivery acceptance.
The migration timeline is not under your controlThe urgency of your post-quantum migration is determined by two factors: when a cryptographically relevant quantum computer exists (outside your control) and how long your sensitive data must remain confidential (your risk tolerance). Organisations that wait for quantum capability to be imminent before beginning migration will not complete it in time. The NCSC and NSA have both issued guidance recommending migration begin now. We are already 8 months past the NIST standard publication. The preparatory work is the constraint, not the quantum computer.
The Threat Model — Precisely Stated
Three distinct threats. Different timelines. Different affected assets. Different required responses. Treating them as one produces a migration plan that addresses none of them adequately.
Post-quantum cryptographic risk is frequently described as a single threat — the risk that quantum computers will break encryption. This framing conflates three structurally distinct threats that affect different assets, operate on different timelines, and require different responses. A migration plan designed around the wrong threat model wastes resources on low-priority assets while leaving high-priority assets unprotected. The threat model below is the starting point for every engagement we conduct.
Threat 1 — Active Now
Harvest-Now, Decrypt-Later (HNDL)
Adversaries are collecting encrypted network traffic today. They cannot decrypt it today. When a cryptographically relevant quantum computer (CRQC) exists — one capable of running Shor’s algorithm against real-world key sizes — they will decrypt everything collected. This attack is not future-tense. The collection is happening. The decryption is deferred. Data with a confidentiality requirement extending beyond the CRQC timeline is already compromised in principle.
Timeline
Active collection now. Decryption deferred to CRQC availability — estimated 5–15 years, with significant uncertainty in both directions.
Affected
Any data encrypted in transit under RSA or ECC key exchange with a confidentiality requirement exceeding the CRQC timeline. Government communications, clinical records, legal privilege, financial data, trade secrets, source code for long-lived systems.
Not affected
Data with short-lived confidentiality requirements. Symmetric encryption (AES-256 is considered quantum-resistant at current key sizes with Grover’s algorithm consideration).
Required response: begin migrating key exchange to PQC algorithms (FIPS 203 / ML-KEM) for all communications carrying data with long-term confidentiality requirements. This is the highest-priority migration objective because it addresses active threat, not anticipated threat.
Threat 2 — Pre-Quantum but Urgent
Authentication & Signature Forgery
Digital signatures based on RSA or ECDSA will be forgeable by a CRQC. Software update signatures, code signing certificates, document signing, certificate authority chains, and any other authentication mechanism relying on public-key signatures will be compromised at CRQC availability. Unlike HNDL, this threat does not require collecting data now — the adversary simply needs a CRQC and access to the signed artefact. The impact is not historical data exposure but real-time authentication failure: the ability to forge software updates, certificates, and signed communications on demand.
Timeline
Becomes active at CRQC availability. Preparation must be complete before that point — certificate chains and signing infrastructure have long lead times.
Affected
Software update mechanisms, PKI hierarchies, code signing infrastructure, document signing workflows, TLS certificate chains, email signing (S/MIME), IoT device authentication, supply chain attestation, long-lived contracts and legal documents with digital signatures.
Compounding
IoT devices deployed today with 10–20 year lifespans and non-updateable cryptographic implementations will reach end-of-life before quantum risk materialises — or will be unmigratable when it does. These must be identified and planned for now.
Required response: migrate signing infrastructure to FIPS 204 (ML-DSA / Dilithium) or FIPS 205 (SLH-DSA / SPHINCS+). Begin with high-value, long-lived signatures: root CAs, code signing for critical systems, document signing for long-retention documents. Plan IoT device refresh or hybrid authentication bridges.
Threat 3 — Implementation-Layer Vulnerability
Classical Vulnerabilities Exposed During Migration
The most underestimated risk in post-quantum migration is not quantum attack — it is classical attack on the weaknesses introduced or exposed during a poorly-executed PQC migration. Adding a PQC layer to an existing system without auditing the classical cryptographic primitives that system also uses frequently reveals classical vulnerabilities that were obscured by the overall security design. A TLS session migrated to ML-KEM key exchange but using MD5 for HMAC has gained quantum resistance and exposed a classical vulnerability simultaneously. The migration process is a cryptographic audit that must be comprehensive, not selective.
Timeline
Active now. Migration-phase vulnerabilities are exploitable immediately upon deployment of a poorly-designed hybrid or partial migration.
Common patterns
Hybrid classical-PQC schemes that downgrade to classical on negotiation failure; PQC key exchange combined with weak symmetric ciphers in the negotiated suite; PQC signatures combined with classical certificate chain validation; correct PQC algorithm selection with incorrect parameter sizes; PQC implementation over side-channel vulnerable hardware.
Who is at risk
Every organisation implementing PQC without a comprehensive classical cryptography audit preceding the migration. The risk is highest for organisations implementing PQC selectively in response to compliance requirements rather than from a comprehensive migration strategy.
Required response: classical cryptography audit before and during PQC migration. The cryptographic inventory (Phase 1 of this engagement) must catalogue all cryptographic primitives in use, not only those being replaced. Every migration decision must be reviewed against the classical primitives in the same protocol path.
Why Post-Quantum Migration Is Harder Than It Appears
Eight specific technical obstacles. Each one has caused PQC migration programmes to stall, regress, or fail. None of them are visible until the migration is underway without adequate preparation.
Post-quantum migration is not “install the new algorithm and remove the old one.” It is a comprehensive cryptographic transformation of every system in the estate that uses public-key cryptography. The obstacles below are not edge cases — they are the norm. Every significant PQC migration programme encounters most of them. Understanding them before beginning the migration determines whether the programme takes 18 months or 4 years to reach the same outcome.
01
You do not know where all your cryptography is
The first requirement of any migration is a complete inventory of what is being migrated. Most organisations have no comprehensive cryptographic asset inventory. Cryptography exists in places that are not obvious — embedded in commercial off-the-shelf software, in TLS handshakes that are never reviewed, in custom-written protocol implementations from a decade ago, in IoT devices that were deployed and forgotten, in middleware that nobody owns, in legacy systems that predate the team that operates them. A PQC migration without a cryptographic inventory is a migration of the systems the team knows about. The systems the team does not know about remain vulnerable.
What happens without an inventory
An organisation completes a PQC migration of its primary application stack. A regulator performs an independent assessment. It finds a legacy system used for inter-departmental communications that was not in the migration scope because it was not in anyone’s inventory. The legacy system uses RSA-1024 — already classically weak, and the first target of a CRQC. The migration programme is declared incomplete. A second programme is required.
How the engagement addresses this
Phase 1 is a comprehensive cryptographic asset inventory using active scanning, passive traffic analysis, code review, configuration analysis, and vendor documentation review. The inventory is the foundation of every subsequent decision. We will not proceed to strategy design until the inventory is sufficiently complete — meaning we have covered all in-scope systems with documented confidence levels for each.
02
PQC key and signature sizes are significantly larger than classical equivalents
The NIST-standardised PQC algorithms are mathematically sound and considered secure against quantum attack. They are also significantly larger than the RSA and ECC algorithms they replace. ML-KEM-768 (Kyber) has a public key of 1,184 bytes versus 256 bytes for P-256 ECDH. ML-DSA-65 (Dilithium) has a signature size of 3,309 bytes versus 64 bytes for Ed25519. These size increases have real performance and compatibility implications: TLS handshake sizes increase, packet fragmentation occurs on MTU-limited networks, certificate chain sizes increase, HSM storage requirements increase, and protocol implementations that assumed fixed key sizes fail silently or loudly depending on how defensively they were written.
Where this causes failures
A financial trading system migrates its message authentication to ML-DSA. The trading protocol was designed with fixed-size authentication fields based on Ed25519 signature sizes. The larger ML-DSA signatures exceed the field length. The parsing code truncates silently. Authentication fails intermittently on a subset of message types. The failure pattern takes 3 weeks of investigation to attribute to the signature size change because no one documented the field size constraint.
How the engagement addresses this
Performance and compatibility impact assessment as part of the migration strategy: for each system in the inventory, the size impact of the PQC migration is calculated, tested in a representative non-production environment, and documented before the migration specification is written. Protocol implementations with fixed-size fields are identified and the remediation for each (field size extension, protocol version negotiation, or alternative algorithm selection) is specified before implementation begins.
03
Hardware security modules do not yet fully support PQC algorithms
Hardware Security Modules (HSMs) — the tamper-resistant devices used for high-assurance key management, certificate authority operations, and code signing — are updated through firmware upgrades and hardware refresh cycles that lag the publication of cryptographic standards by 12–36 months. Many HSMs currently in production do not support the NIST PQC algorithms in hardware. Software-only PQC implementations on general-purpose hardware do not provide the side-channel resistance and key protection properties that the HSM was deployed to provide. Migrating to PQC in software while retaining the HSM for key protection creates a hybrid that may be less secure than either approach alone.
What organisations discover at this point
An organisation discovers its HSM vendor’s PQC-capable firmware is in beta for its current HSM model and will not be production-ready for 14 months. The alternative — a new HSM model with native PQC support — requires a full HSM replacement programme including key migration, HA reconfiguration, and integration testing. What was planned as a 6-month cryptographic migration becomes a 2-year infrastructure programme.
How the engagement addresses this
HSM inventory and vendor roadmap assessment as a specific component of Phase 1. For each HSM in scope: current firmware version, PQC support status, vendor roadmap for PQC firmware availability, and the lead time for hardware refresh if firmware upgrade is not available. The migration strategy accounts for HSM readiness constraints and includes interim measures for high-assurance operations during the transition period.
04
Third-party dependencies control your cryptographic migration pace
Most organisations’ cryptographic posture is substantially determined by the libraries and platforms they depend on — OpenSSL, BouncyCastle, Java’s JCE, Windows CNG, Apple’s Security framework, cloud provider TLS implementations. Each of these has its own PQC support timeline, its own algorithm selection, and its own performance characteristics. An organisation that wants to migrate its web API to ML-KEM key exchange is dependent on its TLS library’s support, its load balancer’s support, its CDN’s support, its client libraries’ support, and every intermediate network device that terminates or inspects TLS. Any one of these that does not support the negotiated algorithm causes the connection to fall back to classical algorithms.
What dependency mapping reveals
A UK financial institution attempting to migrate its customer-facing API to hybrid TLS discovers that its CDN provider does not support ML-KEM in its TLS implementation. The CDN is used for DDoS mitigation and cannot be removed from the path. The migration of the API endpoint is blocked until the CDN provider ships ML-KEM support — which is on their roadmap for Q2 of the following year. The migration plan must be revised around this constraint.
How the engagement addresses this
Dependency mapping for every system in the migration scope: for each cryptographic usage, the library, platform, or service providing the implementation is identified, its current PQC support status is documented, and its roadmap is assessed. The migration strategy sequences the migration based on dependency readiness, identifying which systems can be migrated immediately, which are blocked on specific dependencies, and what the dependency resolution options are for each block.
05
IoT and embedded devices cannot be updated and will outlive the CRQC timeline
Industrial control systems, medical devices, building management systems, network infrastructure hardware, and consumer IoT devices typically have firmware update mechanisms that are either unavailable, limited to specific components, or require physical access. Many devices currently deployed have expected operational lifespans of 10–25 years and use classical public-key cryptography implemented in hardware or in firmware that was compiled against classical cryptographic libraries. These devices will be in operation when quantum computers capable of attacking their cryptography arrive. They cannot be remediated in place. The organisation must either plan for early replacement, implement a network-layer mitigation, or accept the risk explicitly.
Why this is frequently underestimated
A healthcare trust operates 340 networked medical devices. Assessment reveals that 280 of them have firmware that cannot be updated to support PQC algorithms. 180 of those devices are within 5 years of their expected end-of-life. 100 are mid-cycle replacements that the trust cannot afford to replace early on the current capital budget. The PQC programme must now include a multi-year device replacement plan and interim network segmentation as a compensating control.
How the engagement addresses this
IoT and embedded device assessment as a distinct workstream within the cryptographic inventory: for every device category, the update mechanism, the cryptographic implementation, the expected operational lifespan, and the replacement cost. The migration strategy includes IoT-specific recommendations: early replacement scheduling, network segmentation to limit the blast radius of compromised devices, quantum-safe VPN tunnels to protect IoT communications at the network layer when device-level remediation is not feasible.
06
Hybrid classical-PQC schemes must be designed carefully to avoid downgrade attacks
The recommended transitional approach is hybrid cryptography: combining a classical algorithm (ECDH) with a PQC algorithm (ML-KEM) so that the session key is secure as long as either algorithm is secure. This provides protection against both quantum attack (PQC layer) and potential PQC implementation vulnerabilities (classical layer). However, hybrid schemes introduce a negotiation phase. If the negotiation is not protected against downgrade attack — where an adversary intercepts the negotiation and forces both parties to use only the classical algorithm — the hybrid provides no quantum protection at all. Designing a hybrid scheme that resists downgrade requires careful attention to the negotiation mechanism and the failure modes of each component library’s hybrid implementation.
Where downgrade vulnerabilities appear
A hybrid TLS implementation using X25519+ML-KEM-768 has a fallback path to X25519-only for clients that do not support the hybrid key share. An adversary performing an active man-in-the-middle attack strips the ML-KEM key share from the Client Hello, causing the server to fall back to classical-only. The session is established under classical ECDH with no quantum protection. No alert is raised. The hybrid implementation provided no security against the HNDL attack because the fallback was not protected.
How the engagement addresses this
Hybrid scheme design review for every migration phase that involves hybrid cryptography: the negotiation mechanism, the fallback conditions, the fallback protection mechanisms, and the alert and audit trail for any fallback event. Where the library or platform does not support adequately protected fallback, the migration strategy specifies a non-hybrid approach for that system rather than a downgrade-vulnerable hybrid.
07
Performance degradation in constrained environments
PQC algorithms are computationally more expensive than their classical equivalents. ML-KEM key encapsulation is several times slower than ECDH key exchange on standard hardware. ML-DSA signature generation is 20–50× slower than Ed25519 on constrained hardware. For high-throughput systems, the performance impact may require infrastructure scaling. For constrained embedded systems, the performance impact may mean that PQC operations exceed the available processing budget entirely. For real-time systems with strict latency requirements — industrial control, trading systems, SCADA — the added latency of PQC operations in the critical path may be unacceptable without architectural changes.
What performance testing reveals
A trading platform migrates its order authentication from Ed25519 to ML-DSA. Benchmark testing shows that ML-DSA signature verification is 38× slower than Ed25519 on the platform’s embedded order-matching hardware. The latency added by signature verification in the order-matching critical path exceeds the platform’s latency budget by 2.1ms. The migration cannot proceed without redesigning the authentication architecture to move signature verification off the critical path — a 6-month architectural programme not in the original migration scope.
How the engagement addresses this
Performance impact assessment for every migration candidate: benchmark testing of the selected PQC algorithm on the specific hardware and software stack of the target system, under representative load. For systems with latency or throughput constraints, the performance assessment precedes the migration specification. If the performance impact is unacceptable, the specification addresses the architectural change required to accommodate it — not by ignoring the constraint but by solving it before implementation.
08
Certificate lifecycle management must be redesigned, not just re-keyed
The PKI infrastructure that underlies TLS, code signing, and document authentication was designed around classical algorithms with specific key size and lifetime assumptions. PQC certificates have different size properties, different performance characteristics in chain validation, and different lifetime considerations. Migrating to PQC certificates requires not just re-issuing certificates with new algorithms but rethinking the certificate hierarchy, the validation chain performance, the CRL and OCSP infrastructure, the CA key ceremony procedures for PQC CAs, and the certificate pinning implementations that will reject PQC certificates if they hard-code classical algorithm identifiers. Organisations that re-issue certificates without addressing the PKI architecture produce a PQC certificate hierarchy that is operationally worse than the classical hierarchy it replaced.
What PKI migration failures look like
A government agency migrates its document signing PKI to ML-DSA. Certificate chain validation time increases by 340% due to the larger ML-DSA signature sizes in the chain and the lack of OCSP stapling configuration for the new hierarchy. High-volume document processing applications that validate thousands of signatures per minute hit processing capacity limits. The PKI was migrated; the infrastructure to operate it at production scale was not redesigned to account for the performance change.
How the engagement addresses this
PKI architecture review as a standalone workstream: the certificate hierarchy, the CA key management procedures, the OCSP and CRL infrastructure, the certificate pinning inventory, and the chain validation performance under PQC algorithm characteristics. The migration specification includes the PKI architecture changes required, not only the certificate re-issuance plan.
The Five-Phase Migration Programme
Five phases. Each phase produces a specific, verifiable output. None of them can be skipped. All of them can be scoped and priced independently.
The complete migration programme runs all five phases sequentially. Phases 1 and 2 are almost always engaged together — the inventory is the prerequisite for the risk assessment, and the risk assessment is the prerequisite for everything else. Phases 3, 4, and 5 can be phased by system priority, allowing high-priority systems to reach Phase 5 before lower-priority systems have completed Phase 3. The programme can be entered at Phase 1 regardless of what prior work has been done — we will assess and document any existing work against the Phase 1 standards and incorporate it rather than repeating it.
Phase 1
Cryptographic Asset Inventory
A comprehensive inventory of every cryptographic algorithm, key, certificate, protocol, library, and cryptographic dependency in the in-scope systems. The foundation of all subsequent decisions. Cannot be skipped or abbreviated — a migration plan built on an incomplete inventory is a plan for the systems the team knows about, which is not the same as the systems the organisation operates. Typically combined with Phase 2 in a single engagement.
£28,000–£95,000
Scale-dependent · fixed · VAT excl.
8–16 weeksDepends on number of in-scope systems, access complexity, and whether legacy systems require manual inspection. Classified or air-gapped systems add significant time.
Discovery Methods
Active scanning: network-level cryptographic algorithm enumeration across in-scope IP ranges — TLS cipher suite negotiation, SSH key exchange algorithms, SMTP STARTTLS configuration, RDP, VPN endpoints
Passive traffic analysis: sampling of internal network traffic to identify cryptographic protocols in use that are not visible from active scanning (internal mTLS, legacy protocols, custom implementations)
Code repository analysis: static analysis of codebases for cryptographic library imports, hard-coded algorithm identifiers, and custom cryptographic implementations
Configuration review: TLS configuration files, certificate stores, CA configurations, HSM configurations, key management system settings
Vendor documentation review: for COTS software and SaaS platforms, vendor cryptographic algorithm documentation and published PQC roadmaps
IoT and OT device enumeration: device type identification, firmware version, cryptographic capability documentation, expected operational lifespan
Inventory Outputs
Asset register: every cryptographic asset catalogued — algorithm, key size, certificate expiry, usage context, owning system, and data classification of the assets protected
Algorithm prevalence map: which algorithms are in use, where, how many instances, and which systems they protect
Library dependency graph: which cryptographic libraries are in use, their PQC support status, and the systems that depend on each
HSM inventory: every HSM, its firmware version, its PQC support status, and its vendor roadmap
IoT risk register: every IoT/OT device with a classical cryptographic dependency, its update capacity, its operational lifespan, and its expected risk at CRQC availability
Coverage confidence rating: for each system category, the confidence level in the inventory completeness, with documented gaps and the plan to address them
Pricing Basis
£28,000: up to 50 systems, predominantly web and application layer, standard access, no classified or air-gapped components
£48,000: up to 150 systems including OT/IoT, legacy systems requiring manual inspection, multiple site locations
£75,000–£95,000: enterprise estate (150+ systems), multiple security classifications, legacy systems with no documentation, industrial control systems, medical device estate
Government and defence estates with high security classifications: separately scoped — classified environment access requirements affect methodology and timeline significantly
The most common Phase 1 finding that changes the programmeA significant proportion of cryptographic usage is in systems with no identified owner. Custom-written protocol implementations from 5–15 years ago that no current team member wrote. Middleware configurations that were set up once and never reviewed. SaaS platforms whose TLS configuration is controlled by the vendor. The inventory reveals these and creates ownership assignments where none existed — which is a separate organisational task from the technical inventory, and which frequently delays Phase 2 because the systems cannot be assessed without an owner.
Phase 2
Quantum Vulnerability Assessment & Risk Prioritisation
Assessment of each cryptographic asset in the inventory against the three threat models, producing a prioritised risk register that drives the migration sequence. The risk assessment must account for the data classification of the assets protected, the confidentiality longevity requirement of that data, the system’s operational criticality, and the technical constraints on migration. Not all systems are equally urgent — and incorrectly prioritising high-effort low-risk systems over low-effort high-risk systems is one of the most common ways PQC migration programmes waste time and money.
£18,000–£42,000
Inventory-dependent · fixed · VAT excl.
4–8 weeksDepends on inventory size and data classification complexity. Typically combined with Phase 1.
Risk Dimensions Assessed
Data sensitivity and longevity: what data is protected, its classification, and the period for which it must remain confidential — the primary HNDL risk driver
Algorithm vulnerability: RSA-2048, RSA-4096, P-256, P-384, X25519, Ed25519, DSA, DH — the quantum vulnerability profile of each, including the key size dependency for Grover’s algorithm against symmetric components
Harvest exposure: whether the system’s traffic is likely to be collected by a capable adversary today — based on the system’s exposure, the organisation’s threat profile, and the data classification
Migration complexity: estimated effort to migrate each system, based on the dependency mapping, HSM constraints, IoT update limitations, and performance requirements
Classical vulnerability co-assessment: weaknesses in the classical cryptographic configuration that exist independently of quantum risk and that may be exposed or worsened by migration
Assessment Outputs
Quantum risk register: every cryptographic asset rated by quantum risk level (critical, high, medium, low) with the specific evidence for each rating
HNDL exposure list: the specific data assets and system communications most at risk from harvest-now-decrypt-later, ranked by data sensitivity and harvest likelihood
Migration priority matrix: Phase 3 entry sequence for each system based on risk level, migration complexity, and dependency readiness
Classical vulnerability summary: classical cryptographic weaknesses identified during the assessment that require remediation independent of PQC migration
Executive risk briefing: a non-technical summary of the organisation’s quantum cryptographic risk position suitable for board-level communication and regulatory disclosure
Regulatory Alignment
NCSC guidance alignment: assessment mapped to NCSC post-quantum cryptography guidance and migration recommendations
FCA / PRA: alignment with UK financial regulatory expectations for cryptographic resilience under DORA ICT risk management requirements
MHRA / NHS: alignment with NHS DSPT cryptographic requirements and MHRA guidance for medical device software cryptographic controls
HMG security classifications: for government clients, alignment with the NCSC’s guidance for systems operating at OFFICIAL, SECRET, and TOP SECRET classifications
GDPR and UK GDPR Article 32: assessment of whether current cryptographic measures meet the “appropriate technical measures” requirement given the quantum risk horizon
Phase 3
PQC Migration Strategy & Algorithm Selection
The strategic design of the migration: which PQC algorithms are selected for each use case, whether hybrid or pure PQC approaches are appropriate for each system, the migration sequencing and dependencies, the hybrid transition architecture for systems that must support both classical and PQC clients during the transition period, and the cryptographic agility design that will allow future algorithm changes without repeating the full migration programme. Phase 3 produces the strategy from which Phase 4 derives the implementation specifications for each system.
£35,000–£85,000
Estate-dependent · fixed · VAT excl.
8–14 weeksDepends on the number of distinct system architectures requiring migration strategies. Organisations with homogeneous technology stacks complete Phase 3 significantly faster.
Algorithm Selection
Key encapsulation: ML-KEM-512, ML-KEM-768, or ML-KEM-1024 selection based on security level requirements and performance constraints of each system
Digital signatures: ML-DSA-44, ML-DSA-65, or ML-DSA-87 vs. SLH-DSA for use cases where stateless hash-based signatures are preferred for their different security assumptions
Hash functions: SHA-3 and SHAKE256 selection where required by PQC algorithm specifications or where SHA-2 weakness to quantum speedup is relevant
Symmetric layer: AES-256 retained (Grover’s algorithm provides only quadratic speedup, effectively halving the security level — AES-256 provides 128 bits of post-quantum security); AES-128 upgraded where post-quantum security margins require it
NIST backup algorithms: BIKE and HQC as additional key encapsulation candidates for systems where algorithm diversity against potential ML-KEM weaknesses is required
Transition Architecture
Hybrid scheme design: X25519+ML-KEM-768 for TLS key exchange, Ed25519+ML-DSA for signing — with downgrade attack protection specifications for each
Migration sequencing: the system-by-system migration sequence based on the Phase 2 priority matrix, dependency constraints, and HSM readiness
Client compatibility strategy: how systems that must serve both PQC-capable and classical clients during the transition period handle the two populations — dual-stack, algorithm negotiation, or parallel endpoints
PKI hierarchy redesign: root CA, intermediate CA, and end-entity certificate hierarchy for PQC certificates, including the dual-signature approach for hybrid PKI
IoT mitigation strategy: quantum-safe VPN tunnelling, network segmentation, and device replacement scheduling for non-updatable devices
Cryptographic Agility Design
Algorithm abstraction layer: the software architecture pattern that separates cryptographic algorithm selection from cryptographic usage — enabling future algorithm changes without application code modification
Key management for agility: key storage, metadata tagging, and rotation procedures designed to accommodate algorithm changes without re-keying all existing assets
Protocol negotiation for agility: TLS and other protocol configurations designed to support algorithm negotiation rather than hard-coded algorithm selection
Monitoring for agility: cryptographic algorithm monitoring that alerts when algorithms in use differ from the current approved algorithm set — detecting unauthorised algorithm downgrade and configuration drift
Future migration trigger criteria: the specific conditions under which another cryptographic migration should be initiated — based on NIST guidance updates, NCSC recommendations, or emerging cryptanalytic results
Why cryptographic agility is not optionalThe NIST PQC algorithms are new. ML-KEM and ML-DSA were standardised in 2024 after 6 years of analysis, but cryptanalysis of new algorithms continues after standardisation. If a significant weakness in ML-KEM is discovered in 5 years, organisations without cryptographic agility will face another full migration programme. Organisations with cryptographic agility will update an algorithm configuration. Cryptographic agility is not a luxury feature of the migration strategy — it is the mechanism that ensures this is the last full migration programme the organisation must conduct.
Phase 4
Implementation Specifications & Migration Runbooks
System-by-system implementation specifications that translate the Phase 3 strategy into the specific technical steps, configuration changes, library versions, certificate procedures, HSM operations, and test cases required for each system’s migration. Implementation is performed by your engineering teams or infrastructure partners from these specifications. The specifications are written at the level of detail that allows an engineer who was not involved in Phases 1–3 to implement the migration correctly without reinterpreting strategic decisions.
£42,000–£160,000
System count-dependent · fixed · VAT excl.
10–24 weeksEach distinct system architecture requires a separate implementation specification. Organisations with 50+ distinct architectures should expect the upper end of the timeline.
Per-System Specifications
TLS migration: exact cipher suite configurations, minimum TLS version, session resumption settings, OCSP stapling configuration, certificate transparency, HSTS configuration — for each web server, load balancer, and API gateway in scope
Library upgrade specifications: exact library versions, configuration parameters, and integration changes for each cryptographic library upgrade (OpenSSL, BouncyCastle, libsodium, etc.)
Certificate issuance procedures: for each CA in scope, the exact procedure for issuing PQC or hybrid certificates — including the HSM operations, the certificate profile configuration, and the testing steps
SSH migration: server-side and client-side configuration for ML-KEM key exchange in OpenSSH, including known_hosts format changes and host key re-keying procedures
VPN and IPsec: IKEv2 configuration for PQC key exchange, including vendor-specific configuration syntax for each VPN platform in scope
Migration Runbooks
Pre-migration checklist: verification steps confirming prerequisites are in place before migration begins for each system
Step-by-step migration procedure: the exact sequence of operations, with decision points and the criteria for proceeding or stopping at each
Validation tests: the specific tests run after each step to verify the migration step succeeded before proceeding
Rollback procedure: the exact steps to revert the migration if a validation test fails or an unexpected problem is encountered — with the maximum time allowed at each step before rollback is triggered
Go/no-go criteria: the specific conditions that must be met for the migration to proceed to the next system in the sequence
Communication templates: notifications to internal stakeholders, certificate subscribers, and external dependencies at each migration milestone
Test Specifications
Cryptographic correctness tests: verification that the PQC implementation produces correct outputs — using NIST test vectors for ML-KEM and ML-DSA
Interoperability tests: verification that the migrated system correctly interoperates with both PQC-capable and classical clients during the hybrid transition period
Downgrade attack tests: verification that the hybrid scheme correctly rejects downgrade attempts to classical-only operation
Performance tests: latency and throughput measurements under representative load, compared against the Phase 3 performance impact assessment baselines
Certificate chain validation tests: verification that the full certificate chain validates correctly in all client environments in scope
Phase 5
Post-Migration Validation & Cryptographic Agility Programme
Independent validation of the completed migration and establishment of the ongoing cryptographic monitoring and agility programme. Phase 5 is not a one-time delivery — it establishes the operational capability that keeps the organisation’s cryptographic posture current as the quantum threat develops, as NIST and NCSC guidance evolves, and as the PQC algorithm landscape matures. This phase can be structured as a time-limited programme engagement or as an ongoing advisory retainer.
£22,000–£65,000
Programme or retainer · VAT excl.
Programme: 6–10 weeksOngoing retainer: £8,500–£24,000/year depending on estate size and review frequency.
Post-Migration Validation
Independent cryptographic scanning: re-run of the Phase 1 active scanning and passive traffic analysis to verify that all in-scope systems have been successfully migrated
Residual classical algorithm detection: identification of any remaining RSA or ECC usage in the in-scope estate that was not addressed by the migration programme
Hybrid scheme validation: verification that hybrid schemes are operating correctly and that downgrade protections are functioning as specified
PKI chain validation: end-to-end certificate chain validation for all PQC certificate hierarchies
Performance baseline confirmation: measured performance of migrated systems against the Phase 3 targets
Migration completion report: documented evidence of migration completion suitable for regulatory reporting and board assurance
Cryptographic Agility Programme
Cryptographic monitoring implementation: tooling configuration for continuous monitoring of algorithms in use against the approved algorithm set
Algorithm drift alerting: detection and alerting when configuration changes or new system deployments introduce unapproved classical algorithms
Certificate expiry management: monitoring and alerting for PQC certificate expiry — PQC certificates have shorter recommended lifetimes than classical certificates in some implementations
NIST/NCSC guidance monitoring: ongoing monitoring of NIST and NCSC post-quantum guidance for algorithm updates, security level revisions, or new standardisation activity
Annual cryptographic posture review: structured annual review of the cryptographic posture against the current threat model, identifying any new risks from changed threat intelligence, algorithm vulnerabilities, or guidance updates
Regulatory Reporting
NCSC reporting: migration completion documentation in the format required by NCSC guidance for government and critical national infrastructure organisations
FCA/PRA reporting: ICT risk management documentation for DORA compliance, including cryptographic resilience evidence
Board assurance pack: migration completion evidence, residual risk summary, ongoing monitoring summary, and forward-looking agility plan for board-level assurance
Supply chain attestation: documentation of cryptographic standards applicable to suppliers and third parties — for organisations whose supply chain assurance programmes include cryptographic requirements
Bilateral Obligations
Client Obligations
Provide full access for the cryptographic inventory — including systems that are sensitive, legacy, or assumed to be cryptographically unimportant
The cryptographic inventory must cover the full in-scope estate. Systems excluded from the inventory because access is complicated, because they are assumed to use standard configurations, or because no one wants to acknowledge they exist remain vulnerable after the migration is complete. The most consequential cryptographic vulnerabilities are typically in the systems that are hardest to assess — the undocumented legacy systems, the air-gapped environments, the third-party managed systems. Access must be arranged before the engagement begins for all in-scope systems.
If a system is excluded from the inventory scopeIt is documented as out of scope with the reason. The risk register notes the exclusion. The migration completion report notes that the migration does not cover excluded systems. Regulatory assurance based on the completion report cannot be claimed for excluded systems.
System owners must be identified and engaged throughout the migration programme
The cryptographic migration of any production system requires the involvement of the person responsible for that system’s availability, configuration, and change management. The Phase 4 migration runbooks are designed to be executable by the system owner’s team. They cannot be executed by someone unfamiliar with the system. Identifying system owners — and ensuring they are engaged and committed to the migration timeline — is the client’s organisational responsibility. A migration programme without identified system owners stalls when implementation begins.
If system owners are not identified or are unavailable for migration phasesThe migration for those systems is deferred until ownership is established. Deferred systems remain on the risk register as unmigrated. If regulatory deadlines require migration completion, the ownership establishment must be resolved before the deadline, not after.
RJV Obligations
Algorithm recommendations based on current NIST and NCSC guidance, disclosed when we disagree with guidance
Our algorithm recommendations follow NIST FIPS 203, FIPS 204, and FIPS 205 as the primary standards, supplemented by NCSC guidance for UK-specific regulatory contexts. Where our assessment of a system’s requirements leads us to recommend a configuration that differs from the default guidance — for example, recommending SLH-DSA over ML-DSA for a specific signing use case due to its different security assumptions — we disclose the difference from the default guidance and the reasoning. We do not follow guidance dogmatically when the specific deployment context justifies a different approach, but we always document when and why we deviate.
If NIST or NCSC guidance changes after delivery of Phase 3 or Phase 4Significant guidance changes within 12 months of delivery are assessed against the delivered strategy and specifications at no additional cost, with a written assessment of whether the guidance change requires any specification revisions. Changes that require material specification revisions are priced as scope additions.
Risk findings reported as found — including findings about systems the organisation considers well-managed
The cryptographic inventory and vulnerability assessment will find weaknesses that the organisation’s security team did not know were there. Some of those weaknesses will be in systems that the team considers well-secured. We report all findings accurately — including findings that imply that a previous security assessment missed something, that a vendor made a commitment about cryptographic standards that the implementation does not meet, or that a compliance certification was obtained for a system whose cryptographic configuration does not meet the certified standard. These findings are reported to the organisation, not withheld to protect sensitivities.
If a finding is disputedWe review the evidence with the system owner and document the dispute. We revise findings where the challenge is technically substantive. We do not revise findings in response to discomfort with their implications.
Questions every organisation should be able to answer about its post-quantum cryptographic position
We do not think we will be a target for nation-state adversaries. Does harvest-now-decrypt-later still apply to us?
Harvest-now-decrypt-later collection is not selective. Nation-state actors performing bulk collection are collecting encrypted traffic at scale, not specifically targeting individual organisations. The collection is passive and pervasive — major internet exchange points, submarine cable taps, and compromised transit infrastructure collect traffic indiscriminately. If your communications traverse public internet infrastructure, they are likely being collected. The relevant question is not whether you are a target but whether the data in your communications has value to any adversary at any point in the next 10–15 years. Healthcare records, financial data, legal privilege, trade secrets, personnel data, source code, and strategic plans all have long-term value to a wide range of adversaries. The HNDL threat is not about being specifically targeted. It is about the value of the data you encrypt today to someone who will be able to decrypt it in a decade.
Quantum computers capable of breaking RSA are not here yet. Why do we need to start now?
Three reasons. First, the HNDL attack is already in progress — the window for protecting data that must remain confidential for more than the quantum timeline has already partially closed for data encrypted in recent years. Second, the migration takes time — enterprise cryptographic migrations of any significant complexity take 2–5 years from planning to completion. An organisation that starts when quantum computers arrive will not complete the migration before they are exploitable. Third, regulatory and compliance requirements are moving ahead of the quantum computer — the UK NCSC, US NSA, and EU ENISA have all issued guidance recommending migration begin now. Financial sector regulators are beginning to incorporate post-quantum cryptographic resilience into their ICT risk management expectations. The compliance requirement will arrive before the quantum computer.
Our TLS library (OpenSSL / BouncyCastle / etc.) already supports ML-KEM. Does that mean we are protected?
Library support is necessary but not sufficient. A library that supports ML-KEM is available to be configured to use ML-KEM. That does not mean your applications, web servers, load balancers, CDNs, and API gateways are configured to use it. It does not mean the hybrid scheme that combines ML-KEM with ECDH is correctly designed to resist downgrade attacks. It does not mean the certificate chain presented by your server is issued by a PQC or hybrid CA. It does not mean the same library version is deployed consistently across your estate. And it does not mean that the other cryptographic components in the same protocol path — the cipher suite, the HMAC algorithm, the certificate validity period — meet current recommendations. Library support is the starting point for a migration, not the ending point.
We are a small organisation. Is this engagement sized for us?
The Phase 1 + Phase 2 combination is available at £28,000–£60,000 for smaller organisations with fewer than 50 in-scope systems. For organisations with a straightforward technology stack — standard web application hosting, commercial SaaS providers, minimal on-premises infrastructure — the Phase 1 inventory may reveal that the migration is primarily a matter of TLS configuration updates, library upgrades, and certificate renewals, all of which are relatively straightforward to specify in Phase 3 and implement in Phase 4. The complexity and cost of the migration programme is driven by the complexity and heterogeneity of the cryptographic estate, not by the size of the organisation. A small organisation with a simple, modern infrastructure may have a simpler migration than a large organisation with legacy systems accumulated over decades.
How does this relate to the cryptographic controls in ISO 27001, Cyber Essentials, and DORA?
ISO 27001 Annex A.8.24 requires that cryptographic controls be appropriate to the classification of the information being protected. The current interpretation of “appropriate” is evolving to include quantum-resilience for long-lived or sensitive data — but ISO 27001 does not yet mandate PQC migration specifically. Cyber Essentials requires patch management and appropriate configuration of technical controls but does not address PQC specifically. DORA Article 9 requires that financial entities’ ICT risk management frameworks include “state of the art” cryptographic controls — and the EBA’s guidance on DORA implementation is beginning to incorporate post-quantum considerations. The most direct current regulatory driver in the UK is the NCSC’s guidance, which is advisory but increasingly expected in government and CNI supply chain requirements. The engagement produces documentation that satisfies the cryptographic resilience evidence requirements of all of these frameworks — but the primary driver for starting the engagement should be the actual threat, not the current regulatory requirement, which will catch up with the threat model on a delay.
What are your payment terms and how is the programme structured commercially?
Each phase is a separate fixed-price engagement: 50% on signing, 50% on delivery acceptance. Phases can be engaged sequentially or Phases 1 and 2 can be engaged together under a single contract. Phases 3 and 4 require the completion of Phases 1 and 2 — the strategy and implementation specifications cannot be written without the inventory and risk assessment. Phase 5 can be engaged at the completion of Phase 4 or structured as an ongoing retainer from the programme outset. There are no hidden milestone payments, no retrospective scope additions, and no requirement to engage all phases — an organisation that wants only Phases 1 and 2 to understand its position before making further decisions is free to stop there. The Phase 5 ongoing retainer is £8,500–£24,000 per year depending on estate size, billed quarterly in arrears.
The assessment session takes 90 minutes. The question it answers is how far behind you currently are — and whether that gap is closing or widening.
We review your current understanding of your cryptographic estate: what you know about your TLS configurations, your certificate hierarchies, your HSMs, your key management systems, and your IoT and OT devices. We assess your organisation’s data sensitivity profile and the HNDL exposure implied by your current cryptographic posture. At the end of the session you have a preliminary view on your quantum risk position, the highest-priority assets requiring urgent attention, and the scope of the Phase 1 inventory required to move from preliminary view to documented evidence.
Every month that passes without beginning the migration is a month in which data encrypted today under RSA or ECC accumulates in adversaries’ collection systems. The data encrypted in that month may be sensitive for the next decade. The decision to begin is not about predicting when quantum computers will arrive — it is about acknowledging that the harvest has already begun, and that the protection window for data with long-term confidentiality requirements is already narrowing.
Format
Video call or in-person in London. 90 minutes.
Cost
Free. No commitment.
Lead time
Within 5 business days of contact.
Bring
What you currently know about your cryptographic estate: which TLS versions and cipher suites your external-facing systems use, whether you use HSMs and which, any existing PQC assessment work or vendor communications about PQC roadmaps, your data sensitivity profile (what data is sensitive for how long), and any regulatory or compliance drivers that are pushing the migration timeline.
Attendees
CISO or security lead and a technical architect or infrastructure lead who understands the cryptographic systems in detail. Both perspectives are needed. From RJV: a post-quantum cryptography specialist. Not a vendor with a product to sell.
After
Written preliminary assessment within 3 business days. Fixed-price Phase 1 + Phase 2 scope within 5 business days if you want to proceed.