Node vs Endpoint: Why the Difference Matters for PQC Migration
Updated: Aug 31
Stop treating PQC migration as an endpoint problem. It isn’t - and that mistake is already breaking real architectures.
Post-quantum cryptography migration is often discussed in terms of endpoints: laptops, smartphones, servers and IoT devices. That is an important starting point, but it is not the complete picture.
Many cryptographic sessions are terminated by infrastructure components positioned between communicating systems. VPN gateways, reverse proxies, API gateways, load balancers and service-mesh proxies may all 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, identify migration dependencies and test the parts of the architecture 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 because endpoints and intermediary infrastructure can 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 also 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 will depend 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