The real cost of implementing PQC: memory, performance, power and engineering time

The conversation around quantum computing and security often starts with a simple question: when will organizations need to replace the public-key cryptography they use today?

For engineering teams, there is a second question that is just as important: what will that replacement actually cost?

Post-quantum cryptography (PQC) is now moving into real-world implementation. NIST published its first three finalised PQC standards in 2024, including ML-KEM for key establishment, and ML-DSA and SLH-DSA for digital signatures. In the UK, the National Cyber Security Centre (NCSC) has set a target of 2035 for organizations to complete their migration to PQC.

But the cost of migration cannot be measured solely in procurement budgets. PQC introduces new engineering considerations around memory, processing performance, bandwidth, and, for some devices, energy consumption. There is also the time required to discover existing cryptography, select appropriate technology, integrate it, test it, and maintain it.

These costs vary enormously. What is easily accommodated by a cloud server could be a significant constraint for a microcontroller. An implementation designed for maximum throughput will face different trade-offs from one designed for minimum power or memory.

Understanding those differences is essential to planning a practical PQC migration.

Why does post-quantum cryptography come with different requirements?

The public-key cryptography widely deployed today relies heavily on mathematical problems that are hard to solve, including integer factorization or discrete logarithms. A sufficiently capable fault-tolerant quantum computer could undermine those systems, which is why new quantum-resistant algorithms are being introduced.

PQC uses different mathematical foundations. Those differences affect not only security but also how the algorithms behave when implemented.

Take ML-KEM, NIST’s standard for establishing a shared secret.

NIST’s recommended default parameter set, ML-KEM-768, has a 1,184-byte encapsulation key, a 2,400-byte decapsulation key, and a 1,088-byte ciphertext. Moving to ML-KEM-1024 increases those figures to 1,568, 3,168 and 1,568 bytes respectively. NIST explicitly notes that parameter selection involves performance trade-offs, and that keys or ciphertexts can become unacceptably large for some applications.

Digital signatures have their own characteristics. For ML-DSA-65, for example, NIST specifies a 1,952-byte public key, a 4,032-byte private key, and a 3,309-byte signature. ML-DSA-87 increases the signature size to 4,627 bytes.

Those figures are useful, but they do not tell you how much RAM an implementation will consume or how quickly it will execute. Those properties depend heavily on the implementation and target platform.

That distinction is at the heart of understanding the real cost of PQC.

Cost 1: Memory

Memory can be one of the most visible constraints when implementing PQC, particularly on embedded devices.

There are several dimensions to consider. Keys, signatures, and ciphertexts need to be stored or transmitted. The cryptographic implementation itself occupies code space. Algorithms also need working memory while operations are being performed.

On a general-purpose server, a few additional kilobytes may be relatively insignificant. On a microcontroller with tightly constrained RAM and flash, they can determine whether an implementation is practical.

This is why it is important not to look at key sizes in isolation. The fact that an ML-KEM-768 encapsulation key is 1,184 bytes does not mean an implementation needs 1,184 bytes of RAM. Runtime memory requirements depend on choices such as data representation, intermediate calculations, code architecture, and optimization.

The implementation can therefore make a major difference.

PQShield’s PQMicroLib-Core is designed specifically for bare-metal and real-time embedded systems. PQShield states that configurations can operate in as little as 5 KB of RAM, including a secure-boot use case designed to introduce PQC signature verification without replacing existing hardware.

This illustrates a wider point. The resource requirements in a cryptographic standard are not necessarily the final resource requirements of the product.

For embedded teams, the right questions are more specific: How much RAM is available at the point where the cryptographic operation runs? How much flash can be allocated? Which operations need to be supported? What other processes are competing for the same resources?

PQC needs to fit the device, rather than the device being designed around a generic PQC implementation wherever possible.

Cost 2: Performance

Performance is another area where broad claims about PQC can be misleading. There is no single measure of “PQC speed”.

