DOCSIS Explained: Cable Modems, the CMTS and Baseline Privacy

DOCSIS (Data Over Cable Service Interface Specification) is the family of specifications that lets a cable TV network carry internet traffic. A cable modem in your home talks over the coaxial cable to a Cable Modem Termination System (CMTS) run by the operator, and Baseline Privacy Plus (BPI+) authenticates the modem with a certificate, encrypts the traffic on the shared cable and checks the signature on every firmware image the operator pushes.

CableLabs writes the specifications; the ITU-T has published international versions in its J series. The first specification was issued in 1996 and DOCSIS 4.0 in 2019. This post goes one level deeper than our guides to DHCP and SNMP, both of which a cable modem depends on to come online.

Key takeaways

• CableLabs develops DOCSIS and lists the first specification issue dates as 1996 (1.0), 1999 (1.1), 2001 (2.0), 2006 (3.0), 2013 (3.1) and 2019 (4.0). The ITU-T versions include J.112 Annex B (first generation), J.122 (second generation, current edition December 2007) and the J.222 series (third generation, 2007).
• Cable is a shared medium: every home on a node hears the same downstream, which is why DOCSIS has had link layer encryption since the first generation.
• A modem boots in a fixed order: find and lock a downstream channel, learn the upstream parameters, range, get an address by DHCP, get the time by the RFC 868 Time Protocol, fetch a configuration file by TFTP, register with the CMTS, then start encryption.
• The configuration file sets your service: speed limits through service flows, how many devices may sit behind the modem, SNMP access and which firmware image to load. It carries two MD5 based integrity checks, one of them keyed with a secret shared between the CMTS and the provisioning system.
• BPI+ has four parts according to RFC 4131: key exchange and data encryption, cable modem authentication, multicast encryption, and authentication of downloaded software images. Its MIB lists ciphers from 40 bit DES up to 256 bit AES in CBC mode.
• The operator, not the subscriber, decides which firmware a cable modem runs. That puts patch timing in the operator's hands and means the router behind the modem is your responsibility.
• DOCSIS 4.0 raises specified capacity to 10 Gbps down and 6 Gbps up, using either full duplex (FDX) or extended spectrum frequency division duplex up to 1.8 GHz. In March 2026 CableLabs reported a multivendor interop focused on its new security features: elliptic curve cryptography for authentication and AES-256 for encryption.
• Changing a modem's configuration file to get service you have not paid for is theft of service. In the United States, 47 U.S.C. 553 makes it a federal offence with fines and prison terms.

What DOCSIS is and who writes it

DOCSIS defines the radio frequency interface, the media access control (MAC) protocol, security, and the operations and management interfaces that let modems from many manufacturers work with CMTS equipment from many other manufacturers. CableLabs, the research and development consortium of cable operators, runs the working groups, publishes the specifications and certifies equipment. Its own history post says plainly that CableLabs "owns the DOCSIS trademark" and oversees development of each new version.

The specifications come as a suite. For DOCSIS 4.0, the CableLabs technology page lists MULPIv4.0 (MAC and upper layer protocols), PHYv4.0 (physical layer), SECv4.0 (security), CM-OSSIv4.0 and CCAP-OSSIv4.0 (operations support for the modem and the CMTS). Older generations used documents such as the Radio Frequency Interface (RFI) and Baseline Privacy Interface Plus (BPI+) specifications. The CableLabs library is public to browse, but this post cites the freely readable ITU-T recommendations and IETF RFCs wherever a detail matters.

The ITU-T versions

The ITU-T publishes international equivalents in its J series:

• J.112, "Transmission systems for interactive cable television services" (March 1998), with Annex B titled "Data-over-cable service interface specifications: Radio-frequency interface specification". Annex B was revised in March 2001 and March 2004.
• J.122, "Second-generation transmission systems for interactive cable television services, IP cable modems". The edition in force is dated December 2007 and replaced a December 2002 edition. It is the source for most of the boot sequence and signal level figures below.
• J.222, the third generation, published as parts. J.222.0 is the overview (December 2007) and J.222.3 covers security services (November 2007). The ITU-T page for J.222.3 carries an unusual note: the recommendation "was never formally published because of copyright issues", so for third generation security the CableLabs documents remain the practical reference.
• J.382, "Advanced digital downstream transmission systems for television, sound and data services for cable distribution", published January 2014 and revised March 2018, covers the advanced downstream physical layer that arrived with the DOCSIS 3.1 era.

The TOPICS lead for this post said DOCSIS 1.0 dates from 1997. CableLabs' own table lists 1996 as the first specification issue date, and the ITU-T adopted its version in 1998. Product certification and deployment came later than the first paper specification, which is where most of the date confusion comes from.

