Why Post-Quantum Cryptography Must Start at the Hardware Level

The clock is ticking. Quantum computers capable of breaking RSA and ECC are no longer a distant theoretical threat — they’re an engineering challenge with a visible timeline. NIST finalized its post-quantum cryptography standards in 2024, but the real question isn’t whether to migrate. It’s how — and more critically, at what level of the system stack.

The answer: it must start at silicon.

The “Harvest Now, Decrypt Later” Reality

Nation-state adversaries are already collecting encrypted communications today, storing them until quantum computers mature enough to break the encryption. For any data that needs to remain confidential for more than 10 years — government communications, defense systems, critical infrastructure, medical records — the migration to PQC is already overdue.

NIST’s standardization of ML-KEM (formerly Kyber) for key encapsulation and ML-DSA (formerly Dilithium) for digital signatures removed the “which algorithm” uncertainty. The remaining challenge is implementation — and this is where hardware becomes critical.

The Limits of Software-Only PQC

Many organizations are attempting PQC migration through software libraries. While this approach works for cloud servers with abundant resources, it falls apart in the embedded world:

Performance Gap: ML-KEM key generation on a Cortex-M4 takes approximately 500,000 cycles — roughly 10x slower than ECC-256. For real-time systems like automotive ECUs or industrial controllers, this overhead is unacceptable.

Memory Footprint: ML-DSA signatures are 2,420 bytes (vs 64 bytes for ECDSA). ML-KEM public keys are 1,184 bytes. On memory-constrained MCUs with 64-256KB SRAM, this creates significant pressure on the entire firmware architecture.

Side-Channel Vulnerability: Software implementations of lattice-based cryptography are inherently vulnerable to power analysis and electromagnetic emanation attacks. The Number Theoretic Transform (NTT) — the core operation in both ML-KEM and ML-DSA — produces data-dependent power consumption patterns that leak secret key information.

This last point deserves emphasis: you cannot fully protect software PQC against physical attacks using software-only countermeasures. The physics of the problem demands a hardware solution.

Why Hardware PQC is Non-Negotiable

Dedicated PQC hardware accelerators solve all three problems simultaneously:

Performance: A hardened NTT accelerator can execute ML-KEM operations in under 10,000 cycles — a 50x improvement over software, bringing PQC performance in line with legacy ECC.

Constant Resources: Hardware implementations use fixed silicon area and operate with deterministic memory access patterns, eliminating the variable footprint problem.

Physical Security: Hardware enables true side-channel countermeasures — Boolean and arithmetic masking at the gate level, hiding through random delay insertion, and shuffling of independent operations. These protections are architecturally impossible to achieve in software alone.

The Secure Boot Chain Imperative

PQC at the hardware level isn’t just about accelerating algorithms. It’s about rebuilding the entire trust chain:

Boot ROM must verify the first-stage bootloader using PQC signatures. This verification happens before any software runs — it must be implemented in immutable hardware.

Hardware Root of Trust must generate and protect PQC key material in tamper-resistant storage, never exposable to software.

Measured Boot with PQC-signed attestation ensures the entire firmware stack is quantum-resistant from the first instruction.

If any link in this chain relies on software-only PQC, the entire system’s quantum resistance is only as strong as its weakest — and most attackable — point.

The Migration Path

For organizations beginning their PQC hardware migration:

Phase 1 — Hybrid Mode: Deploy hardware that supports both classical (ECC) and PQC algorithms simultaneously. This provides backward compatibility while establishing quantum resistance.

Phase 2 — PQC-Primary: As ecosystem support matures and certification bodies (CAVP, Common Criteria, KCMVP) update their requirements, transition to PQC as the primary algorithm suite with classical as fallback.

Phase 3 — PQC-Native: Full transition to PQC-only operation, removing legacy cryptographic cores to reduce attack surface and silicon area.

The hardware IP must be designed for Phase 3 from day one, with Phases 1 and 2 as configuration options — not the other way around.

Conclusion: Trust Begins in Silicon

The post-quantum transition is not a software update. It’s a silicon architecture decision. Organizations that treat PQC as a firmware patch will find themselves vulnerable to both quantum and classical physical attacks.

The foundation of quantum-resistant security must be built at the hardware level — in the Root of Trust, in the boot chain, in the cryptographic accelerators. Everything above depends on the integrity of what’s below.

Trust begins in silicon. The time to build that foundation is now.