Post-quantum security architecture: a reference model for products, devices and infrastructure

Post-quantum cryptography (PQC) is sometimes framed as an algorithm replacement exercise: identify where RSA or elliptic-curve cryptography is used, substitute a quantum-resistant algorithm, and move on.

In practice, the transition is much broader.

Cryptography is embedded throughout modern products and infrastructure. It establishes the trustworthiness of a device when it starts, verifies the software it runs, authenticates firmware updates, proves the identity of devices and services, secures communications, and enables trusted connections into cloud platforms.

It’s clear that post-quantum security must be thought of as an architectural problem.

NIST describes cryptographic agility in similarly broad terms – a system’s ability to replace and adapt algorithms across protocols, applications, software, hardware, firmware and infrastructure while preserving security and ongoing operations. One of the clearest reasons that this capability is so important is the transition to post-quantum cryptography.

A useful reference model looks beyond any individual algorithm or protocol:

Root of trust → Secure boot → Firmware and software updates → Device identity → Communications → Cloud and services

PQC can have a role at every level.

Where does post-quantum cryptography belong?

It’s important to understand what cryptography is doing at each layer.

At the root of trust, cryptographic functions establish a security foundation for the rest of the system. During secure boot, signatures help determine whether software can be trusted before it is executed. Firmware-update mechanisms authenticate new code. Device and workload identities establish which machines or services should be trusted. Communications protocols protect data moving between systems, while cloud connections extend those trust relationships beyond the device itself.

These functions do not all require the same cryptographic primitive.

NIST finalized its first three post-quantum cryptography standards in August 2024. FIPS 203 specifies ML-KEM, a key-encapsulation mechanism designed to establish shared secret keys. FIPS 204 specifies ML-DSA for digital signatures, while FIPS 205 specifies the hash-based digital-signature scheme SLH-DSA. NIST describes these standards as ready for implementation, and is encouraging organizations to begin migrating systems to quantum-resistant cryptography.

The architectural question is therefore not simply, “Where do we encrypt data?”

The better question is: Where does this system use public-key cryptography to establish or maintain trust?

That includes confidentiality, but also authenticity and integrity.

The distinction matters. The well-known “Harvest-Now, Decrypt-Later” (HNDL) risk concerns adversaries collecting encrypted information today in the expectation that a future cryptographically relevant quantum computer will be able to decrypt it. CISA, NSA and NIST have explicitly warned organizations to consider sensitive data with long lifetimes when preparing for PQC migration. But the same guidance also calls attention to systems that create and validate digital signatures, including software and firmware update mechanisms.

A complete post-quantum architecture must address both.

Start with the root of trust

For a product or device, the root of trust is the logical place to begin.

A hardware or platform root of trust provides foundational security services on which higher layers depend. Depending on the design, those services can include protected key storage, cryptographic operations, secure boot, device provisioning, authentication, attestation and management of security-critical state.

If the network connection is upgraded to PQC but the device still depends on quantum-vulnerable cryptography at its foundation, only one part of the trust chain has changed.

That is particularly important for products with long operational lifetimes, where the security architecture selected during design may remain deployed for a decade or more.

Another consideration is that choosing a standardized PQC algorithm does not automatically create a secure implementation. Cryptographic implementations can be exposed to threats such as side-channel analysis and fault injection, particularly where attackers may have physical access to a device.

Hardware roots of trust and cryptographic accelerators can therefore play an important role where isolation, performance, or resistance to physical attacks are required.

PQShield’s PQPlatform-TrustSys, for example, is designed as a programmable, PQC-focused root-of-trust subsystem. It supports NIST-standardized ML-KEM and ML-DSA alongside classical ECC and RSA, as well as symmetric cryptographic acceleration. The architecture also supports fault-tolerance and side-channel countermeasures, allowing classical and post-quantum cryptography to coexist during migration.

Post-quantum trust needs a secure foundation.

Secure boot: protecting the first instruction

Once a trust anchor exists, that trust has to extend into the software the device executes.

Secure boot does this by verifying software before allowing it to run.

A simplified chain might look like this:

Immutable trust anchor → Bootloader → Firmware or operating system → Applications

