Hardware vs. software post-quantum cryptography: how to choose the right implementation

Choosing a post-quantum cryptography (PQC) algorithm is only part of the migration challenge. When an organization has decided to support standards such as ML-KEM for key establishment or ML-DSA for digital signatures, the question must be asked: where should those cryptographic operations run?

For some products, implementing PQC as software on an existing processor provides the flexibility and performance required. For others, dedicated hardware acceleration can reduce the load on the host processor, provide more predictable performance, or strengthen protection against physical attacks. Many systems will combine the two.

There is no universal answer because PQC implementation is a system-level decision.

The right architecture depends on factors including throughput, latency, power consumption, available memory, silicon area, attack exposure, upgradeability, and certification requirements. These considerations can vary significantly between a cloud server, an automotive ECU, a semiconductor root of trust, and a memory-constrained IoT device.

The decision, therefore, goes beyond a choice between hardware or software. The real question is: what does this product need its cryptographic implementation to do?

Software vs. hardware PQC: what are we choosing?

In a software implementation, PQC algorithms run on an existing CPU or microcontroller through a cryptographic library or SDK. This can make deployment and updates relatively straightforward because the implementation is not fixed into silicon.

Software can offer:

• Faster integration into existing platforms
• Easier updates and algorithm changes
• Portability across processor architectures
• No additional silicon area
• A strong foundation for crypto-agility

The trade-offs depend on the platform. Cryptographic operations consume CPU cycles, memory, and energy. Sensitive operations share the wider software execution environment unless additional protections are used.

Hardware PQC moves some or all cryptographic processing into dedicated hardware IP. This might be a targeted accelerator, a cryptographic coprocessor, or a more comprehensive security subsystem or root of trust.

Hardware can provide dedicated processing resources, isolate sensitive operations, and support countermeasures against physical attacks. This consumes silicon area and can be harder to modify once a chip has been manufactured.

However, there is a middle-ground – software-controlled cryptography supported by hardware acceleration.

For many products, that combination provides the most practical balance.

Eight questions for choosing a PQC implementation

Rather than starting with a preference for hardware or software, architects can make the decision by examining eight characteristics of the system.

1. How much throughput does the system need?

The first question is how much cryptographic work the system performs.

A microcontroller verifying a firmware signature occasionally has very different requirements from infrastructure processing thousands of cryptographic operations continuously.

Real performance data demonstrates why the workload matters. In a published PQShield software benchmark, ML-KEM-768 required approximately 117,000 processor cycles for key generation, 90,000 for encapsulation, and 88,500 for decapsulation on the tested platform. ML-KEM-1024 increases those figures to approximately 168,000, 125,000, and 124,000 cycles respectively.

Numbers like these should not be treated as universal performance figures because results depend heavily on the processor, implementation, compiler, security protections, and measurement methodology. They do demonstrate why architects need to benchmark the specific algorithms and parameter sets on their target system.

If cryptographic operations are occasional and the existing CPU has sufficient capacity, software may be entirely adequate.

As the volume of operations rises, dedicated acceleration becomes more attractive because cryptographic workloads can be offloaded from the host processor.

2. How predictable should latency be?

Throughput and latency are related, but they are not the same problem.

A system can deliver good average throughput while still experiencing individual operations that take longer than expected. That distinction can be important in real-time, safety-critical, and tightly scheduled systems.

ML-DSA illustrates the issue particularly well. Its signing process uses rejection sampling, which means execution time can vary – creating challenges both for strict real-time deadlines and for constant-time side-channel resistance. PQShield’s 2026 research into ML-DSA benchmarking warns that individual signing operations can take significantly longer than the statistical average and argues that minimum, average, and maximum measurements alone may be inadequate for time-critical systems.

Architects therefore need to ask more than “How fast is PQC?”

They should ask:

• What is the acceptable worst-case latency?
• Is cryptography on a time-critical execution path?
• Can another process run while the operation completes?
• Would a latency spike cause a timeout or safety issue?

Where predictable cryptographic performance is critical, dedicated hardware or carefully designed hardware/software implementations may become preferable.