For a key encapsulation mechanism such as ML-KEM, engineers might measure key generation, encapsulation, and decapsulation. For a signature scheme, signing and verification have different performance characteristics. The metric that matters could be latency for an individual operation, or the number of operations a system can process each second.

Context is everything. A device performing signature verification once during secure boot has very different performance requirements from a server terminating large volumes of secure connections. A smart meter might have limited processing capacity but relatively modest throughput requirements. A network appliance might need to continuously process cryptographic operations at high speed.

Even NIST’s ML-KEM standard reflects this trade-off. It recommends ML-KEM-768 as the default parameter set because NIST considers it to provide a large security margin at a reasonable performance cost, while acknowledging that applications may need a different parameter set where performance or security requirements differ.

Implementation choices can then change performance again.

Software can be optimized for a particular processor architecture, including taking advantage of specialized instruction sets. Hardware acceleration provides another option when throughput or CPU availability becomes critical.

PQShield’s PQPerform-Inferno, for example, implements hardware acceleration for ML-KEM and ML-DSA and is designed for use cases including TLS acceleration, high-performance server communications, VPNs, and secure boot. It can also be deployed in multiple instances where greater throughput is required.

This does not mean hardware acceleration is necessary everywhere. It demonstrates why performance requirements should be defined before an implementation is selected.

The useful benchmark is not “How fast is PQC?” It is “Can this implementation meet the performance requirements of this system?”

Cost 3: Power

Power adds another layer to the engineering equation.

Every cryptographic operation consumes energy through computation, memory access, and, where data is transmitted, communication. On mains-powered infrastructure, this may be secondary to throughput or latency. On a battery-powered sensor, mobile device, or remotely deployed IoT system, it can directly affect operational life.

Research involving PQShield’s Markku-Juhani O. Saarinen examined the energy requirements of PQC candidates on an Arm Cortex-M4 platform. It found that energy, bandwidth, and latency requirements across the algorithms studied could vary by several orders of magnitude – enough to affect battery life, user experience, and protocol design. The research also highlighted the need to consider both computational energy and the energy required to transmit larger cryptographic objects.

There is an important caveat here. The study was published in 2020, during NIST’s candidate-selection process, rather than measuring only the final standards available today. It should therefore be read as evidence of how significantly algorithm and implementation choices can affect energy requirements, rather than as a current benchmark for a particular finalized algorithm.

The broader engineering principle remains relevant.

More CPU cycles do not automatically translate into an unacceptable power budget, just as a larger key does not automatically make an implementation impractical. What matters is the complete system.

Engineers need to consider how often cryptographic operations take place, the efficiency of the implementation, the target processor, memory access, communications overhead, and the energy budget available.

This is particularly important for products expected to remain deployed for years without hardware replacement.

Cost 4: Engineering time

Memory, speed, and power can all be benchmarked. Engineering time is harder to quantify, but it may prove to be one of the largest costs of PQC migration.

Migration starts before an organization installs a new cryptographic library.

Teams first need to understand where vulnerable public-key cryptography is used. That can mean examining applications, devices, protocols, certificates, key-management systems, third-party products, and dependencies across the supply chain.

The NCSC expects large organisations and those operating their own IT infrastructure to spend two to three years carrying out discovery and assessment, defining a migration strategy and developing an initial migration plan. Its target is for this stage to be completed by 2028.

Implementation brings another set of tasks.

Technology has to be evaluated and procured. Software or hardware needs to be integrated. Protocol compatibility must be considered. Implementations need testing, and teams need rollback and business-continuity plans. Suppliers need to be involved. Some environments will require certification or additional security validation.

The NCSC also expects migration to be iterative, involving multiple deployment and testing cycles rather than one universal “big bang” change.

Then there is implementation security.

Highly optimized cryptographic code can become more difficult to verify because optimization increases the gap between high-level specifications and what actually runs on a processor. Recent PQShield research, for example, has examined formal verification of an architecture-specific ML-KEM implementation optimized using AVX2 instructions, demonstrating that performance optimization and rigorous verification need not be mutually exclusive.

