# Cable Modem PQC: DOCSIS Roadmap **Source**: https://quantumsequrity.com/blog/cable-modems-pqc **Category**: Industry & Use Cases --- [← Back to Blog](../../blog.html) Industry & Use Cases # Cable Modem PQC: DOCSIS Roadmap 11 min read About one in three internet connections in North America runs over a cable modem. The number is similar or higher in much of Europe and parts of Asia. The technology that makes this work is DOCSIS (Data Over Cable Service Interface Specification), maintained by CableLabs, the cable industry's research consortium. DOCSIS has been evolving since the late 1990s and is now in its fourth generation, DOCSIS 4.0, which targets multi-gigabit symmetric speeds over the same coaxial cable that delivers television. Most users never think about how a cable modem authenticates to the network. The CMTS (Cable Modem Termination System) at the headend has to know that the modem connecting to it is a real modem and not an attacker, and the modem has to know that the headend is real. This trust relationship is established cryptographically, and the cryptographic system that makes it work is BPI+ (Baseline Privacy Plus). With the move to DOCSIS 4.0 and the broader push toward post-quantum cryptography, the cable industry is now planning how to migrate this infrastructure. ## What DOCSIS Does DOCSIS is the protocol that turns a coaxial cable into a high-speed bidirectional data network. The same cable that carries TV signals carries data streams, and DOCSIS defines how those data streams are encoded, prioritized, and authenticated. The endpoints are the cable modem (in the customer premises) and the CMTS (at the cable operator's headend). The CMTS aggregates traffic from many modems on the same physical cable plant, encodes downstream data into RF channels for the broadcast direction, and decodes upstream data from the modems on different RF channels. DOCSIS 3.0 introduced channel bonding for multi-gigabit speeds. DOCSIS 3.1 introduced OFDM modulation for even higher capacity. DOCSIS 4.0, currently rolling out, introduces "Full Duplex DOCSIS" (FDX) and "Extended Spectrum DOCSIS" (ESD) for multi-gigabit symmetric service. DOCSIS 4.0 also includes significant updates to BPI+ and the underlying PKI. ## BPI+ and the DOCSIS PKI BPI+ is the security layer of DOCSIS. It does three things: 1. Authenticates the cable modem to the CMTS 2. Establishes a session key for traffic encryption 3. Encrypts the data flow with AES-128-CBC or AES-128-GCM The authentication uses a manufacturer certificate baked into the cable modem at the factory. Every cable modem has a unique X.509 certificate signed by the manufacturer's certificate authority, which is in turn signed by the CableLabs root CA. The CMTS validates the certificate chain when the modem boots up, and the chain has to terminate at the CableLabs root. This is one of the largest and most distributed PKIs in the world. There are hundreds of millions of cable modems in service, each with a unique certificate, all chained back to a single CableLabs root. The root CA itself is operated according to industry-standard CA practices with offline ceremonies, hardware security modules, and multi-party controls. For PQC migration, this PKI has to evolve. Every certificate in the chain needs to support PQC algorithms. Existing modems that have RSA-2048 manufacturer certificates cannot be updated in the field, so the migration has to be incremental: new modems ship with PQC-capable certificates while old modems continue to use RSA. ## The DOCSIS 4.0 Security Updates DOCSIS 4.0 includes meaningful updates to BPI+. The new version (sometimes called BPI+ V2 in working drafts) includes: - AES-256-GCM as a primary cipher option (replacing AES-128-CBC) - Updated key derivation using HKDF - Crypto-agility framework for future algorithm updates - Discussion of PQC migration path CableLabs has published research and white papers on DOCSIS PQC migration. The current direction is hybrid: new modems will support both classical (RSA, ECDSA) and post-quantum (ML-DSA) certificates, with the CMTS choosing which authentication path to use based on what each modem supports. The actual deployment is expected to start around 2026 to 2028 as DOCSIS 4.0 rolls out widely. ## Why a Cable Modem Cares About PQC Three reasons. First, the BPI+ session keys protect the data flow between the modem and the CMTS. If an adversary records that traffic and a quantum computer breaks the key derivation in the future, the recorded traffic becomes readable. This is the standard [harvest now, decrypt later](harvest-now-decrypt-later.html) concern. Second, the manufacturer certificates have a long lifetime. A cable modem deployed in 2025 might be in service in 2032 to 2035. Its certificate will be valid that entire time. If RSA-2048 is broken before the certificate expires, an attacker can forge new modem identities and impersonate any subscriber. Third, software updates are signed. The cable operator pushes firmware updates to modems regularly, and those updates are signed with the operator's signing key. If the signing key uses RSA and that RSA gets broken, the attacker can sign fake firmware that takes over millions of modems. ## The CableLabs Root and Its Migration The CableLabs root CA is the trust anchor for the entire ecosystem. Every cable modem ships with the CableLabs root certificate (or its public key) embedded in firmware. The CMTS validates modem certificates against this root. Migrating the root is the hardest part of the PQC transition. New modems can be manufactured with PQC-aware firmware that knows about a new PQC root. Old modems cannot be updated to know about new roots, except via firmware updates that are themselves signed by the old root. There is a chicken-and-egg problem: you need the old root to validate the firmware update that adds the new root. The standard solution is cross-signing. The new PQC root is signed by the old classical root, creating a transitional certificate that both old and new modems can validate. New modems trust the PQC root directly. Old modems trust it via the cross-signed bridge. After all old modems are retired, the cross-sign can be deprecated. For more on the broader PKI migration patterns, see [the NIST FIPS guide](nist-fips-guide.html). ## Modem Authentication Latency When a cable modem boots up, it has to complete BPI+ authentication before it can pass user traffic. The classical RSA-based authentication takes a few hundred milliseconds. The user perception is that the modem boots in 30 to 60 seconds, of which the cryptographic part is a small fraction. PQC authentication adds overhead. ML-KEM-768 key exchange is a few hundred microseconds on modern hardware. ML-DSA-65 verification is a few hundred microseconds to a few milliseconds depending on implementation. The certificate sizes are larger (3.3 KB signatures vs 256 bytes for RSA-2048), which adds bandwidth on the upstream channel where the modem sends its certificate to the CMTS. For boot time, the cumulative effect is a small but noticeable increase. For modems that re-authenticate periodically or after network events, the cumulative cost matters more. CableLabs research has measured these costs in lab settings and concluded that they are tractable but require attention to certificate size and protocol design. Read more about ML-KEM in [ML-KEM explained](ml-kem-explained.html) and the broader hybrid migration approach in [hybrid encryption](hybrid-encryption.html). ## CMTS Side and Operational Scale A typical CMTS at a major cable operator handles thousands to tens of thousands of cable modems. Every modem authenticates to the CMTS at boot and re-authenticates periodically. The CMTS does cryptographic verification on every authentication, which means the CMTS is a busy cryptographic system. For PQC, the CMTS has to support PQC verification at scale. ML-DSA-65 verification is faster than ML-DSA-65 signing, and modern server CPUs can handle thousands of ML-DSA verifications per second per core. For a CMTS handling 10,000 modems with periodic re-authentication every hour, the cryptographic load is roughly 3 verifications per second per CMTS, which is trivial. The bigger CMTS-side concern is certificate storage and validation. The CMTS has to validate the full certificate chain (modem certificate -> manufacturer CA -> CableLabs root) on every authentication. PQC certificate chains are larger, and the CMTS has to keep its trust store updated as new manufacturer CAs are added. ## DOCSIS 4.0 and Beyond The current DOCSIS roadmap goes through DOCSIS 4.0 with a clear path. Looking further out, CableLabs is researching beyond-4.0 evolutions that include: - 25 Gbps and higher symmetric speeds - Integration with passive optical networks (PON) for fiber overlay - Cloud-native CMTS architectures (vCMTS) - Native PQC support in all new layer protocols The vCMTS direction is particularly relevant for PQC because virtualized CMTS implementations run on commodity servers and can adopt new cryptographic libraries more easily than purpose-built hardware. PQC migration in vCMTS deployments is expected to be faster than in traditional integrated CMTS hardware. ## DPoE and Fiber Convergence Many cable operators also deploy DOCSIS Provisioning of EPON (DPoE) for fiber-served customers. DPoE lets operators use DOCSIS-style provisioning and management for EPON (Ethernet Passive Optical Network) infrastructure. The cryptographic flows are similar to standard DOCSIS, with the same PKI dependencies. For PQC, DPoE migration follows the broader DOCSIS migration. New DPoE deployments expected to roll out from 2026 onwards are designed to be PQC-aware. ## What Operators Are Doing Now Major North American cable operators (Comcast, Charter, Cox, Rogers, Shaw) have been participating in CableLabs PQC working groups. The current operational focus is: 1. Inventory: understanding which modem models, CMTS firmware versions, and back-office systems are PQC-capable 2. Pilot: testing PQC certificate handling on small subscriber populations 3. Vendor engagement: requiring new modem and CMTS purchases to include PQC support 4. Back-office: updating provisioning systems, certificate authorities, and certificate management to handle PQC Realistic deployment timelines have major operators starting PQC pilot deployments around 2027, with broader rollout through 2030. This aligns with the NIST migration timeline and the CNSA 2.0 mandate dates. ## CableLabs Specifications and PQC CableLabs publishes a range of specifications beyond DOCSIS itself, including specifications for converged interconnect networks, network functions, and operational support systems. PQC migration affects each of these: - **Converged Interconnect Network (CIN)**: The network layer that aggregates traffic from many remote PHY devices to a centralized CMTS. CIN uses TLS for control-plane connections; PQC migration follows the broader NFV and SDN PQC story. - **Distributed Access Architecture (DAA)**: Modern cable architectures push DOCSIS PHY processing closer to the customer, with the MAC and control layers in centralized facilities. The control connections between distributed nodes and centralized cores need PQC TLS. - **vCMTS**: Virtualized CMTS implementations run in software on commodity servers. They inherit the PQC migration of any cloud-native deployment. CableLabs' broader PQC strategy treats DOCSIS as one component of a larger system that all needs to migrate together. ## Operator-Side Certificate Management Beyond the CableLabs root and the manufacturer CAs, individual cable operators run their own internal PKIs for back-office systems: CMTS authentication, OSS/BSS integrations, network monitoring, and customer-facing portals. These internal PKIs need PQC migration just like any enterprise PKI. The pattern that operators are following is similar to large enterprises: identify high-value internal certificates, pilot PQC issuance, deploy hybrid certificates that work for both PQC-aware and legacy clients, and migrate full systems over a 3 to 5 year window. This work runs in parallel with the DOCSIS-specific migration. ## Frequently Asked Questions **Will my cable modem stop working when PQC arrives?** No. Existing modems will continue to authenticate using their existing RSA certificates. The migration is incremental: new modems support PQC, old modems continue to use classical. Eventually old modems will be retired through normal hardware refresh cycles. **Does PQC make my internet faster or slower?** Neither, in any meaningful sense. The data flow itself is encrypted with AES, which is the same. PQC affects authentication and key exchange, which happen at boot and periodically. The user does not notice. **What about cable TV signaling?** Television transport uses different cryptography (CableLabs DRM, conditional access systems). DRM PQC migration is a separate but related effort. The DRM systems generally have shorter content lifetimes than data flows, so the harvest-now urgency is lower. **Is DOCSIS 4.0 backward compatible with PQC additions?** Yes. DOCSIS 4.0 includes hooks for cryptographic agility, and PQC support is being added as a feature within the DOCSIS 4.0 spec rather than as a new major version. Modems that support DOCSIS 4.0 from 2026 onwards are expected to support PQC. **What is the biggest risk during the migration?** Cross-signing or trust anchor missteps. If a cable operator deploys a new PQC root CA without proper cross-signing to the legacy root, deployed modems may fail to validate certificates and lose service. Migration discipline matters. ## Sources - CableLabs DOCSIS 4.0 Specification, https://www.cablelabs.com/specifications/CM-SP-MULPIv4.0 - CableLabs BPI+ Specification (DOCSIS Security), https://www.cablelabs.com/specifications/CM-SP-SECv4.0 - CableLabs PQC Research, https://www.cablelabs.com/blog/post-quantum-cryptography-pqc - 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 - NIST SP 800-208, "Recommendation for Stateful Hash-Based Signature Schemes", https://csrc.nist.gov/pubs/sp/800/208/final ## Related Articles - [What is Post-Quantum Cryptography?](what-is-post-quantum-cryptography.html) - [ML-KEM Explained](ml-kem-explained.html) - [Hybrid Encryption](hybrid-encryption.html) - [Harvest Now Decrypt Later](harvest-now-decrypt-later.html) - [NIST FIPS Guide](nist-fips-guide.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)