A cryptographic algorithm can be standardized and still be impractical on a particular device. The October 15 revision of the IETF working-group draft Adapting Constrained Devices for Post-Quantum Cryptography examines PQC in IoT nodes, secure elements, TPMs, small hardware security modules, and other systems limited by processing power, RAM, flash storage, or battery capacity.
The draft is in IESG evaluation with an intended Informational status; it is still work in progress, not a final RFC. It nevertheless exposes a critical planning issue: a product-level statement of PQC support does not prove that a deployed hardware model can generate, store, use, rotate, back up, and recover the required keys within its operational limits.
“Constrained” belongs in the inventory
Traditional asset inventories often capture model and firmware but omit the resources available to cryptographic operations. For PQC planning, teams may need to know RAM, nonvolatile storage, processor characteristics, power constraints, cryptographic-module boundaries, supported key representations, and which operations can be offloaded.
A migration-ready device record should connect:
- hardware model, revision, firmware, owner, location, and service role;
- cryptographic module or secure-element model and lifecycle status;
- supported PQC algorithms, parameter sets, and operations;
- available RAM, storage, power, and acceptable latency;
- seed, expanded-key, cache, and ephemeral-key behavior;
- secure boot, firmware-signing, and attestation dependencies;
- backup, transfer, recovery, rotation, and end-of-life procedures; and
- benchmarks and tests tied to the exact configuration.
Without this context, a capability flag can direct remediation toward a configuration the device cannot safely sustain.
Key representation changes operational behavior
The draft discusses storing a compact seed and deriving an expanded private key when needed. That can reduce persistent storage, but derivation consumes compute and may add latency. Caching an expanded key can improve performance while increasing the sensitive material present in memory.
These are not invisible implementation details. The inventory should record whether a device retains the seed, the expanded private key, or both; where transient material exists; how it is erased; whether imported keys are compatible; and what happens after hardware failure.
A seed is a critical security parameter because it can reproduce the private key. It needs protection equivalent to the key it derives. “Only a seed is stored” must never be interpreted as lower sensitivity.
Backup and recovery are part of PQC readiness
A device may perform a PQC operation successfully and still fail the lifecycle test. If it cannot securely export or recover key material, hardware replacement can become an identity-loss event. If backups use a weaker channel or wrapping key, the strongest on-device algorithm does not protect the transfer.
Teams should test backup creation, authorization, encryption strength, restore to an approved replacement, audit evidence, and destruction of obsolete copies. They should also identify keys that must not be exported and document the alternative recovery or re-enrollment path.
Recovery evidence is especially important for devices with long service lives, remote locations, limited maintenance access, or safety-critical roles.
Firmware trust may be the limiting dependency
Constrained devices often depend on signatures for secure boot and firmware updates. A device may not need to generate a post-quantum signature, but it must be able to store the public key, receive a larger signature or package, verify it within resource limits, and recover safely from failure.
That makes the signing service, release pipeline, package format, transport, bootloader, recovery image, and device verifier one migration chain. A PQC-capable network session does not compensate for a firmware lifecycle that remains immovable.
Benchmarks need operational distributions
Average execution time is not enough for algorithms whose operations can vary. Teams should measure worst-case or high-percentile latency, memory peaks, energy use, failure rates, and concurrency under realistic workloads. They should also test cold start, key rotation, firmware verification, recovery, and degraded conditions.
Results must be tied to the exact hardware, firmware, compiler, cryptographic implementation, parameter set, and optimization. Otherwise a benchmark cannot support a production decision.
What organizations should do next
First, identify constrained devices and embedded cryptographic modules as a distinct migration population. Do not infer readiness from the surrounding server or gateway.
Second, add resource and key-representation fields to the canonical inventory. Preserve supplier claims separately from tested behavior.
Third, test complete lifecycles: enrollment, routine use, rotation, backup, restoration, firmware update, failure, and retirement.
Fourth, prioritize devices whose replacement cycles extend beyond migration deadlines or whose firmware trust chain cannot be changed remotely.
Finally, record unknowns and inaccessible populations. Discovery gaps are not evidence that unsupported devices are absent.
How Vista Platform helps
Vista Platform is a self-hosted cryptographic system of record. Its operating loop—discovery, canonical inventory, evaluation, action, and proof—helps teams connect device observations with modules, keys, firmware dependencies, owners, lifecycle decisions, remediation, and test evidence.
Vista Platform Core is free of charge and includes discovery, inventory, compliance and PQC assessment, and CBOM generation without asset, sensor, seat, or time caps. Vista tracks and governs post-quantum migration; it does not generate PQC keys or perform every migration. Selected-asset Active Scan is targeted, not indiscriminate network scanning. Vista is not a vulnerability scanner, and incomplete observation is not proof of absence.
Explore Vista’s cryptographic inventory, post-quantum migration, and CBOM and compliance resources.
Where uncertainty remains
The IETF draft may change during evaluation, and device performance varies widely by implementation and platform. Its optimization discussions are not a substitute for vendor documentation or measurement on deployed hardware. The lasting governance point is that resource, key-lifecycle, firmware, and recovery constraints must be visible before a device can be called migration ready.
Source
- Adapting Constrained Devices for Post-Quantum Cryptography, IETF PQUIP Working Group Internet-Draft, revision 08, October 15, 2026.