Physical attacks introduce further considerations in some environments. Side-channel and fault-injection protections can require additional design, implementation and validation work, particularly for devices an attacker may physically access.

Engineering time therefore includes much more than the replacement of one API call with another. It spans discovery, architecture, integration, optimization, security, interoperability, testing, deployment, and long-term maintenance.

The costs interact, so optimization means making trade-offs

These four costs cannot always be optimized independently.

An implementation tuned to minimize memory may make different performance trade-offs from one designed to maximize throughput. Adding protection against physical attacks can require additional computation or memory. Hardware acceleration can reduce the workload placed on the main processor, but it introduces decisions around silicon area, integration and architecture.

Even increasing the security parameter can change several variables simultaneously.

Moving from ML-KEM-768 to ML-KEM-1024 increases the encapsulation key from 1,184 to 1,568 bytes, the decapsulation key from 2,400 to 3,168 bytes and the ciphertext from 1,088 to 1,568 bytes. NIST specifically advises implementers to account for adverse performance effects when choosing parameter sets.

The objective is therefore not to find the implementation with the smallest memory footprint or highest benchmark score in isolation. It is to understand the constraints of the system and make the appropriate trade-offs.

For an embedded sensor, memory and power could dominate. For a data center appliance, throughput might matter more. For secure boot, verification time and code size might be the critical measures. For a product expected to operate for 15 years, the ability to update cryptography later may outweigh a small performance advantage today.

This is why PQC needs to be approached as an engineering problem rather than simply an algorithm-selection exercise.

How to control the cost of PQC migration

The good news is that many of these costs can be managed when organizations start early.

Discover cryptography before replacing it. A clear inventory makes it possible to prioritize systems rather than attempting to migrate everything simultaneously. The NCSC recommends identifying priority services, dependencies on long-lived hardware, supply-chain relationships, and risks associated with legacy systems as part of migration planning.

Benchmark on representative hardware. Generic benchmarks provide useful comparisons, but they cannot tell you how an implementation will behave in your product. Test memory, latency, throughput, and, where relevant, energy consumption under realistic workloads.

Optimize for the actual use case. A constrained MCU, a cloud service and a network appliance should not automatically use the same implementation strategy. PQC software and hardware can be optimized around different resource and performance requirements.

Include implementation security. Speed and memory measurements are only meaningful if the resulting implementation provides the required security. For exposed devices, this might include protection and validation against side-channel or fault-injection attacks.

Design for cryptographic change. PQC migration will involve periods in which traditional and post-quantum cryptography coexist. The NCSC therefore recommends seeking crypto-agile solutions that can support alternative suites of algorithms.

Most importantly, organizations should account for engineering effort early. Waiting until a migration deadline approaches risks turning manageable architectural trade-offs into expensive emergency changes.

PQC is an engineering program, not an algorithm update

The relationship between quantum computing and security is often discussed in terms of a future cryptographic threat. But for engineering teams, the practical work of addressing that threat has already begun.

The NCSC describes PQC migration as a global-scale change to IT and operational technology and acknowledges that the total financial cost could be significant. Its roadmap calls for discovery and initial planning by 2028, high-priority migrations by 2031, and migration across systems, services and products by 2035.

Meeting those milestones efficiently means looking beyond whether a system can technically run a post-quantum algorithm.

How much memory does the implementation require? Can it meet the system’s performance target? What does it mean for the power budget? How much engineering is needed to integrate, secure, and maintain it?

There is no universal answer because there is no universal PQC environment.

The objective should be to choose implementations that match the constraints of each system, while building enough crypto-agility to adapt, as standards, requirements, and technology evolve.

PQShield develops post-quantum cryptography across embedded software, system-level software, and hardware IP, with implementations designed around different memory, performance, and security requirements.

Talk to PQShield about evaluating the practical cost of PQC in your architecture and building a migration path designed for real-world deployment.