Each stage can authenticate the next, creating a chain of trust from the hardware or immutable boot code upwards.

Digital signatures are central to many secure-boot architectures. NIST’s FIPS 204 describes digital signatures as a mechanism both for detecting unauthorized modification of data and authenticating the identity of the signatory. ML-DSA provides a post-quantum mechanism for performing those functions.

This makes secure boot an important PQC migration point.

The issue is already appearing in government migration requirements. NSA’s CNSA 2.0 program sets out quantum-resistant algorithm requirements for US National Security Systems, while more recent NSA capability packages are beginning to introduce CNSA 2.0 objectives and software-signing requirements into deployed architectures.

For manufacturers, the design challenge is not just implementing a PQC signature verifier. Boot-time performance, memory, hardware resources, implementation security and support for existing signing mechanisms all matter.

Hybrid secure boot can provide one migration route. A system can support both existing classical signatures and PQC, allowing cryptographic policy to change over time instead of requiring an immediate clean break. PQShield’s secure-boot implementations take this approach across its PQPlatform family, with support for post-quantum and classical cryptography at the hardware security layer.

Firmware updates extend the trust chain for years

Secure boot protects code before it runs. Secure firmware updates protect what the device will execute in the future.

That makes the update architecture one of the most important components of long-term quantum readiness.

An update system commonly needs to verify that a firmware image originates from an authorized source and has not been altered. Digital signatures can provide authenticity and integrity before the update is installed.

The challenge is longevity.

An industrial controller, automotive component, telecommunications platform, or IoT device designed today may still be operating many years from now. If its update mechanism can only authenticate firmware using a quantum-vulnerable scheme, migrating the rest of the product later could be significantly harder.

CISA’s migration guidance specifically recommends that organizations inventory quantum-vulnerable cryptography in applications and libraries, including the mechanisms used for firmware and software updates. It also warns that embedded cryptography can be difficult for discovery tools to identify, making supplier visibility important.

This leads to an important design principle: the mechanism used to change a product securely must itself be designed for cryptographic change.

That can mean supporting multiple algorithms, upgradeable trust anchors, and algorithm identifiers, as well as enough resource headroom to accommodate post-quantum keys and signatures.

Device identity: who are you trusting?

Once a device is running trusted software, it still needs to establish its identity to other systems.

Modern infrastructure increasingly depends on cryptographic machine identity. Devices authenticate to gateways. Services authenticate to other services. Hardware components attest their identity and state. Cloud workloads use certificates and credentials to establish trusted sessions.

PQC therefore has implications for provisioning, certificate infrastructures, device credentials, attestation, and authentication.

It also raises an architectural question: where should those cryptographic operations happen?

On some systems, a software library may be the right answer. On others, private keys and identity operations may need to remain inside a hardware-backed security boundary.

Emerging platform protocols demonstrate how the layers are beginning to converge. Version 1.4 of the DMTF Security Protocol and Data Model, or SPDM, adds post-quantum support including ML-KEM, ML-DSA and SLH-DSA for environments in which components need to authenticate and establish secure communications. PQShield supports these primitives through both hardware-rooted and embedded software implementations.

During migration, many organizations will also need to support classical and post-quantum credentials simultaneously. That makes crypto-agility particularly important at the identity layer.

Communications and cloud connectivity

Network communication is the most familiar part of the PQC problem.

Public-key cryptography is routinely used when two systems establish secure connections. In the post-quantum model, a KEM such as ML-KEM can be used to establish a shared secret over a public channel, after which symmetric cryptography can protect the session.

That applies across many relationships:

1. Device ↔ Device
2. Device ↔ Gateway
3. Device ↔ Cloud
4. Service ↔ Service
5. Enterprise application ↔ Cloud platform

But upgrading one endpoint is not enough.

A cloud connection can involve protocol libraries, certificates, proxies, gateways, load balancers, security appliances, and backend services. Each can introduce cryptographic dependencies.

This is one reason CISA recommends creating a cryptographic inventory covering network protocols, endpoints, servers, applications, libraries, and even CI/CD pipelines before attempting migration.