3. What is the power budget?

Power is another system-specific trade-off.

Battery-powered IoT devices, automotive electronics, edge devices, and large-scale infrastructure are constrained by energy consumption, but for different reasons.

A software implementation uses existing compute resources and avoids additional hardware. If cryptographic operations are infrequent, this can be an efficient approach.

For sustained or computationally intensive workloads, dedicated hardware may perform a function more efficiently than a general-purpose processor. However, “hardware is lower power” should not be treated as a universal rule.

The right metric is the energy consumed by the complete cryptographic operation under the expected workload.

This is also where hardware/software co-design can help. PQShield’s PQPlatform-CoPro, for example, uses a hardware/firmware architecture designed to support PQC acceleration while maintaining upgradeability. PQShield identifies low power consumption and scalable configurations among the design characteristics of the coprocessor.

4. How much memory is available?

PQC also has to fit within the memory architecture of the target product.

For software, architects need to consider:

• RAM
• Flash or code space
• Stack and heap usage
• Cache behavior
• Temporary working memory

This is particularly important in embedded systems.

However, constrained memory does not automatically mean that cryptography has to move into hardware. Software can be specifically optimized for resource-constrained platforms.

PQShield’s embedded library, now part of its PQMicroLib family, is designed for microcontrollers and memory-constrained systems. Its implementation is configurable at build time, so developers can include only the algorithms required, and reduce binary size and memory footprint. Published PQShield materials show support for platforms including Arm Cortex-M devices and Arm application processors.

The important question is not whether PQC uses more resources than an existing algorithm in isolation. It is whether the required PQC implementation fits within the complete product’s resource budget.

5. How much silicon area can you afford?

For semiconductor designers, hardware acceleration introduces additional die area usage, another finite resource.

Every accelerator, memory block, bus interface, and security component competes with other functionality on the chip.

This means the idea of ‘putting PQC in hardware’ is not a single architectural choice. There is a spectrum:

Software only → Targeted accelerator → Cryptographic coprocessor → Security subsystem → Root of trust

A targeted accelerator can move computationally intensive primitives into hardware while leaving protocol logic and policy in software. A coprocessor can offload a larger portion of the cryptographic workload. A root of trust can provide a protected security boundary for keys, cryptographic operations, boot, firmware verification, and device identity.

PQShield’s hardware portfolio reflects this range. PQPlatform-CoPro combines lattice and hash capabilities. PQPlatform-TrustSys extends the architecture to an autonomous security subsystem or fully updateable root of trust.

The right amount of hardware is therefore the amount justified by the product’s performance, security, and integration requirements.

6. What can an attacker reach?

Performance is only half of the decision. The threat model matters just as much.

A cryptographic algorithm can be mathematically secure while its implementation leaks sensitive information.

Attackers with physical access may be able to observe power consumption or electromagnetic emissions, manipulate timing, or deliberately introduce faults. These implementation-level attacks are particularly relevant to exposed devices, semiconductor platforms, automotive systems, payment infrastructure, and other high-assurance environments.

The important questions include:

• Can an attacker physically access the product?
• Are secret keys handled on a general-purpose CPU?
• Does the system need resistance to power or electromagnetic analysis?
• Could an attacker inject faults?
• Which operations need to remain inside a protected boundary?

These requirements can shift the balance toward hardware-backed security.

For example, PQPlatform-TrustSys provides configurable power side-channel and fault-tolerance countermeasures, with key material protected inside the root-of-trust environment. PQShield describes the subsystem as a secure “island” that provides cryptographic services to the wider system while keeping sensitive material inside its hardware security boundary.

Hardware itself is not automatically secure against side-channel attacks. The countermeasures must be designed as an integral part of the implementation.rejection

7. How upgradeable does the system need to be?

Software has an obvious advantage at the point when cryptography needs to be updated.

Algorithms can evolve. Parameter choices can change. Implementations can require security patches, and protocols can be upgraded.

This makes crypto-agility an important part of the hardware-vs-software decision.

