GPON and XGS-PON are the ITU-T standards behind most fibre to the home. An optical line terminal (OLT) in the operator's exchange sends light down one fibre, unpowered splitters share it among dozens of homes, and an optical network terminal (ONT) in each home picks out its own traffic. GPON runs at about 2.5 Gbit/s down and 1.25 Gbit/s up per fibre; XGS-PON at about 10 Gbit/s both ways.
Securing them is a split job. The standards provide AES encryption of user traffic, ONT authentication by serial number, password or registration ID, and in newer generations integrity checks and mutual authentication. The operator decides which are switched on and controls the ONT's firmware through a management protocol called OMCI. As a subscriber, your part is the router and network behind the ONT. This post goes one level deeper than our guides to how a home router is made and how optical transceivers are made, and sits next to our DOCSIS explainer for cable.
Key takeaways
- A passive optical network (PON) has one active box at each end: the OLT at the operator and the ONT (ITU-T also says ONU, optical network unit) at the customer. In between is glass and unpowered splitters.
- ITU-T G.984.1 sets GPON's split at up to 1:64 for the physical layer (1:128 for the protocol layer), a maximum logical reach of 60 km and a maximum differential fibre distance of 20 km.
- GPON's main rates are 2.48832 Gbit/s down and 1.24416 Gbit/s up, at 1480 to 1500 nm down and 1260 to 1360 nm up. XGS-PON (G.9807.1) runs 9.95328 Gbit/s both ways, normally at 1575 to 1580 nm down and 1260 to 1280 nm up, so it can share a fibre with GPON.
- Downstream is a broadcast that every ONT receives. GPON encrypts GEM payloads with AES-128 in counter mode; in the base standard the ONT sends its key upstream in the clear, because neighbours cannot see upstream light.
- XGS-PON adds AES-CMAC integrity keys for management messages, a key encryption key, optional upstream encryption and optional mutual authentication (OMCI based or IEEE 802.1X).
- OMCI (ITU-T G.988) is how the OLT configures the ONT and replaces its firmware. G.988 leaves image verification to vendors, asking only for at least an integrity check such as a CRC.
- Many fibre boxes have two managers: OMCI for the PON side and TR-069 (CWMP) or TR-369 (USP) for the router side.
What a passive optical network is
A PON is a point to multipoint fibre network. One OLT port in the central office feeds one fibre. An optical splitter, sometimes two in stages (for example 1:8 in a cabinet and 1:8 near the homes), divides the light among many output fibres. Each ends at an ONT, which turns light into Ethernet for your router. The splitters have no electronics or power supply, so the operator has nothing to power or patch in the street. The cost is that every home on the tree shares the same fibre and the same light.
| Part | Where it sits | What it does |
|---|---|---|
| OLT (optical line termination) | Operator exchange | Sends downstream, schedules upstream time slots, runs ranging, holds keys, connects to the core |
| ODN (optical distribution network) | Ducts, cabinets, risers | Feeder fibre, passive splitters and drop fibres; no power |
| ONT or ONU | Customer premises | Receives its share of downstream, transmits upstream in its time slot |
| CPE router | Behind or built into the ONT | NAT, firewall, Wi-Fi and DHCP for the home |
ITU-T uses ONU as the general term and ONT for an ONU at a single subscriber's premises.
Why one fibre serves 32 to 128 homes
Each split halves the optical power, so a 1:64 split loses far more light than 1:32, and the OLT laser and ONT receiver must cover splitter loss plus fibre, connector and splice loss. G.984.1 (03/2008) says a larger split is more attractive to operators, but "split ratios of up to 1:64 are realistic for the physical layer, given current technology," while the transmission convergence layer must allow 1:128. It sets the logical reach at 60 km, physical reach options of 10 km and 20 km, and a maximum differential fibre distance (the gap between nearest and farthest ONT) of 20 km.
XGS-PON raises the floor. G.9807.1 (02/2023) makes 1:64 the minimum, because many operators built 1:32 to 1:64 trees for GPON, and notes operators may go to 1:128 or 1:256 for better economics. It requires a fibre distance of at least 20 km, a differential distance of up to 40 km and operation on ODNs of nominally 28 or 29 dB loss.
How GPON works
GPON is the ITU-T G.984 series: G.984.1 (general characteristics), G.984.2 (physical layer), G.984.3 (transmission convergence: framing, ranging, bandwidth allocation, PLOAM messaging and security) and G.984.4 (ONT management), later generalised into G.988 for all ITU-T PONs.
Rates and wavelengths
G.984.1 lists two rate pairs and says 1.2 Gbit/s up with 2.4 Gbit/s down makes up nearly all deployed GPON; G.984.2 gives the exact line rates of 2488.32 and 1244.16 Mbit/s. After framing overhead and sharing with the other homes on the tree, each subscriber gets less, which is why operators sell tiers well below line rate. Both directions share one fibre by wavelength: 1480 to 1500 nm down and 1260 to 1360 nm up. Some operators add an RF video overlay at 1550 to 1560 nm, which the newer G.9804.1 still requires PON systems to coexist with.
Downstream: one broadcast, many listeners
The OLT sends 125 microsecond frames that every ONT receives. User traffic rides in GEM (GPON encapsulation method) frames tagged with a 12 bit Port-ID; each ONT keeps its own Port-IDs and discards the rest. That filter is not a security boundary. The Broadband Forum's TR-156 Issue 4 (November 2017) notes that all ONUs receive all downstream traffic for every GEM port, and that AES encryption "can be (and typically is) applied over bidirectional GEM ports," with a different key per ONU. The encryption is what provides privacy.
Upstream: time slots, ranging and DBA
Every ONT shares the fibre back to the OLT, and simultaneous bursts would collide at the splitter. So the OLT publishes a bandwidth map in each downstream frame saying which allocation may transmit and when. G.984.3 defines an 8 bit ONU-ID assigned at activation, a 12 bit Alloc-ID per upstream allocation (the default one equals the ONU-ID and carries PLOAM and the OMCI channel), and T-CONTs, the OMCI objects that hold upstream queues for an Alloc-ID.
Because ONTs sit at different distances, the OLT runs ranging during activation: it measures each ONT's round trip delay and assigns an equalization delay so every ONT appears to be at the same logical distance. With dynamic bandwidth assignment (DBA) the OLT then adjusts allocations many times a second, either from ONT queue reports (status reporting DBA) or by watching for idle frames in granted slots (traffic monitoring DBA).
Activation and PLOAM
The PLOAM (Physical Layer Operations, Administration and Maintenance) channel inside the frames is how the OLT discovers ONTs, assigns ONU-IDs, sends ranging results, requests and switches keys, and deactivates an ONT. A new ONT answers a serial number request, gets an ONU-ID, is ranged and only then enters service. Its serial number is eight bytes, a four byte vendor ID plus a four byte vendor specific number (G.984.3's Serial_Number_ONU message), often printed as four letters and eight hexadecimal characters.
What changed with XG-PON, XGS-PON and beyond
- XG-PON (G.987 series, 2010): about 10 Gbit/s down and 2.5 Gbit/s up.
- XGS-PON (G.9807.1, first edition June 2016, current February 2023, Amendment 1 May 2025): 9.95328 Gbit/s each way.
- NG-PON2 (G.989, October 2015): stacked wavelength pairs, defined in G.9804.1 as 40 Gbit/s down and 10 Gbit/s up.
- Higher speed PON and 50G-PON (G.9804 series, from November 2019): G.9804.1 asks for a symmetric option of about 50 Gbit/s to support a service rate of at least 40 Gbit/s, plus asymmetric 50/25 and 50/12.5 or 50/10 options.
Coexistence on the same fibre
Operators add a generation beside the old one on the same tree and move customers gradually, so each generation uses different wavelengths. G.9807.1 defines a basic set for XGS-PON that reuses XG-PON's bands (1575 to 1580 nm down, 1575 to 1581 nm outdoors, and 1260 to 1280 nm up) and an optional set that reuses GPON's (1480 to 1500 nm down, 1300 to 1320 nm up) for fibre that will not carry GPON at the same time. Because GPON's full 1260 to 1360 nm upstream would overlap, G.984.2 also lists a reduced GPON upstream of 1290 to 1330 nm, referencing G.984.5. With the basic set and older XG-PON ONTs present, the OLT must also serve the 10/2.5 rate on the same wavelengths.
A passive coexistence element, or a multi-PON optical module in the OLT port, merges generations onto the feeder. G.9804.1 requires the 50G generation to coexist with XG(S)-PON or GPON, and describes an option where all three share one tree.
The IEEE runs a parallel family of Ethernet PONs, which the Broadband Forum's TR-142 lists as 1G-EPON (802.3ah), 10G-EPON (802.3av) and 25G-EPON and 50G-EPON (802.3ca). Products sold as "25G PON" outside those families follow industry agreements, not an ITU-T recommendation, so check which specification a product follows.
A timeline of the standards
| Date | Document | What it did |
|---|---|---|
| October 1998 | ITU-T G.983.1 | BPON, the predecessor |
| March 2003 | ITU-T G.984.1 (first edition) | GPON general characteristics |
| February 2004 | ITU-T G.984.3 (first edition) | GPON TC layer, including AES security |
| June 2004 | ITU-T G.984.4 (first edition) | GPON OMCI |
| March 2008 | G.984.1 (current edition); BBF TR-142 Issue 1 | Updated GPON characteristics; TR-069 enabled PON devices |
| 2010 | ITU-T G.987.1, G.987.3; G.988 (October) | XG-PON; OMCI generalised for all ITU-T PONs |
| January 2014 | G.984.3 (current edition) | Enhanced security annex, PON-ID, power management |
| October 2015 | ITU-T G.989 | NG-PON2 definitions |
| June 2016 | ITU-T G.9807.1 (first edition) | XGS-PON |
| November 2017 | BBF TR-156 Issue 4 | GPON in TR-101 networks, extended to XGS-PON |
| November 2019 | ITU-T G.9804.1 | Higher speed PON requirements |
| 2021 | ITU-T G.9804.2, G.9804.3 | Higher speed PON TC layer; 50G-PON physical layer |
| November 2022 | G.988 (current edition) | OMCI, amended March 2024 and May 2025 |
| December 2022 | BBF TR-142 Issue 4 | CWMP and USP enabled PON devices |
| February 2023 | G.9807.1 (current edition) | XGS-PON, Amendment 1 May 2025 |
| November 2025 | G.984.3 Amendment 2 | Latest GPON TC amendment |
| January 2026 | BBF TR-369 Issue 1 Amendment 5 | Latest USP issue |
Dates come from the ITU-T recommendation pages and Broadband Forum documents in the sources; check each page's "In force" list before quoting a clause.
How downstream encryption works
The GPON threat model
Clause 12.1 of G.984.3 says the basic concern is that downstream data is broadcast to all ONUs, so a user who reprogrammed an ONU could listen to everyone's downstream. It calls this the "eavesdropping threat" and judges more exotic threats not worth an attacker's resources. It then notes that a PON is highly directional: no ONU can observe another's upstream, so privileged information, including keys, can go upstream in the clear. Tapping the shared fibre is dismissed as unrealistic, since it would happen in public spaces and probably disrupt the PON.
AES-128 in counter mode on GEM payloads
G.984.3 allows only AES in counter (CTR) mode, citing NIST guidance, with a 128 bit key. AES encrypts a sequence of counter values into a keystream that is XORed with the data. Both ends share a 46 bit crypto-counter built from the superframe counter in each frame header plus a position in the frame, so no counter value repeats while a key is in use, the one rule counter mode must never break. Only the GEM payload is encrypted; the header with its Port-ID stays clear so ONTs can filter without decrypting. Encryption happens before forward error correction and scrambling.
Key exchange over PLOAM
The OLT sends a Request_Key message. The ONT generates a key, which should be cryptographically unpredictable (G.984.3 points to FIPS 140-2), and returns it in an Encryption_Key message, in two halves, each sent three times. If the OLT cannot collect it after three attempts, it declares loss of key synchronisation and deactivates the ONT. Otherwise it picks a future frame number from which both sides switch to the new key. The ONT, not the OLT, generates the key because only upstream is private from the neighbours.
The enhanced security annex
The 2014 edition added optional Annex B. A compliant system holds a 128 bit pre-shared secret per ONU, at the ONU and on the operator side. Using G.988's Enhanced Security Control entity, OLT and ONT authenticate each other and derive a 128 bit master session key, and the ONT then encrypts the data key it sends upstream with AES-128 (ECB mode) under that key.
What GPON encryption does not protect
- Upstream in base GPON. Other ONTs cannot see it, but someone with access to the feeder fibre could.
- Headers and metadata. GEM headers, PLOAM messages and the bandwidth map stay clear and reveal which ports are active and how much each ONT sends.
- Multicast. In the TR-156 architecture a single GEM port carries multicast groups such as IPTV to all ONUs, and TR-156 states that GPON AES encryption is disabled on that multicast GEM port. TR-156 also describes configuring the OLT to carry multicast in AES encrypted per-ONT GEM ports for operators who want more.
- Anything past the OLT. From there traffic crosses the operator's network like any broadband traffic, so HTTPS and other end to end encryption still matter.
- Integrity. Base GPON has error detection codes but no cryptographic integrity check, and counter mode lets a flipped ciphertext bit flip the same plaintext bit.
- Whether it is on. Encryption is configured per GEM port by the operator; subscribers cannot see it.
What XGS-PON adds
G.9807.1 clause C.15 widens the threat model: forged upstream packets to impersonate another ONU, malicious devices attached at street cabinets, spare ports or cables that could impersonate an OLT or ONU, and replay or bit flipping. Because some deployments are physically secure, several features are optional. The toolkit:
- A master session key derived from the ONT's registration ID or from mutual authentication.
- AES-CMAC (NIST SP 800-38B) derived OMCI and PLOAM integrity keys, which sign management messages with a message integrity check (MIC), and a key encryption key that protects the data key in transit.
- XGEM payload encryption with AES-128 in counter mode on any unicast traffic, downstream and upstream, plus a broadcast key for a multicast stream. A two bit key index in each XGEM header marks the payload unencrypted or names one of two keys, so keys roll over without a gap. Per-port encryption, downstream only or both ways, is provisioned through OMCI.
G.988 includes PLOAM MIC and OMCI MIC error counters the OLT can read. A rising count is worth an alert.
What OMCI is and how the OLT configures the ONT
OMCI (ONU management and control interface) is ITU-T G.988; the current edition is November 2022, amended in March 2024 and May 2025. It is not reachable over IP: it runs inside the PON, on a dedicated GEM port, between the OLT and each ONT. It models the ONT as managed entities (MEs) that the OLT creates, reads, sets and deletes:
| Managed entity | What it represents | Why it matters |
|---|---|---|
| ONU-G and ONU2-G | The ONT: vendor, version, serial, LOID, capabilities, OMCI version | Inventory and authentication |
| T-CONT, GEM port network CTP | Upstream containers and GEM ports | Service mapping and per-port encryption |
| Software image | Each firmware slot | Version, committed, active and valid flags; download and activation |
| Virtual Ethernet interface point (VEIP) | Hand-off to a separate, non-OMCI management domain | Where the router side begins |
| BBF TR-069 management server | ACS address and credentials | Lets OMCI hand the router side its TR-069 server |
| Enhanced security control | Mutual authentication and key protection | Optional stronger authentication |
How firmware gets to the ONT
G.988 clause 9.1.4 is the part that matters most for supply chain security. An ONT keeps two software image instances. One is committed (boots next), one is active (running now). The OLT downloads into the inactive slot in sections, activates it and, once it works, commits it; if it fails, the old image is still there.
Two attributes deserve attention. An image is valid if verified to be executable, but "the verification mechanism is not subject to standardization"; it should include at least a data integrity check such as a CRC. The optional image hash is MD5. So OMCI standardises how firmware moves and which version runs, not a manufacturer signature check, and MD5 catches corrupted transfers, not deliberately altered images. Whether an ONT refuses unsigned firmware is a product feature and a procurement question.
Where TR-069 and TR-369 come in
A fibre box is often an ONT plus a residential gateway in one case. The Broadband Forum's TR-142 Issue 4 (December 2022) calls this an integrated PON CPE with two management domains: OMCI for the ONU entity, and CWMP (TR-069) or USP (TR-369) for the gateway. The U reference point divides them; in OMCI that boundary is the VEIP.
- TR-069 (CWMP), currently Amendment 6 Corrigendum 1 (June 2020), CWMP 1.4. The gateway opens sessions to the operator's auto configuration server (ACS). With an HTTPS ACS URL the CPE must use TLS, and should use TLS 1.2. The ACS triggers a call-in with a "connection request," a plain HTTP GET the CPE must authenticate with HTTP digest authentication. TR-069's signed package format for downloads is optional ("MAY").
- TR-369 (USP), latest Issue 1 Amendment 5 (January 2026). Controllers and agents talk over WebSocket, STOMP, MQTT or a UNIX domain socket (CoAP is obsolete). Before processing a controller's message, an agent must have that controller's (or a trusted broker's) certificate information and a cryptographically protected connection. Roles separate, for example, the operator's controller from household users.
Through the TR-069 management server ME, OMCI can give the ONT its ACS URL and credentials so a box picks up its router configuration on first connection; G.988 sets that ME's default state to locked. On an integrated box, the two sides may have different update channels, credentials and owning teams, so audit both.
How ONTs are authenticated, and what ONT spoofing is
Serial number. G.984.3 Appendix VI describes the simplest method: the operator pre-provisions the serial to subscriber mapping, or the OLT learns it at an earlier activation, optionally checked with a PLOAM password. TR-156 requires OLTs to support pre-provisioned serials (R-150) and to check a new serial against known ones (R-154). But a serial is not a secret: it is on the label and sent in the clear.
PLOAM password and registration ID. A registration ID is assigned to the subscriber, provisioned in the OLT and given to the installer or subscriber, who enters it into the ONT, where it fills the PLOAM password. The OLT can then learn the serial for later. Technicians can pick any ONT from the van. TR-156 requires the OLT to fall back to the registration ID for an unrecognised serial (R-155).
LOID and logical password. A third option lives in OMCI. G.988 gives the ONU-G entity two optional attributes: a Logical ONU ID (LOID, a text string of up to 24 bytes) and a logical password (up to 12 bytes), plus a credentials status the OLT sets to report success, an LOID error, a password error or a duplicate LOID. G.988 leaves how the LOID is entered out of scope, giving a web page as one example.
XGS-PON registration ID. Mandatory in every XGS-PON device, a 36 octet string kept in non-volatile storage. It authenticates the ONT to the OLT, one way only, and seeds the registration based session keys. G.9807.1 says a failed check does not stop ranging or management; what happens next is operator policy.
Secure mutual authentication. G.9807.1 defines two methods that authenticate both ends: OMCI based (Annex C.C) and IEEE 802.1X based (Annex C.D). Transmission convergence chips must support both, but equipment and operators may choose not to use them. On failure the OLT may retry, block traffic, deactivate the ONT or run rogue ONU diagnostics.
ONT spoofing
ONT spoofing means a device presenting another ONT's identity, usually its serial and sometimes its password, registration ID or LOID, so the OLT treats it as legitimate. Using another subscriber's identity or connecting unapproved equipment can breach the operator's terms or the law, and we do not cover how it is done. For defenders, the point is that identifiers sent in the clear can be copied, and in base GPON nothing cryptographically binds an identity to hardware. Operators can:
- Treat serials as inventory keys, not credentials, and require a registration ID, password or LOID as well.
- Enable mutual authentication where equipment supports it (G.984.3 Annex B; G.9807.1 Annexes C.C or C.D).
- Turn off automatic service activation for unknown ONTs on production ports, and alarm on unknown or duplicate serials and ONTs that move ports.
- Apply TR-156's OLT anti-spoofing controls: per-port MAC limits (R-121), IPv4 source checks against DHCP or configured addresses (R-119), gateway MAC spoofing protection (R-116) and the IPv6 equivalents (R-158).
- Watch MIC error counters and sharp changes in an ONT's optical levels.
GPON, XGS-PON, DOCSIS 3.1 and VDSL2 compared
| GPON | XGS-PON | DOCSIS 3.1 | VDSL2 | |
|---|---|---|---|---|
| Standard | ITU-T G.984 series | ITU-T G.9807.1 | CableLabs; ITU-T J series versions | ITU-T G.993.2 (current edition 02/2019) |
| Medium | Fibre, shared by splitter | Same fibre plant | Coax, shared on a node | Copper pair per line |
| Line rate | 2.48832 down, 1.24416 up (Gbit/s, per port) | 9.95328 both ways | Up to 10 Gbit/s down in the specification, much less up | Depends on loop length and profile; far lower than fibre on long lines |
| Field powered equipment | None | None | Amplifiers and nodes | Street cabinets in fibre to the cabinet builds |
| Link encryption | AES-128 CTR on GEM payloads; optional enhanced annex | AES-128 CTR both ways; CMAC integrity; optional mutual auth | BPI+ with certificates | Not in the line standard |
| Device management | OMCI plus TR-069 or USP | Same | Config file and SNMP, plus TR-069 or USP | TR-069 or USP on gateways |
| Who controls access device firmware | Operator | Operator | Operator | Operator for supplied gateways; you for your own modem |
On every one of these, the operator decides which firmware the access device runs. The device you fully control is the router behind it.
Step by step: what a home user can check and do
Everything here is about equipment you own. Do not log in to, reconfigure or replace an ISP-supplied ONT or gateway without the ISP's permission; it is their equipment, and their terms and local law apply.
Step 1: identify your ONT
Find the box where the fibre enters. The label shows a model, a serial (often four letters plus eight hexadecimal characters for GPON) and LEDs such as PON and LOS. A steady PON light means it has ranged and is in service; a red or flashing LOS light means no light is arriving. Note the model and serial for support calls, but do not post them publicly: the serial is one of the identifiers an OLT may use to recognise your line.
Step 2: work out whether your ONT and router are separate
Common setups are a separate ONT plus a router, an integrated ONT and router (TR-142's integrated PON CPE), or an ONT module plugged into a router. Count the routers between you and the internet:
# Linux or macOS: show the first few hops to a public resolver
traceroute -n -m 4 1.1.1.1
# Windows
tracert -d -h 4 1.1.1.1
If hop 1 is your router (for example 192.168.1.1) and hop 2 is another private address, an ISP gateway is doing NAT in front of yours. If hop 2 is public or in the carrier grade NAT range 100.64.0.0/10, your router is the only one at home.
Step 3: keep the ISP CPE updated the supported way
The operator pushes ONT firmware through OMCI. Ask which version you run and how often it is updated, and ask for a swap if your model is out of support. If you may use the gateway's web interface, change the default password and disable WAN side administration where allowed. CISA's January 31, 2024 Secure by Design alert urges router makers to put web management on LAN side ports only and to automate updates.
A dated example shows why the router software matters. NVD published CVE-2018-10561 on 4 May 2018: an authentication bypass in the web interface of one manufacturer's GPON home routers. CISA added it to its Known Exploited Vulnerabilities catalog on 31 March 2022. The flaw was in the router's web interface, not the GPON protocol.
Step 4: put your own firewall behind it
If the ISP gateway offers bridge mode or IP passthrough and allows it, use it so your own router holds the public address. Either way, your router protects your devices. On an OpenWrt router, check the build and pending updates:
# Show the build and target
ubus call system board
# Refresh package lists and list upgradable packages (releases that use opkg;
# if your release uses a different package manager, use its equivalent commands)
opkg update
opkg list-upgradable
On a Linux firewall, a minimal nftables policy that drops unsolicited inbound traffic on the WAN interface (rename wan0 to yours):
sudo tee /etc/nftables.conf > /dev/null <<'EOF'
flush ruleset
table inet filter {
chain input {
type filter hook input priority 0; policy drop;
iif "lo" accept
ct state established,related accept
ct state invalid drop
iifname != "wan0" accept
ip protocol icmp icmp type { echo-request, destination-unreachable, time-exceeded } limit rate 10/second accept
ip6 nexthdr icmpv6 accept
}
chain forward {
type filter hook forward priority 0; policy drop;
ct state established,related accept
ct state invalid drop
iifname != "wan0" oifname "wan0" accept
}
}
EOF
sudo nft -c -f /etc/nftables.conf && sudo systemctl enable --now nftables
nft -c checks syntax before loading. ICMPv6 is accepted because IPv6 neighbour discovery and path MTU discovery need it. Then, from outside your network (a phone hotspot works), scan only your own address:
# Find your public IPv4 address from inside your network
curl -4 https://ifconfig.me
# From outside your network, scan only that address
nmap -Pn --top-ports 200 YOUR.PUBLIC.IP.HERE
Only scan addresses you own or may test. On most home connections, no ports should be open.
Step 5: segment and turn off what you do not use
Turn off UPnP unless a device needs it, put smart home devices and guests on separate networks, confirm your router's IPv6 firewall is on and update every device behind the router. Our home router security checklist for remote developers goes further.
What ISP operators should audit
The OLT management plane
The OLT controls every ONT, holds keys and pushes firmware. Treat it like a core router:
- Management (CLI, NETCONF, SNMP, element management system) only on an out of band network or management VRF, verified from outside.
- SSH, NETCONF over SSH, SNMPv3 with authentication and privacy, TLS for web interfaces; Telnet, HTTP and SNMPv1 or v2c off.
- Per-person accounts via TACACS+ or RADIUS with command logging; no shared admin passwords.
- Alarms to a SIEM: unknown serials, ONTs on new ports, loss of key synchronisation, MIC errors, rogue ONU detection.
- OLT software tracked against vendor advisories, configuration in version control and diffed after every change.
Provisioning policy
Pre-provision serials and registration IDs, enable AES on every unicast GEM or XGEM port (and upstream on XGS-PON where supported), decide in writing whether new equipment must support GPON Annex B or XGS-PON mutual authentication, and apply TR-156's anti-spoofing controls.
The ONT firmware supply chain and inventory
ONT and gateway images are embedded Linux builds: bootloader, kernel, BusyBox, web server, TR-069 or USP agent, voice stack and vendor SDK. Ask every supplier:
- Is every image signed, and does the ONT reject images that fail the check, whether delivered over OMCI, TR-069 or local upload? G.988 only requires an integrity check.
- Will you ship a software bill of materials (CycloneDX or SPDX) with every release, and how fast do you fix vulnerable components?
- How long will each model get security updates?
Then reconcile what is running. Read the software image version through your element management system, export it as CSV and compare against an approved list:
#!/usr/bin/env python3
"""Flag ONTs running firmware that is not on the approved list for their model.
Usage: python3 ont_firmware_check.py ont_inventory.csv approved_firmware.csv
ont_inventory.csv: serial,model,active_version
approved_firmware.csv: model,approved_version
"""
import csv
import sys
from collections import Counter, defaultdict
def load_approved(path):
approved = defaultdict(set)
with open(path, newline="") as f:
for row in csv.DictReader(f):
approved[row["model"].strip()].add(row["approved_version"].strip())
return approved
def main(inventory_path, approved_path):
approved = load_approved(approved_path)
off_list = Counter()
unknown_models = Counter()
with open(inventory_path, newline="") as f:
for row in csv.DictReader(f):
model = row["model"].strip()
version = row["active_version"].strip()
if model not in approved:
unknown_models[model] += 1
elif version not in approved[model]:
off_list[(model, version)] += 1
for (model, version), count in off_list.most_common():
print(f"OFF-LIST {model:20} {version:24} {count} ONTs")
for model, count in unknown_models.most_common():
print(f"UNKNOWN {model:20} {'(no approved list)':24} {count} ONTs")
return 1 if off_list or unknown_models else 0
if __name__ == "__main__":
sys.exit(main(sys.argv[1], sys.argv[2]))
Models with no approved list are often the riskiest, because nobody owns them. Use G.988's two image slots for staged rollouts: pilot group first, commit only after a clean pilot, then roll out by OLT or region with the previous image available.
Common mistakes
- Treating the GEM Port-ID filter as privacy. Without AES on the port, a reprogrammed ONT can read its neighbours' downstream.
- Leaving unicast ports unencrypted by default. TR-156 disables AES on the multicast GEM port by design; unicast ports should be encrypted.
- Using the serial number as a credential. It is printed on the box and sent in the clear.
- Automatically activating unknown ONTs on production ports. Convenient for installers, and for anyone with a spoofed ONT.
- Assuming OMCI firmware upgrades are signed. G.988 standardises transfer and an optional MD5 hash, not signatures.
- Auditing only one management domain. Integrated CPE needs both the OMCI side and the TR-069 or USP side covered.
- Exposing gateway management to the WAN. Keep it on the LAN side and the operator's management network.
- Forgetting the router behind the ONT. For subscribers, that is where most of the risk and most of the options are.
FAQ
What is the difference between GPON and XGS-PON?
GPON (ITU-T G.984) runs at about 2.5 Gbit/s down and 1.25 Gbit/s up per port. XGS-PON (G.9807.1) runs at about 10 Gbit/s both ways and adds integrity checks on management messages and optional mutual authentication. Both use the same passive fibre and can share a tree on different wavelengths.
What is an OLT?
The optical line terminal in the operator's exchange sends downstream, schedules upstream time slots, runs ranging, manages keys and configures ONTs through OMCI. Each of its PON ports serves one splitter tree.
How many homes share one GPON port?
Typically 32 to 64. G.984.1 calls up to 1:64 realistic for the physical layer and has the protocol layer handle 1:128. XGS-PON makes 1:64 the minimum and allows 1:128 or 1:256 if the optical budget permits.
Is GPON traffic encrypted?
Downstream user traffic is normally encrypted per ONT with AES-128 on GEM payloads. In base GPON the key travels upstream in the clear; an optional annex protects it with a pre-shared secret. XGS-PON can also encrypt upstream and protects keys and management messages. Encryption ends at the OLT.
What is OMCI in GPON?
OMCI (ITU-T G.988) is the protocol the OLT uses to configure an ONT over a dedicated channel inside the PON. It models interfaces, traffic containers, GEM ports, credentials and firmware images as managed entities, and it is how operators upgrade ONT firmware.
What is a LOID on a fibre ONT?
A Logical ONU ID, an optional ONU-G attribute in ITU-T G.988 of up to 24 bytes, often paired with a logical password of up to 12 bytes. The OLT can use it to recognise a subscriber's ONT and reports LOID errors or duplicates through a credentials status attribute.
Can I use my own ONT or router on a fibre connection?
A router behind the ONT is almost always your choice. Replacing the ONT depends on the operator, which must provision it on its OLT and manages its firmware. Ask your ISP, and never copy another device's serial or credentials.
What is the difference between TR-069 and OMCI?
OMCI manages the PON side from the OLT, inside the fibre network. TR-069 (CWMP) and its successor TR-369 (USP) manage the router side over IP from an operator server. On integrated gateways both run on one box, split at the U reference point.
Where Safeguard fits
The fit here is indirect. Safeguard does not scan ONT or OLT firmware, inspect PON traffic or manage routers, gateways or other endpoints; ONT images are closed builds the operator and manufacturer control. Safeguard helps with the software teams build around a fibre network: provisioning and inventory tools that drive an element management system, TR-069 or USP controller code, a reconciliation script like the one above, OLT alarm exporters or a home lab firewall generator. It 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.
The OLT and ONT must be fixed by their vendor and operator, but the tools, controllers and monitoring code around them, and the router software behind the ONT, ship open source components. Those you can keep current yourself, as the standard Safeguard remediation guide below covers.
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.
| Your situation | What to use |
|---|---|
| A fixed version exists | Autonomous remediation opens the upgrade pull request; Gold Open Source confirms the safe version |
| You need to know today whether you are affected | Gold Open Source lookup and "Am I affected?" checker, free and without login |
| You want vulnerable versions to stop shipping | The Gold scan GitHub Action in CI, plus Safeguard policies and gates |
| Upstream has no fix yet, or will not ship one | A custom Gold request; fork and patch (early access) |
| You want to start clean on new projects | Pull hardened components and images from Gold Registry |
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 Safeguard CLI session: 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 in an ONT inventory script, a USP controller or an OLT alarm 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 scans from the terminal. Access network tooling often lives on a management host inside the operator's network, and the runner scans 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 OLT management on its own network.
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
In base GPON, why does the ONT send its encryption key upstream in the clear?
Because G.984.3 assumes the PON is highly directional: other ONTs cannot see upstream light, while anything sent downstream reaches every ONT. The optional Annex B encrypts the key with a session key derived from a pre-shared secret, and XGS-PON protects it with a key encryption key.
An ONT reports its software image as valid. Does that mean the firmware was signed by the manufacturer?
Not necessarily. G.988 says the verification mechanism is not standardised and should include at least a data integrity check such as a CRC. Signature checking is a manufacturer feature, so operators should confirm it with each supplier.
Sources
- ITU-T G.983.1: Broadband optical access systems based on PON
- ITU-T G.984.1: GPON general characteristics
- ITU-T G.984.2: G-PON physical media dependent layer
- ITU-T G.984.3: G-PON transmission convergence layer
- ITU-T G.984.4: G-PON ONT management and control interface
- ITU-T G.987.1: XG-PON general requirements
- ITU-T G.987.3: XG-PON transmission convergence layer
- ITU-T G.9807.1: XGS-PON
- ITU-T G.988: ONU management and control interface (OMCI)
- ITU-T G.989: NG-PON2 definitions
- ITU-T G.9804.1: Higher speed PON requirements
- ITU-T G.9804.2: Higher speed PON common transmission convergence layer
- ITU-T G.9804.3: 50G-PON physical media dependent layer
- ITU-T G.993.2: VDSL2
- Broadband Forum TR-156 Issue 4 (November 2017), PDF
- Broadband Forum TR-142 Issue 4 (December 2022), PDF
- Broadband Forum TR-069 Amendment 6 Corrigendum 1 (June 2020), PDF
- Broadband Forum TR-369: The User Services Platform
- NIST SP 800-38A: Block Cipher Modes of Operation
- NIST SP 800-38B: The CMAC Mode for Authentication
- NVD: CVE-2018-10561
- CISA: Secure by Design Alert for SOHO Device Manufacturers (January 31, 2024)
- CISA: Home Network Security
Related reading: How a home router is made, How optical transceivers are made, DOCSIS explained and the home router security checklist for remote developers.
Last reviewed: 24 October 2026. ITU-T and the Broadband Forum amend these documents regularly; check the in force editions on the ITU-T recommendation pages and your operator's or supplier's documentation before relying on a specific value.