How DOCSIS evolved from 1.0 to 4.0

Each generation kept backward compatibility, so a DOCSIS 3.0 modem still works on a DOCSIS 3.1 network and many networks carry several generations at once. CableLabs notes that "modems often live in the network for many years", which matters for security: the weakest modem on a node still has to be supported.

Dated timeline

Specified capacity by generation

Figures are from the CableLabs DOCSIS 4.0 technology page, which warns that they are "based on specifications" and that deployed performance varies. CableLabs' pages differ on DOCSIS 3.1 upstream (1 to 2 Gbps in the table, 1.5 Gbps in the 4.0 FAQ, up to 1 Gbps on the 3.1 page, 1.5 to 1.7 Gbps on a high split plant in the 2024 post) because they assume different plant configurations.

How a hybrid fibre coax network carries data

A cable network today is hybrid fibre coax (HFC). Fibre runs from the operator's headend or hub to a node in the neighbourhood, and coaxial cable runs from the node through amplifiers and taps to each home. The coax is shared: every modem on a node receives the same downstream signal and competes for the same upstream.

The pieces

• Headend or hub. The building where the operator's routers, provisioning servers and CMTS or CCAP core sit.
• CMTS or CCAP core. The CMTS terminates the DOCSIS link: it schedules the upstream, sends the downstream, runs ranging, enforces service flows and handles BPI+. The Converged Cable Access Platform (CCAP) merged video and data functions into one platform. CableLabs lists "taps, amplifiers, RPDs, CCAP cores and modems" among the components operators must evaluate for DOCSIS 4.0.
• Distributed access. In a Remote PHY design the physical layer moves out of the headend into a Remote PHY Device (RPD) at the node, and the link from headend to node becomes digital Ethernet over fibre instead of analogue optics. The CCAP core keeps the MAC functions. CableLabs publishes a Remote PHY specification family for this split.
• Node, amplifiers, taps and modem. The node converts between optical and RF, amplifiers boost the signal, taps feed individual homes, and the cable modem (often combined with a Wi-Fi router as a "gateway") sits in the home.

Downstream and upstream channels

The spectrum on the coax is split into a low band for upstream and a much larger high band for downstream. J.122 describes a classic North American downstream plan of 6 MHz channels in a range "from 50 MHz to as high as 860 MHz", with a cable modem required to accept channels centred from 91 to 857 MHz.

Before DOCSIS 3.1, data travelled on single carrier QAM (SC-QAM) channels. J.122 specifies 64QAM and 256QAM in the downstream at about 5.06 and 5.36 million symbols per second in a 6 MHz channel. Upstream channels use TDMA (time division) or, from DOCSIS 2.0, S-CDMA (synchronous code division), with QPSK through 64QAM.

DOCSIS 3.0 introduced channel bonding: several SC-QAM channels combined into one logical pipe. CableLabs gives the example of a modem bonding 32 downstream and four upstream SC-QAM channels for a theoretical peak of 1 Gbps down and 100 Mbps up.

OFDM and OFDMA in DOCSIS 3.1

DOCSIS 3.1 introduced orthogonal frequency division multiplexing (OFDM) downstream and orthogonal frequency division multiple access (OFDMA) upstream. Instead of one carrier per channel, an OFDM channel spreads data over many narrow subcarriers. Each subcarrier can be loaded with as many bits as its local signal quality allows, and noisy parts of the spectrum can be avoided without losing the whole channel. CableLabs credits the generation's gains to low density parity check (LDPC) coding, very high modulation orders and more than 1 GHz of usable spectrum. OFDMA applies the same idea upstream, letting many modems share an OFDM upstream channel by being assigned different groups of subcarriers and time slots.

CableLabs' typical DOCSIS 3.1 example is a modem with two OFDM plus 32 SC-QAM channels downstream and two OFDMA plus four SC-QAM channels upstream, reaching a theoretical 5 Gbps down and 1.7 Gbps up.

Why the upstream split matters

Upstream capacity depends on where the operator puts the boundary between the upstream and downstream bands, known as the split. The November 2024 CableLabs post gives these DOCSIS 3.1 ranges:

Moving the split means changing amplifiers and filters in the field, which is why upstream upgrades are slow.

What happens when a cable modem boots

J.122 clause 11.2 defines cable modem initialization as a fixed sequence. The RFC 4546 object docsIfCmStatusValue reports where a modem is in it (from notSynchronized through rangingComplete, ipComplete, todEstablished and registrationComplete to operational, or accessDenied), and RFC 4639's docsDevServerBootState adds states such as waitingForDhcpOffer, waitingForTimeServer, waitingForTftp and refusedByCmts.

Step 1: scan and lock a downstream