NIST defines crypto-agility as the capabilities required to replace and adapt cryptographic algorithms across protocols, applications, software, hardware, firmware, and infrastructure while preserving security and ongoing operations. Its latest guidance emphasizes that the correct approach depends on the specific implementation environment.

Software makes change easier, but this does not mean hardware has to be inflexible.

A hardware/software co-design can keep algorithm selection, policy, and updateable functionality in software or firmware while using hardware for acceleration and protected operations. PQPlatform-CoPro, for example, is specifically designed around hardware/firmware co-design for crypto-agility and upgradeability.

This can be especially valuable for silicon that is expected to remain in products for many years.

8. What needs to be certified?

Certification can significantly affect architectural decisions.

FIPS 140-3, for example, defines security requirements for cryptographic modules and underpins the Cryptographic Module Validation Program, jointly operated by the US and Canadian governments. The requirements apply to a defined cryptographic module, making the location and boundaries of cryptographic functionality important considerations during product design.

Architects should therefore consider certification early:

• Which cryptographic functionality falls inside the module boundary?
• Which algorithms and implementations need validation?
• What happens to certification if software changes?
• Are hardware security requirements involved?
• Does the target market have additional assurance requirements?

Software and hardware can both support certification paths. PQShield’s PQCryptoLib-SDK, for example, is designed to support CAVP/CMVP compliance paths, while PQPlatform-TrustSys supports CAVP/CMVP and SESIP compliance paths.

Certification should therefore be an input to the architecture, rather than something considered after implementation.

A practical hardware vs. software decision matrix

The eight criteria can be summarized as follows:

The table is deliberately not a scorecard. An enterprise server and an automotive security controller can reach completely different conclusions while both making sound engineering decisions.

Mapping the choices to real systems

Consider three common architectures.

1. An enterprise or cloud application may already have capable general-purpose processors, minimal physical attack exposure, and a strong requirement for rapid updates. A software-first approach is a natural fit. PQCryptoLib-Core provides software implementations, while PQCryptoLib-SDK combines PQShield’s library with an OpenSSL 3.x provider for applications including TLS and certificate management.
2. A constrained embedded device may have limited RAM and flash, a low or intermittent cryptographic workload, and a long deployment lifetime. Optimized embedded software can be the right starting point, particularly when updateability matters. PQMicroLib-Core is designed for this type of resource-constrained environment. Hardware acceleration can then be introduced where the device’s performance or security requirements justify it.
3. A high-assurance semiconductor or SoC platform may face stricter latency, throughput, isolation, and physical security requirements. Here, a dedicated accelerator, coprocessor, or root of trust can be appropriate. PQPlatform-CoPro provides compact hardware PQC acceleration, while PQPlatform-TrustSys can operate as an autonomous subsystem or root of trust with side-channel and fault-injection protections.

Why the answer is often hardware and software

For many products, the strongest architecture will not be either purely hardware or software.

Software can manage protocols, policy, updates, and algorithm selection. Hardware can accelerate computationally intensive operations, protect sensitive material, and provide isolation where the threat model demands it.

That combination can preserve crypto-agility without sacrificing performance or implementation security.

It is also important to distinguish this from hybrid cryptography. A hybrid hardware/software architecture describes where cryptography runs. Hybrid cryptography describes the use of classical and post-quantum mechanisms together during migration. A product can use both approaches simultaneously.

Choose the architecture around the product

The question is not whether hardware is better than software for post-quantum cryptography.

It is better to ask – what throughput and latency does the product need? How much power, memory, and silicon area are available? What attacks must it withstand? How easily must its cryptography change? And what needs to be certified?

For some systems, those answers point clearly toward software. For others, dedicated hardware is justified. In many products, the best result will come from combining flexible software with carefully selected hardware acceleration.

PQC migration is not just about deploying new algorithms. It is an opportunity to build cryptographic architectures that can meet today’s requirements while remaining ready for whatever comes next.

Choosing between software, hardware, and a hybrid PQC architecture? Talk to PQShield about finding the right balance of performance, security, footprint, and crypto-agility for your product.