PQC · crypto agility
Prepare products and systems for cryptographic change
Start by understanding where you use cryptography, what it protects and how it can be updated. We help turn that knowledge into a feasibility assessment, migration plan and test evidence.
Two connected needs
PQC — post-quantum cryptography
Cryptographic mechanisms designed to resist attacks using quantum computers. Migration requires an assessment of use cases, protocols and dependencies.
Crypto agility — the ability to change
The ability to change algorithms, protocols, keys and their use in products and systems securely. It encompasses architecture, processes, updates and supplier cooperation.
For embedded devices and OT, long operational lifetimes, constrained resources, firmware signatures and compatibility with existing infrastructure are particularly important. The same approach helps address a compromised key, an unsupported library or a change of supplier.
Profiling a specific product configuration
The unit of analysis is the use of cryptography in a precisely identified configuration, such as a product family, hardware revision, bootloader and firmware version. Assessing one variant does not replace checking the others.
- Function: secure boot, update signing, communications, device identity or protection of stored data.
- Implementation: algorithm and parameters, library or supplier, protocol and hardware dependencies.
- Trust: references to keys, certificates and trust anchors, and the ability to replace and revoke them.
- Assessment basis: documentation, configuration, code, SBOM or cryptographic inventory, and test results, with information sources and gaps identified.
We distinguish confirmed behaviour, conditional capabilities and unknowns. An algorithm’s presence in a library does not prove that a device uses it or can transition securely to a new mechanism.
Can the change be made safely?
Update feasibility and hardware limits
We check what can be changed in software and what is constrained by ROM, the bootloader or a component that cannot be updated. We account for device recovery after an interrupted change.
Resources and compatibility
We assess execution time, memory, message and firmware image sizes, and interoperability with legacy devices, backends and service tools.
Transitioning between trust anchors
We establish the sequence for deploying a new verifier and trust anchors, changing the signing system and retiring old keys. These conditions must be tested on the target hardware.
The assessment identifies confirmed, conditional, blocked or unknown capabilities, with reasons and a next action. We do not reduce critical constraints to a single readiness percentage.
Three separate migration paths
Communications
Changing TLS or another protocol requires checking both ends of the connection, mechanism negotiation, latency and interoperability. An intermediary gateway may protect only a particular segment of the communication path.
Update signatures
A compatible signing system and on-device verification are required, along with secure trust distribution and a recovery procedure. We also test rejection of unauthorised images and prohibited rollbacks.
Secure boot
The ROM → bootloader → firmware chain may contain mechanisms that cannot be updated. We check hardware limits and whether the change requires a different device variant.
Changing communication protection does not migrate firmware signatures or secure boot. We assess each path separately and bring them together in a plan for a specific configuration.
From an inventory to a verified change
- Scope and inventory: select the product family, hardware revision and firmware version; gather cryptographic use cases and evidence.
- Feasibility assessment: update, resource and dependency constraints; compare a native change, an adapter or hardware replacement.
- Migration plan: sequence of changes, trust-transition conditions, responsibilities and acceptance criteria.
- Pilot and testing: an agreed scenario on a real device, interoperability, resource use and behaviour after an interrupted update.
- Decision and maintenance: evidence linked to the configuration, release conditions and assessments to repeat after a change.
The outcomes are an inventory with confidence levels, a feasibility assessment, a migration plan and organised test evidence. We select the scope according to the decision the team needs to make.
Pilot proposal: one product, one change
Example scope to be agreed: one IoT or OT product, one hardware revision, two firmware versions and one cryptographic change scenario tested on a real device.
This could involve moving to a new communication-protection mechanism or changing update signatures. We first agree access to the device, documentation and test environment, and measurable criteria.
- A cryptographic profile and explicit information gaps for both versions.
- A comparison of possible change paths and their limitations.
- A plan with the sequence, conditions, responsibilities and recovery procedure.
- Test results for trust transition, interrupted updates and resource use, as appropriate to the selected scenario.
- An evidence package and a review of the change’s impact on documentation and the release decision.
This is a proposal for cooperation and R&D work, rather than a description of a completed deployment or a finished product. Integration, timing and resources are agreed individually.
Standards are a starting point
NIST has published ML-KEM / FIPS 203 for key establishment, and ML-DSA / FIPS 204 and SLH-DSA / FIPS 205 for digital signatures.
Current information: NIST — Post-Quantum Cryptography. Selecting a mechanism depends on its function, protocol, implementation and product constraints.
Using a PQC algorithm alone does not constitute product certification or CRA compliance. We connect the migration plan with risk assessment and maintenance arrangements for the specific system.
A shared concern for products and OT
In a CRA project, cryptography is part of the architecture and support period. In OT, a change must account for process continuity and suppliers’ capabilities.
The manufacturer decides whether a product version is ready, while the operator decides the conditions for deployment in a specific plant. We help organise the information both sides need, including supported configurations, limitations and update requirements.
CRA and the product lifecycle · OT cybersecurity · Training and workshops
Resources and further discussion
nis2cra.com
Resources, analyses, qualification tools and initiatives on NIS2, the CRA and OT cybersecurity.
cratrace.com
cratrace — a project for managing information and evidence throughout the product lifecycle in the context of CRA requirements.
Let’s discuss cryptographic readiness
Tell us which product or system you are analysing, how long it needs to operate and what change lies ahead. You do not need a complete inventory to begin.