The modem tunes across the downstream band until it finds a DOCSIS channel and locks to its timing (SYNC messages) and its forward error correction.

Step 2: learn the upstream

On the downstream, the CMTS broadcasts upstream channel descriptors and bandwidth allocation maps. The modem picks a usable upstream channel and learns where the initial maintenance opportunities are, the windows in which a modem that has not yet ranged may transmit.

Step 3: ranging

Ranging lines up every modem's transmissions in time, power and frequency, because each home sits at a different distance from the node. The modem transmits a ranging request at a low power and steps up until the CMTS answers with corrections. J.122 Table 6-8 lets the CMTS command upstream power in 0.25 dB steps, within a TDMA range of +8 to +54 dBmV for 32QAM and 64QAM and +8 to +58 dBmV for QPSK, and +8 to +53 dBmV for S-CDMA. Ranging repeats periodically for as long as the modem is online.

Step 4: DHCP

J.122 clause 11.2.6 says the modem "MUST invoke DHCP mechanisms" from RFC 2131 to get an IP address, and the DHCP response "MUST contain the name of a file that contains further configuration parameters". The file's TFTP server comes from the siaddr field. The recommended retransmission backoff starts at 4 seconds and ends at 64 seconds, with a randomised plus or minus one second and a limit of five retries. This is the modem's own management address, separate from the address your router gets later.

J.122 also has a rule that matters for security: the modem's DHCP, TFTP and time of day clients "MUST only be sent via the RF Interface", and the modem must ignore DHCP, TFTP and time server messages arriving on the customer side port. A device on your LAN cannot answer the modem's provisioning requests.

Step 5: time of day

The modem asks for the time using the RFC 868 Time Protocol over UDP and adds the time offset from DHCP. J.122 says the time "need not be authenticated and need only be accurate to the nearest second"; its job is to timestamp the event log. If the time server does not answer, the modem logs the failure, continues to register and keeps retrying, at least once and at most three times per five minutes per server. Event log entries with a default date far in the past usually mean this step failed.

Step 6: TFTP configuration file

After DHCP, the modem "MUST download the parameter file using TFTP". The file is binary, a sequence of type, length, value (TLV) settings. If the file names an upstream channel or downstream frequency different from the one the modem is using, the modem must not register and must range again on the configured channel.

Step 7: registration

The modem sends a registration request (REG-REQ) to the CMTS carrying the settings from the configuration file that the CMTS must enforce. J.122 lists settings the modem must not forward, including the software upgrade filename, the software upgrade TFTP server, SNMP write access control and the CPE Ethernet MAC addresses. The CMTS checks the request against a keyed digest (described below) and answers with a registration response; the modem acknowledges. Only now can the modem forward customer traffic.

Step 8: Baseline Privacy initialisation

In J.122, Baseline privacy initialization (clause 11.2.10) follows registration (clause 11.2.9) when the configuration file enables privacy: the modem proves its identity with its certificate, receives an authorization key and then traffic encryption keys. The RFC 4546 state list numbers securityEstablished before paramTransferComplete, so the order is not identical across generations; check your generation's specification if it matters.

What the configuration file controls

The configuration file is the subscriber's service contract in machine form. The TLVs J.122 names in the CMTS integrity calculation give a good list of what it controls:

How the file is protected

J.122 Annex D defines two checks. The CM MIC is an MD5 digest over the configuration settings; the modem recomputes it and must discard the file if it does not match. That only proves the file was not corrupted, because anyone can compute an unkeyed MD5. The CMTS MIC is the real control. Annex D says the CMTS and the configuration server "share an authentication string", and clause D.3.1.1 says the digest "MUST be calculated using HMAC-MD5 as defined in [RFC 2104]" over the service affecting settings: network access, service flows, maximum CPEs, privacy settings, the TFTP server timestamp and provisioned modem address, and more. The modem passes those settings to the CMTS in the order it received them so the CMTS can recompute the HMAC. If a file was changed after the provisioning system signed it, the CMTS refuses registration.

The TFTP server timestamp and provisioned modem address fields in that list tie a file to the moment it was served and the modem that fetched it, which makes replaying one modem's file for another harder. The keyed digest is only as strong as the shared secret behind it, so a guessable or reused secret undermines the whole check.

How Baseline Privacy Plus and the DOCSIS security specification work

Because every modem on a node hears the same downstream, DOCSIS needed link layer privacy from the start. DOCSIS 1.0 had Baseline Privacy Interface (BPI), which encrypted traffic but did not strongly authenticate modems. BPI+ arrived with DOCSIS 1.1. RFC 4131, the September 2005 IETF MIB for BPI+, summarises it as four "distinct functional and manageable areas":

