Stop Treating PQC Migration as an Endpoint Problem
Updated: Oct 6
It isn’t - and that mistake is already breaking real architectures.
Post-quantum cryptography (PQC) migration often focuses on endpoints: laptops, smartphones, servers, and IoT devices. This is a crucial starting point, but it does not provide the complete picture. Many cryptographic sessions terminate at infrastructure components positioned between communicating systems. VPN gateways, reverse proxies, API gateways, load balancers, and service-mesh proxies influence whether an organisation can deploy and operate post-quantum cryptography successfully.
Understanding the difference between a network node and an endpoint helps organisations build a more complete cryptographic inventory. This distinction allows for the identification of migration dependencies and testing of the architecture's parts most likely to experience operational impact.
What is a Network Node?
A node is any participating or addressable component in a network. Depending on the architecture, nodes can include:
Routers
Switches
Servers
Load balancers
VPN gateways
API gateways
Proxies
Service-mesh components
Endpoints
A node may generate, receive, process, route, or forward data. However, not every node is the source or final destination of a communication.
What is an Endpoint?
An endpoint is a node that acts as the source or destination of communication. Examples include:
Laptops
Smartphones
Workstations
IoT sensors
Application services
Containers
Databases
Embedded devices
The simplest rule is:
All endpoints are nodes, but not all nodes are endpoints.
This distinction is useful. Endpoints and intermediary infrastructure create different requirements during a post-quantum cryptography migration.
Why the Distinction Matters for PQC
PQC migration is not simply a software update applied to every device. It involves algorithms, protocols, certificates, key management, hardware, network paths, and operational dependencies. The impact varies according to an asset’s function.
Constrained Endpoint Considerations
Embedded devices, IoT sensors, mobile equipment, and other constrained endpoints may face limitations involving:
CPU capacity
RAM
Firmware footprint
Bandwidth
Network latency
Battery or energy consumption
Legacy protocol compatibility
Limited update capability
PQC algorithms generally use larger cryptographic objects than many familiar elliptic-curve algorithms. For example, NIST’s ML-KEM-768 uses a 1,184-byte encapsulation key and a 1,088-byte ciphertext. ML-DSA-65 uses a 1,952-byte public key and a 3,309-byte digital signature. [pages.nist][nvlpubs.nist]
These larger objects can affect memory use, bandwidth, message processing, and interoperability. The practical impact depends on the protocol, implementation, hardware, and frequency of cryptographic operations. It should be measured rather than assumed.
Infrastructure Node Considerations
High-volume infrastructure nodes may process large numbers of connections or cryptographic operations. Examples include VPN concentrators, TLS gateways, reverse proxies, and service-mesh proxies.
Potential concerns include:
Cryptographic operations per second
Connection concurrency
Latency under load
Memory and network I/O
Certificate processing
Hardware acceleration
Larger handshake messages
Fragmentation and interoperability
Capacity during peak traffic
The limiting factor is not automatically memory at the endpoint or throughput at the node. A particular gateway may be limited by CPU, memory, network bandwidth, connection tracking, or another architectural constraint. Performance testing should use realistic traffic volumes, protocol configurations, and hybrid or PQC-enabled implementations.
Identify Cryptographic Termination Points
The most important question is not simply whether an asset is a node or an endpoint. The more useful question is:
What cryptographic role does this asset perform?
An endpoint may participate in application-level or end-to-end encryption. However, upgrading one endpoint does not automatically create end-to-end PQC protection. The relevant communication path may include several systems that terminate or establish secure sessions.
These systems can include:
VPN concentrators
Reverse proxies
Load balancers
API gateways
Service-mesh proxies
TLS inspection systems
Internal application services
Cloud security gateways
For each asset in the cryptographic inventory, ask:
Does it terminate TLS, VPN, or another secure protocol?
Does it authenticate users, devices, or services?
Does it generate, store, or use cryptographic keys?
Does it inspect, decrypt, or re-encrypt traffic?
Does it process certificates or digital signatures?
Could larger PQC messages affect performance or interoperability?
Ordinary routers and switches may simply forward encrypted traffic. They may not require a PQC upgrade unless they terminate tunnels or perform cryptographic functions themselves.
Endpoint and Infrastructure Migration Have Different Scopes
Endpoint migration may involve:
Operating systems
Applications
Embedded firmware
Device-management platforms
Legacy hardware
Unsupported devices
Intermittently connected equipment
Backward compatibility
Infrastructure migration may involve:
TLS and VPN termination
Public-key infrastructure
Certificate lifecycles
Key management systems
Hardware security modules
Proxies and gateways
Service meshes
Cloud and SaaS dependencies
Monitoring and incident response
These dependencies may extend beyond systems owned directly by the organisation. A cloud provider, software supplier, managed service, or business partner may control a cryptographic component that affects the migration timeline.
Build a Cryptographic Inventory, Not Just an Asset List
An asset inventory identifies what an organisation owns or operates. A cryptographic inventory goes further by recording where and how cryptography is used across systems, applications, devices, services, and data flows. NIST describes this as a foundation for managing cryptographic risk and preparing for PQC migration. [pages.nist]
A useful inventory should link:
Assets
Applications
Data flows
Protocols
Algorithms
Certificates
Keys
Cryptographic libraries
HSMs and KMS platforms
Session-termination points
Suppliers and dependencies
Data-retention requirements
This makes it easier to identify systems that are both technically important and difficult to replace or update.
The Practical Takeaway
A PQC migration plan should not ask only:
Are our endpoints ready for post-quantum cryptography?
It should also ask:
Where are cryptographic sessions terminated, which systems process the keys and signatures, and where could larger PQC messages affect the architecture?
Endpoints and network nodes are not interchangeable categories. More importantly, neither category alone tells you enough about migration priority. The priority should be based on cryptographic function, data sensitivity, exposure, dependency, replaceability, and performance risk.
A credible PQC programme therefore needs to inventory both endpoints and nodes, then identify the cryptographic role of each asset. That is where the real migration picture begins.
Comments