# Edge Computing and PQC **Source**: https://quantumsequrity.com/blog/edge-computing-pqc **Category**: Industry & Use Cases --- [← Back to Blog](../../blog.html) Industry & Use Cases # Edge Computing and PQC 11 min read The cloud is far away. For most user-facing applications, that distance does not matter. A web page that loads in 200 milliseconds is fine. A video stream that buffers for two seconds is fine. But for a self-driving car deciding whether to brake, an industrial robot adjusting its grip on a part, or a remote surgery robot responding to a surgeon's hand movement, 200 milliseconds is a disaster. These applications need compute that is physically close to the user, often inside the same building or on the same cellular base station. That is what edge computing is for. Edge computing creates a new layer in the architecture: small, distributed compute nodes that sit between the user and the cloud. ETSI calls this Multi-access Edge Computing (MEC). 3GPP integrates MEC into the 5G architecture. Hyperscalers run their own edge zones. The common thread is that the edge is constrained: less power than the cloud, less compute than the cloud, less cooling, less physical security. And every one of those constraints affects how cryptography works at the edge, including post-quantum cryptography. ## What MEC Actually Is ETSI MEC is defined in ETSI GS MEC 003, the reference architecture document. The core idea is that mobile network operators can deploy compute resources at the radio access network (RAN) edge: at base stations, aggregation sites, or central offices that are within a few kilometers of the end user. Applications that need ultra-low latency (sub-10 milliseconds round-trip) can run at this edge layer instead of in a distant data center. The framework defines a MEC orchestrator (similar to NFV MANO), MEC platforms that host the actual edge applications, and APIs that let those applications interact with mobile network state (location, radio quality, traffic patterns). MEC integrates with 3GPP 5G via the Service Based Architecture (SBA), letting edge applications subscribe to network events. For developers, the practical effect is that an edge application looks a lot like a containerized microservice running in a small Kubernetes cluster, but the cluster lives at a base station instead of in a data center. The constraints are different. The cryptography is the same in principle but more constrained in practice. ## Why Edge Cryptography Is Different A typical cloud server has 64 cores, 256 GB of RAM, AES-NI hardware acceleration, and effectively unlimited power. A typical edge node might have 4 to 16 cores, 16 to 64 GB of RAM, sometimes AES-NI but not always, and a power budget that matters because the site is space-constrained. This affects PQC choices in three ways. First, the algorithm itself: ML-KEM-768 is fine on Cortex-A72 class hardware, but pure-software implementations on lower-end ARM cores are slower and use more energy. Second, the key sizes: ML-KEM-768 ciphertexts are 1088 bytes, which adds bandwidth cost on backhaul links from the edge. Third, the certificate size: ML-DSA-65 signatures are 3293 bytes, and a typical TLS handshake includes a chain of 3 certificates plus OCSP responses, which can push the handshake from a few kilobytes to over 10 kilobytes. For most edge applications, this overhead is fine. For dense deployments where a single edge node serves thousands of mobile users with rapidly establishing TLS sessions, the cumulative cost matters. ## The Backhaul Link from Edge to Core Every edge node has a backhaul link to the operator's core network. This link is usually fiber, sometimes microwave, sometimes a dedicated VPN over public internet. It carries: - User plane traffic that the edge cannot serve locally - Control plane traffic between the edge and the 5G core - Management traffic between the edge orchestrator and the core orchestrator - Telemetry, logging, and observability data All of this is encrypted with TLS or IPsec today. The PQC migration question is when to switch the backhaul cryptography to hybrid ML-KEM. The answer depends on how long-lived the sessions are. A persistent control-plane session that runs for the entire lifetime of the edge node is exactly the kind of long-lived data that gets recorded for [harvest now, decrypt later](harvest-now-decrypt-later.html) attacks. ## Edge Application Identity and mTLS Edge applications often use mutual TLS (mTLS) to authenticate to backend services. Each application has a certificate, the backend has a certificate, and both sides verify each other during the TLS handshake. This is the standard zero-trust pattern. For PQC, mTLS at the edge means upgrading the issuing CA, the application certificates, and the TLS library to support hybrid ML-KEM and ML-DSA-based certificates. Major service mesh implementations (Istio, Linkerd) and cert manager tools (cert-manager for Kubernetes) are adding PQC support throughout 2025 and 2026. The practical migration path is incremental. Run a hybrid CA that issues both classical-only certificates (for legacy clients) and hybrid certificates (for PQC-aware clients) in parallel. As applications upgrade their TLS libraries, they automatically negotiate the hybrid suite. Read more about the migration approach in our [hybrid encryption](hybrid-encryption.html) writeup. ## Physical Security at the Edge A cloud data center is in a physically secure facility with biometric access, 24-hour security, redundant power, and tamper-evident server enclosures. An edge node at a cellular base station might be in a roadside cabinet, on a tower, in a basement closet, or in a small wiring room at a stadium or factory. This matters for cryptography because physical access changes the threat model. An attacker who can physically touch the hardware can extract keys from RAM (with cold boot attacks), tamper with firmware, install hardware implants, or simply replace the entire box. Hardware security modules (HSMs) and Trusted Platform Modules (TPMs) help, but they are not always present at the edge. For PQC, the implication is that key material at the edge needs the same care as key material on a user's phone. Keys should be wrapped, sealed to TPM where possible, and rotated frequently. Long-lived keys at the edge are a liability, not an asset. ## Constrained Edge Devices Below the MEC layer, there is an even more constrained tier: industrial gateways, on-premises servers in factories, smart-city edge boxes, retail POS aggregators. These are sometimes called "far edge" or "deep edge" devices. They might run on ARM Cortex-A53 or even Cortex-M class hardware with hundreds of megabytes of RAM and no hardware crypto acceleration. For these devices, PQC migration is harder. ML-KEM-768 in pure software on a Cortex-M7 takes 10 to 30 milliseconds per key generation, which is workable but noticeable. ML-DSA-65 signing is similar. The certificates and ciphertexts are large enough that they affect the size of firmware images and the duration of secure boot sequences. Many of these devices end up using ML-KEM-512 (the smaller parameter set) for performance, accepting the lower security margin. Or they use Kyber/ML-KEM as a long-term key wrap and continue to do session-level cryptography with classical algorithms during the transition period. ## Edge AI and Model Confidentiality A growing class of edge applications runs AI inference: object detection in security cameras, anomaly detection on factory floors, voice recognition in smart speakers, predictive maintenance on industrial equipment. The AI models themselves are often trade secrets that the operator wants to protect from extraction. This creates a new cryptographic requirement: model encryption. The model is encrypted at rest on the edge device and decrypted only inside a secure enclave at runtime. The decryption key needs to be delivered to the device securely. For PQC, the relevant pieces are the key delivery mechanism (which uses ML-KEM in hybrid mode for forward secrecy) and the long-term key that wraps the model on disk (which uses authenticated encryption with a post-quantum-derived key). The patterns are similar to file encryption, which is what QNSQY is designed for. See [ML-KEM explained](ml-kem-explained.html) for the algorithmic details. ## Edge in Industrial Control Systems Industrial control systems (ICS) and operational technology (OT) networks have started adopting edge computing patterns. Programmable logic controllers (PLCs), SCADA systems, and human-machine interfaces (HMIs) increasingly support TLS and certificate-based authentication, often via the OPC UA protocol. OPC UA is defined by the OPC Foundation and uses certificates plus pre-shared user tokens for authentication. The OPC Foundation has published guidance on PQC migration that recommends hybrid ML-KEM for key agreement and ML-DSA for certificate signatures. Industrial environments often run equipment for 20 or 30 years. A PLC installed today might still be in service in 2050. The cryptography on that PLC needs to survive that long, which means hybrid PQC is the only sensible choice. Pure-classical TLS at the OT edge is increasingly considered a known-defective configuration. For a deeper view of how this connects to broader IoT, see [PQC IoT smart home devices](pqc-iot-smart-home-devices.html). ## Cloud-to-Edge Synchronization Most edge deployments are not isolated. They sync state with the cloud: configuration, software updates, telemetry, events. This sync traffic is large and continuous and is the most attractive target for both real-time and harvest-now attacks. Software updates are signed today with RSA or ECDSA. CNSA 2.0 mandates ML-DSA for signed software updates by 2033, and CCSDS, ISO 21434 (automotive cybersecurity), and IEC 62443 (industrial control system cybersecurity) are all expected to follow. Edge fleet management platforms (AWS IoT Greengrass, Azure IoT Edge, Google Distributed Cloud Edge, Mender) are starting to add PQC signing options. Read more about why this matters in [the NIST FIPS guide](nist-fips-guide.html). ## Edge in Retail and Hospitality Edge computing is increasingly common in retail and hospitality: digital signage, inventory tracking via RFID, in-store analytics, kiosk systems, and connected POS infrastructure. These edge deployments aggregate data from many in-store sensors and devices and forward processed data to centralized cloud systems. For PQC, retail edge has the same migration story as other edge categories. The novel concern is that retail environments often operate edge devices with limited update discipline. A device deployed in a back-of-store rack might be forgotten for years. PQC migration here requires automated update infrastructure that pushes new firmware as cryptographic standards evolve. PCI DSS scope considerations also apply when retail edge nodes touch payment data. PQC migration in PCI scope follows the broader payment industry timeline rather than the consumer cloud timeline. ## Multi-Operator Edge and Federation Some edge deployments are federated across multiple operators. A factory might use compute resources from its primary cloud provider plus a local mobile operator's MEC nodes plus a regional edge data center. Workloads can move between these environments based on latency, cost, and capacity. Federated edge requires cryptographic identity that is portable across operators. Standards like OpenID Connect, SPIFFE/SPIRE, and IEEE 802.1AR (secure device identity) are commonly used. PQC migration in federated edge means upgrading these identity standards and the infrastructure that issues federated identities. For more on the broader infrastructure context, see [SDN/NFV and PQC](sdn-nfv-pqc.html). ## Frequently Asked Questions **Can edge devices run NIST PQC algorithms?** Yes, on most modern hardware. ML-KEM-768 runs in single-digit milliseconds on Cortex-A class CPUs. The challenge is not raw compute but bandwidth, certificate sizes, and the cumulative cost of many small overheads adding up in dense deployments. **Do I need to upgrade my edge CA before my edge applications?** You need both, but the CA can be upgraded incrementally to issue hybrid certificates that work for both classical-only and PQC-aware clients. This avoids a flag day where every edge application has to upgrade simultaneously. **Is MACsec at the edge affected by PQC?** MACsec uses pre-shared symmetric keys, so the wire-line protocol is not directly affected. The 802.1X EAP layer that delivers MACsec keys is affected if it uses TLS-based EAP methods. Migrating EAP-TLS to hybrid PQC handles this. **How does PQC affect 5G slicing at the edge?** Network slicing relies on 3GPP control-plane signaling, which uses TLS in many places. The slicing control connections are exactly the kind of long-lived high-value traffic that needs hybrid PQC protection. Operators that run slicing in production have started piloting PQC on the slicing control interfaces. **What is the worst-case performance impact at the edge?** For a typical TLS handshake on Cortex-A72 hardware, hybrid ML-KEM-768 + X25519 adds about 1 to 2 milliseconds compared to pure X25519. For ML-DSA-65 certificate verification, the cost is also a few milliseconds. The bigger impact is bandwidth: handshake size grows from about 4 KB to about 10 KB. ## Sources - ETSI GS MEC 003, "Multi-access Edge Computing (MEC); Framework and Reference Architecture", https://www.etsi.org/deliver/etsi_gs/MEC/001_099/003/03.01.01_60/gs_MEC003v030101p.pdf - 3GPP TS 23.501, "System Architecture for the 5G System", https://www.3gpp.org/DynaReport/23501.htm - NIST FIPS 203, "Module-Lattice-Based Key-Encapsulation Mechanism Standard", https://csrc.nist.gov/pubs/fips/203/final - NIST FIPS 204, "Module-Lattice-Based Digital Signature Standard", https://csrc.nist.gov/pubs/fips/204/final - IEC 62443-4-2, "Security for industrial automation and control systems - Technical security requirements for IACS components", https://webstore.iec.ch/publication/34421 - OPC Foundation, "OPC Unified Architecture Specification Part 2: Security Model", https://reference.opcfoundation.org/Core/Part2/ ## Related Articles - [What is Post-Quantum Cryptography?](what-is-post-quantum-cryptography.html) - [Hybrid Encryption](hybrid-encryption.html) - [PQC IoT Smart Home Devices](pqc-iot-smart-home-devices.html) - [PQC for Telecom 5G and 6G](pqc-telecom-5g-6g.html) - [Harvest Now Decrypt Later](harvest-now-decrypt-later.html) --- ### Protect Your Data Before Q-Day Arrives QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats. [Try QNSQY](../../pricing.html)