1. Key exchange and data encryption
2. Cable modem authentication
3. Multicast encryption, with multicast groups mapped to their own SAIDs
4. Authentication of downloaded software images

DOCSIS 1.1 and 2.0 systems implement both BPI+ and the older BPI.

Modem certificates

Each BPI+ modem carries an X.509 device certificate issued under a manufacturer certificate. RFC 4131 exposes the "X509 DER-encoded manufacturer certificate" and lets the CMTS mark certificates as trusted, untrusted, chained or root, and classifies each modem's certificate as valid, valid and chained, invalid because the modem certificate is untrusted, or invalid because its CA chains to an untrusted certificate. The MIB also says manufacturer certificates must not be given root trust. In practice the operator's CMTS trusts a root operated for the DOCSIS ecosystem and checks that each modem's certificate chains to it, which ties a modem's identity to a manufacturer controlled private key rather than to a MAC address alone.

The key hierarchy

BPI+ key management (Baseline Privacy Key Management, BPKM) works in two layers:

• Authorization key. After the modem sends its certificates, the CMTS returns an authorization key that only that modem can recover. RFC 4131 gives the CMTS a default authorization key lifetime of 604,800 seconds, which is seven days, configurable up to 6,048,000 seconds.
• Traffic encryption keys (TEKs). Protected by the authorization key, the modem requests a TEK for each security association it belongs to. A security association is identified by a SAID. The default TEK lifetime in RFC 4131 is 43,200 seconds, twelve hours, configurable up to 604,800.

The modem starts renewing early. docsBpi2CmAuthGraceTime and docsBpi2CmTEKGraceTime tell it to request a new key that many seconds before the current one expires, so traffic never stops for a key change.

Ciphers

RFC 4131's data encryption algorithm list reads: des56CbcMode, des40CbcMode, t3Des128CbcMode, aes128CbcMode and aes256CbcMode. The 40 bit and 56 bit DES options date from export era cryptography and are far too weak today. Which of these a given modem and CMTS actually negotiate depends on the generation and on operator configuration, so "BPI+ is enabled" on its own says little about strength.

Secure software download

The fourth area protects firmware. RFC 4639 says a modem that implements the BPI+ code verification mechanisms "verifies the source and integrity of the downloaded image by validating one or more Code Verification Signatures that are bundled within the software upgrade". The image is signed by the manufacturer and can be co-signed by the operator. RFC 4131 exposes the result of the last check as one of configFileCvcVerified, configFileCvcRejected, snmpCvcVerified, snmpCvcRejected, codeFileVerified, codeFileRejected or other, along with the manufacturer's and co-signer's organisation names and stored codeAccessStart and cvcAccessStart time values that the specification uses when deciding whether a code verification certificate is current.

A modem should therefore load only an image signed by its manufacturer and, where the operator co-signs, approved by the operator. The status list shows the operator's code verification certificate can arrive in the configuration file or by SNMP.

DOCSIS 4.0 security

CableLabs reported in March 2026 that its interop event of March 2 to 5 "verified interoperability across new DOCSIS 4.0 security features", with ten modem vendors taking part. The post describes elliptic curve cryptography (ECC) being adopted for authentication in place of older public key approaches because it gives strong security with smaller keys and faster certificate operations, and AES-256 for data encryption to protect confidentiality on the access network. The full SECv4.0 text is listed in the CableLabs library; this post relies on the CableLabs summary for the 4.0 changes and does not describe protocol details it could not read in the specification itself.

Who controls cable modem firmware

On a DOCSIS network, the operator decides what firmware runs on the modem, even a modem the subscriber bought. There are two paths, both documented in RFC 4639.

Through the configuration file. The file can name a software upgrade filename and TFTP server. If the running image does not match, the modem downloads the named image, verifies its signatures and reboots into it. The docsDevSwAdminStatus value allowProvisioningUpgrade permits this.

Through SNMP. The operator sets docsDevSwServer to the TFTP server, docsDevSwFilename to the image path and docsDevSwAdminStatus to upgradeFromMgt. After a successful download the modem sets itself to ignoreProvisioningUpgrade and reboots, so a diagnostic image is not immediately reverted by the configuration file. RFC 4639 says the modem may refuse an incomplete, damaged or wrong hardware image.

What that means for patching and trust

• You cannot patch your modem yourself. Even on a retail modem, the manufacturer builds firmware for operators, the operator certifies it for its network and then pushes it. A fix can exist upstream and still take months to reach your device.
• You cannot easily see what is inside it. The firmware is a closed build, and the subscriber has no software bill of materials for it.
• The operator has deep access. SNMP write access lets the operator change filters, limits and firmware. RFC 4639 warns that manipulating its tables "may allow an end-user to increase his or her service levels, spoof his or her IP addresses, change the permitted management stations, or affect other end-users". That is why operators restrict modem management to their own network and why SNMPv3 with USM and VACM "MUST be used with any v3 agent that implements this MIB module".
• Signatures protect integrity, not quality. Code verification proves the image came from the manufacturer and operator. It does not prove the image is free of vulnerabilities.