For OpenSSL-based applications, software integration offers one route. PQShield’s PQCryptoLib-SDK combines its PQC library with an OpenSSL provider and supports uses including TLS connections, certificate management and X.509 certificate generation. It can therefore allow PQC to be introduced at the software and protocol layer without moving the entire cryptographic architecture into dedicated hardware.

Three reference architectures for deploying PQC

There is no single correct implementation architecture. Products have different requirements for performance, memory, power, physical security, upgradeability, and lifecycle.

Three broad models cover many deployments.

1. Software-first architecture

Application → PQ or hybrid protocol → PQC software library → Operating system/platform → Hardware

A software-first architecture is well-suited to enterprise platforms, cloud applications, servers, and embedded systems with sufficient resources.

Its main advantage is flexibility. Cryptographic implementations can be upgraded independently of silicon, and abstraction layers can make future algorithm changes easier.

For constrained systems, however, memory and compute requirements need careful attention.

PQShield’s embedded software supports ML-KEM, ML-DSA and hash-based signatures on embedded platforms, with configurable builds intended to minimize memory and binary size. Its published product material identifies support across architectures including Arm, RISC-V and x86, as well as bare-metal environments.

2. Hardware-first architecture

Application/firmware → Security interface → Hardware root of trust or PQC accelerator → Protected keys

Hardware becomes attractive where cryptography has strict performance, isolation, power, or physical-security requirements.

A cryptographic coprocessor can add PQC acceleration to an existing security subsystem, while a more complete root of trust can own sensitive keys and enforce security policy independently of the host processor.

PQShield’s PQPlatform-CoPro is designed to add hardware PQC acceleration to an existing subsystem, and supports use cases including secure boot, firmware updates, bulk encryption and hash acceleration. PQPlatform-TrustSys extends the model into a complete PQC-focused root of trust.

3. Hybrid hardware and software architecture

For many products, the practical answer lies between the two:

Protocols and policy in software → Cryptographic abstraction → Hardware acceleration and protected key operations

Software provides flexibility and easier updateability. Hardware provides acceleration, isolation, and implementation-level protections for sensitive operations.

This architecture can be particularly useful where manufacturers need crypto-agility without sacrificing the security properties of a hardware root of trust.

It is also important to distinguish hybrid architecture from hybrid cryptography.

Hybrid architecture combines hardware and software. Hybrid cryptography combines classical and post-quantum mechanisms. A product can use either, or both.

Crypto-agility connects the whole model

Whichever implementation model is chosen, crypto-agility is the architectural capability that connects the layers.

NIST’s latest guidance defines crypto-agility as the ability to replace and adapt algorithms in protocols, applications, software, hardware, firmware, and infrastructure while preserving security and operations.

In practice, that means avoiding assumptions that one algorithm will remain fixed for the lifetime of the product.

Architects should consider whether cryptographic policy can change independently from application logic, whether certificates and trust anchors can be replaced, whether interfaces can support multiple algorithms and parameter sets, and whether systems have enough bandwidth, memory and processing capacity for different cryptographic implementations.

Cryptographic inventory matters too. You cannot make an architecture agile if you do not know where cryptography exists.

PQC migration is therefore not simply the deployment of a new primitive. It is an opportunity to design products so that the next migration is easier than the last one.

Building quantum safety through the whole chain of trust

The most useful way to approach post-quantum security architecture is to follow trust through the system:

Root of trust → Secure boot → Firmware updates → Device identity → Communications → Cloud and services

At every stage, ask what establishes trust, which cryptography supports it, how long that mechanism must remain secure and how it can be changed.

The answer will not be identical for every product.

A cloud service may implement much of its PQC transition in software. A constrained embedded product may require highly optimized libraries. A semiconductor platform or critical device may benefit from hardware acceleration or a post-quantum root of trust. Many real-world products will combine all three approaches.

What matters is treating the transition as an end-to-end architecture rather than a collection of isolated algorithm upgrades.

The question is no longer simply, “Where do we replace RSA or ECC?”

It is: “Where does our system depend on cryptography for trust, and how do we make every part of that trust chain ready to evolve?”

That is the foundation of a genuinely quantum-safe architecture.

Ready to build post-quantum security into your products and infrastructure? Talk to PQShield about creating a practical path to quantum-safe security.