The practical result for a household or a small office: treat the cable modem as part of the operator's network and keep your own trust boundary at a router you control. That is the bridge mode setup in the walkthrough below.

What changed in DOCSIS 4.0

DOCSIS 4.0 keeps the OFDM and OFDMA physical layer of 3.1 and gives it more spectrum, with two ways to get there. CableLabs' November 2024 post describes the choice:

• Frequency division duplex (FDD), also called Extended Spectrum DOCSIS (ESD). Upstream and downstream keep separate bands, but the plant is extended to 1.8 GHz and the split moves much higher. CableLabs quotes upstream capacities of 4.2 Gbps on an ultra high split (UHS) plant at 396 MHz and 6 Gbps at 684 MHz, with 9 to 10 Gbps downstream.
• Full duplex (FDX). Part of the spectrum carries upstream and downstream at the same time, with echo cancellation at the node. CableLabs says an FDX plant can also reach up to 6 Gbps upstream and 9 to 10 Gbps or more downstream.

Both figures assume a DOCSIS 4.0 modem with the minimum of five OFDM downstream channels and seven OFDMA upstream channels. A plant is configured for one mode or the other, though devices exist that support both. A DOCSIS 3.1 modem can be software upgraded to work inside an FDX network with limited capabilities, and an intermediate class of "DOCSIS 3.1 Plus" modems with four or five OFDM channels can reach 8 or 9 Gbps downstream on 3.1 equipment.

On security, CableLabs presents the generation's additions as stronger certificate authentication with ECC and AES-256 encryption, tested across vendors in 2026.

DOCSIS 4.0 compared with fibre PON

Fibre to the home with a passive optical network (PON) is the main alternative access technology. In a PON, an optical line terminal (OLT) at the operator sends light down a fibre that is split passively to many homes; each home has an optical network unit (ONU). It is also a shared medium, so it also needs link layer encryption.

The GPON figures come from G.984.1 (March 2008), which says "the most important bit rate is 1.2 Gbit/s up, 2.4 Gbit/s down" and that split ratios "of up to 1:64 are realistic" for the physical layer while the transmission convergence layer "must consider split ratios up to 1:128". XGS-PON is defined in G.9807.1 (February 2023, amended May 2025). For security the shape is the same in both: an operator managed device at the edge of your home and a router behind it that is yours to secure.

What a subscriber can see and check

You can learn a lot about your connection from the modem's own status page, and nothing on it requires changing the modem.

Status page. Most modems serve a read only status page on the customer side, often at a private address such as 192.168.100.1; check the label or manual. It typically shows the startup steps, channel tables, firmware version and event log.

Signal levels. For each downstream channel: frequency, power in dBmV, signal to noise ratio (SNR) or modulation error ratio (MER) in dB, and codeword counters. For each upstream channel: frequency, symbol rate and transmit power in dBmV. RFC 4546 defines these values in tenths: docsIfDownChannelPower is in tenths of a dBmV ("5.1 dBmV will be represented as 51") and docsIfSigQSignalNoise is in tenths of a dB. It also defines docsIfSigQCorrecteds and docsIfSigQUncorrectables, the counters behind the "corrected" and "uncorrectable" columns.

Event log. Timestamped entries for ranging timeouts, lost sync, DHCP and TFTP problems and BPI+ errors. Look for patterns over time rather than single entries.

What you should not do

• Do not edit or replace the configuration file. The configuration file is how the operator enforces your service tier. Changing it, serving the modem a different file, or using modified firmware to get speeds you are not paying for is theft of service. In the United States, 47 U.S.C. 553(a)(1) says no person shall "intercept or receive or assist in intercepting or receiving any communications service offered over a cable system" unless authorised. A wilful violation is punishable by a fine of up to 1,000 dollars or up to six months in prison; for commercial advantage or private gain the limits rise to 50,000 dollars and two years for a first offence and 100,000 dollars and five years after that, and operators can also sue for damages. Other countries have similar laws.
• Do not install unofficial firmware or probe the operator's network. A modified modem can disrupt other customers on the node, and the CMTS and provisioning servers are not yours to scan.

If your levels look wrong, the fix is a support call, not configuration changes.

Step by step: read the status page, check firmware and bridge your own router

These steps assume a Linux or macOS computer on your home network. They only read status information and change settings on equipment you own or rent.

Step 1: find the modem's status address

If your router is already behind the modem, the modem's status page is usually reachable through the router even though it is not your default gateway. Check your router's WAN details or the modem label first. From a computer you can confirm the path:

# Show your default gateway (your router)
ip route show default            # Linux
route -n get default             # macOS

# Trace toward the internet; the modem in bridge mode does not usually appear as a hop,
# because it forwards at layer 2. A gateway in router mode will.
traceroute -n -m 3 1.1.1.1

Then open the address from the label, for example http://192.168.100.1/, in a browser. Many modems show signal data without logging in; settings pages need the administrator password.

Step 2: record the downstream table

Copy the downstream table into a spreadsheet or a text file with the date and time. A snapshot looks like this (example values):

Channel  Lock    Modulation  Freq (MHz)  Power (dBmV)  SNR/MER (dB)  Corrected  Uncorrectable
1        Locked  256QAM      591.0       3.4           40.1          12         0
2        Locked  256QAM      597.0       3.1           39.8          9          0
...
33       Locked  OFDM PLC    722.0       -1.2          41.0          10450      0

If your modem exposes SNMP on the customer side (many do not, and you should not expect it), the same values are in the RFC 4546 MIB in tenths. For a lab modem you own, this is how they would be read with net-snmp; never point it at operator equipment:

# Read only; values are in tenths of a dBmV and tenths of a dB
snmpwalk -v2c -c public 192.168.100.1 DOCS-IF-MIB::docsIfDownChannelPower
snmpwalk -v2c -c public 192.168.100.1 DOCS-IF-MIB::docsIfSigQSignalNoise
snmpwalk -v2c -c public 192.168.100.1 DOCS-IF-MIB::docsIfSigQUncorrectables

Step 3: interpret downstream power and SNR with the specification numbers

J.122 Table 6-17 requires a DOCSIS modem to accept each downstream SC-QAM channel at a level from -15 dBmV to +15 dBmV, with total input power across 40 to 900 MHz below 30 dBmV. For 256QAM it must achieve a post FEC bit error rate of 10 to the power minus 8 with a carrier to noise ratio (Es/No) of 30 dB or better when the level is between -6 and +15 dBmV, and 33 dB or better when the level is below -6 down to -15 dBmV. For 64QAM the threshold is 23.5 dB.

These are the limits a modem must work at, not operator design targets, which sit well inside them. Two worked examples using the J.122 thresholds:

Example 1: healthy channel. Power 3.4 dBmV, SNR 40.1 dB, 256QAM. The level is well inside -15 to +15 dBmV and above -6 dBmV, so the 30 dB requirement applies. The margin is 40.1 minus 30, or 10.1 dB. Corrected codewords are low and uncorrectables are zero. Nothing to do.

Example 2: weak channel. Power -8.6 dBmV, SNR 31.4 dB, 256QAM. The level is below -6 dBmV, so the requirement rises to 33 dB. The margin is 31.4 minus 33, or minus 1.6 dB: the channel is below the level at which the specification guarantees error free performance. Expect uncorrectable codewords to climb, especially at busy times. Typical causes are a loose or corroded connector, an unused splitter, a long run of old cable, or a fault outside the house. Remove splitters you do not need, tighten connectors by hand plus a quarter turn, and call the operator if it persists.

In MIB units, example 2 reads as docsIfDownChannelPower = -86 and docsIfSigQSignalNoise = 314.

Step 4: interpret upstream transmit power

Upstream power is set by the CMTS during ranging, not by you. J.122 allows +8 to +54 dBmV for 64QAM and up to +58 dBmV for QPSK on TDMA channels. A modem transmitting near the top of its allowed range is compensating for loss between the house and the node. If one upstream channel reads 52 dBmV on 64QAM, the modem has only 2 dB left before it hits the 54 dBmV ceiling; any extra loss and it may fail ranging, which shows up in the event log as ranging timeouts. The fix is the same as for weak downstream levels: find the extra loss in the cabling or report it.

Step 5: check the firmware version

The status page usually shows the software or firmware version, the hardware version and sometimes the boot loader version. Record them. Then:

• Compare with the manufacturer's release notes or advisories for your model.
• If an advisory names your model and you run an older build, ask the operator when the fixed build will reach you. A version that changes on its own is normal: that is the operator's upgrade path described above.

Step 6: put your own router behind the modem in bridge mode

If you rent a gateway (modem and router in one box), you can usually switch it to bridge mode so it only acts as a modem and your own router handles routing, firewalling, Wi-Fi and DNS. The names vary: bridge mode, modem mode, passthrough. Some operators require you to request it through their app or support. This changes only your gateway's routing role and is a normal supported setting.

1. Note any port forwards and Wi-Fi settings you need from the gateway.
2. Connect your router's WAN port to the gateway port its manual names for bridge mode.
3. Turn on bridge mode or ask the operator to. The gateway's Wi-Fi and DHCP server switch off.
4. Set the router's WAN to DHCP, and DHCPv6 with prefix delegation for IPv6.
5. Power cycle the gateway, then the router. The configuration file's maximum CPE setting limits how many customer MAC addresses the modem accepts, and a power cycle clears the old one.

Verify on a Linux based router (example interface names):

# The WAN should now hold a public address, not 192.168.x.x, 10.x.x.x or 172.16-31.x.x
ip -4 addr show dev wan
ip -6 addr show dev wan
ip -6 route show | grep -i "proto dhcp"   # delegated prefix routes, if your operator provides them

# Your router should be the only gateway on the LAN
ip route show default

On OpenWrt the same checks are ifstatus wan and ifstatus wan6.

Step 7: confirm what is reachable from inside and outside

From a computer on your LAN, list what the modem exposes on its status address. Scan only the device you own or rent:

# Read-only TCP service scan of your own modem's status address
nmap -Pn -sT -p 1-1024 192.168.100.1

You should see at most a web status page. Close any router port forwards you no longer use.

Step 8: harden the router you now own

• Set a unique administrator password. CISA warns that default credentials "may be readily available on the internet".
• Turn on automatic updates and disable remote administration and Universal Plug and Play if you do not need them; CISA recommends disabling unnecessary services.
• Put smart home devices on a separate network or VLAN.

Common mistakes

• Leaving the modem's management interface reachable. A gateway with remote management enabled, or a status page exposed by a port forward, gives others a view into your connection and sometimes settings access. Keep management to the LAN and turn off remote access unless the operator needs it and you have agreed to it.
• Renting a gateway and keeping the default Wi-Fi credentials. The default network name and passphrase are printed on a label, and anyone who sees the label, from a repair visit to a house guest's photo, has your Wi-Fi password. Change both and change the administrator password too.
• Assuming the ISP patches the in-home router. The operator patches the modem and, if you rent one, the gateway's router functions. If you bring your own router, or bridge the gateway, nobody patches that router but you.
• Treating BPI+ as end to end encryption. BPI+ encrypts between the modem and the CMTS. Past the CMTS your traffic is ordinary IP traffic, and inside your home it is whatever your router and Wi-Fi provide. Use TLS and a VPN where you need confidentiality beyond the access network.
• Reading one bad number as a fault. Corrected codewords are normal, and a single T3 timeout is noise. Watch for uncorrectables that keep climbing, SNR below the thresholds above or upstream power near the ceiling.
• Adding splitters and amplifiers to fix Wi-Fi coverage. A cheap splitter costs several dB of downstream level and can drop a marginal channel below spec. Fix Wi-Fi coverage with access points, not with the coax.
• Running a double NAT by accident. A gateway left in router mode in front of your router breaks port forwards and often IPv6. Use bridge mode.
• Buying a modem without checking the operator's approved list. Operators only provision models they have certified, and only those get firmware from them.

Where Safeguard fits

The fit here is indirect, and it is better to say so. Safeguard does not scan cable modem firmware, does not inspect DOCSIS traffic and does not manage routers or other endpoints. Cable modem images are closed builds controlled by the operator and the manufacturer. Where Safeguard helps is the software you build yourself around a network like this: the configuration generator for a lab or small office router, a Prometheus exporter that scrapes modem status pages, a home automation stack or an internal provisioning tool written in Python or Go. Safeguard scans those repositories and container images (safeguard scan --dir . or safeguard scan --image <name>), matches components against vulnerability databases, ranks findings with reachability analysis and can open fix pull requests through autonomous remediation, which ships switched off until your team enables it.

FAQ

What is DOCSIS in simple terms?

DOCSIS is the set of specifications that lets a cable TV network carry internet traffic. It defines how a cable modem and the operator's CMTS talk over coaxial cable, how the modem is provisioned and how its traffic is encrypted. CableLabs writes it; the ITU-T publishes international versions in its J series.

What is a CMTS?

A Cable Modem Termination System is the operator side equivalent of your modem. It sends the downstream signal, schedules every modem's upstream transmissions, runs ranging, enforces service tiers from the configuration file and handles BPI+ key exchange. In modern networks its functions sit in a CCAP core, often with the physical layer moved to a Remote PHY device at the node.

What is the difference between DOCSIS 3.0, 3.1 and 4.0?

DOCSIS 3.0 (2006) bonded several single carrier QAM channels for up to about 1 Gbps down. DOCSIS 3.1 (2013) added OFDM and OFDMA, LDPC coding and wider channels for up to 10 Gbps down in the specification. DOCSIS 4.0 (2019) keeps OFDM but adds full duplex or extended spectrum to 1.8 GHz, raising specified upstream to 6 Gbps.

Is cable internet traffic encrypted?

Between your modem and the CMTS, yes, when BPI+ is enabled, which is standard practice. It uses certificates to authenticate the modem and block ciphers such as AES to encrypt traffic. It does not protect your traffic beyond the operator's CMTS or inside your home, so use HTTPS and a VPN where you need more.

Can I update my cable modem's firmware myself?

No. The operator pushes firmware through the configuration file or SNMP, and the modem only accepts images whose code verification signatures check out. Ask the operator about newer builds.

What are good downstream power and SNR levels for a cable modem?

The ITU-T J.122 specification requires a modem to work with downstream SC-QAM channels from -15 to +15 dBmV and, for 256QAM, an SNR of at least 30 dB (33 dB below -6 dBmV). Operators design to tighter ranges inside those limits, so check your operator's published numbers before calling a reading bad.

What does bridge mode on a cable modem do?

Bridge mode turns off the gateway's router, firewall, DHCP server and Wi-Fi so it acts only as a modem, and your own router receives the public address. It avoids double NAT and puts the router's patching under your control.

Is it illegal to modify a cable modem config file?

Yes, when the aim is service you have not paid for. In the United States 47 U.S.C. 553 prohibits receiving cable communications services without authorisation, with fines, prison terms and civil damages.

How does DOCSIS 4.0 compare with fibre?

DOCSIS 4.0 reaches up to 10 Gbps down and 6 Gbps up over existing coax with plant upgrades, while PON fibre such as XGS-PON offers symmetric 10 gigabit capability with no active equipment in the field. Both share capacity among neighbours and both use an operator managed device in the home.

A DOCSIS network is mostly closed operator equipment whose fixes must come from the operator, but the router you put behind the modem, the scripts that monitor it and any provisioning tool you write all ship open source components. Those you can keep current yourself, and the standard Safeguard remediation guide below covers how.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real session with the Safeguard CLI. The assistant reads a finding and its advisory, asks before each command, upgrades a dependency, runs the tests and pushes nothing. The same flow applies when a library inside your router configuration generator or modem monitoring exporter needs an upgrade.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard runner on your own machine, approves it with a device code and then scans from the terminal. Home lab and small office network tooling often lives on a machine behind the modem rather than in a hosted repository, and the runner lets you scan it where it sits.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. Granting a narrow set of tools follows the same idea as keeping a modem's management interface on the LAN only: give each party only the access it needs.

Click through it at your own pace, or open it full screen.

Download the apps at safeguard.sh/download and read the CLI docs at docs.safeguard.sh/docs/cli.

Quick check

Sources

• CableLabs: DOCSIS 4.0 Technology
• CableLabs: DOCSIS 3.1 Technology
• CableLabs blog: The Evolution of DOCSIS Technology: Building the Future of Connectivity (November 20, 2024)
• CableLabs blog: Authentication and Privacy: DOCSIS 4.0 Interop Focuses on Security (March 20, 2026)
• CableLabs: Specifications library
• CableLabs: CM-SP-SECv4.0 specification page
• CableLabs: CM-SP-R-PHY specification page
• ITU-T J.112: Transmission systems for interactive cable television services
• ITU-T J.122: Second-generation transmission systems for interactive cable television services, IP cable modems
• ITU-T J.122 (12/2007) full text, PDF
• ITU-T J.222.0: Third-generation transmission systems, IP cable modems: Overview
• ITU-T J.222.3: Third-generation transmission systems, IP cable modems: Security services
• ITU-T J.382: Advanced digital downstream transmission systems for cable distribution
• RFC 2669: DOCSIS Cable Device MIB (August 1999)
• RFC 4131: Management Information Base for DOCSIS Cable Modems and CMTS for Baseline Privacy Plus (September 2005)
• RFC 4546: Radio Frequency (RF) Interface Management Information Base for DOCSIS 2.0 Compliant RF Interfaces (June 2006)
• RFC 4639: Cable Device Management Information Base for DOCSIS Compliant Cable Modems and CMTS (December 2006)
• ITU-T G.984.1: Gigabit-capable passive optical networks (GPON): General characteristics
• ITU-T G.984.1 (03/2008) full text, PDF
• ITU-T G.9807.1: 10-Gigabit-capable symmetric passive optical network (XGS-PON)
• 47 U.S.C. 553: Unauthorized interception or receipt of cable service (Cornell LII)
• CISA: Home Network Security

Related reading: DHCP explained and SNMP explained.

Last reviewed: 24 October 2026. The DOCSIS 4.0 specifications and their security features are still being deployed; check the CableLabs specification library, the ITU-T J series and your operator's guidance before relying on a specific value.