Most people think the relationship between their router and Openreach ends at the line test. You call your ISP, a technician runs a sync check, maybe logs a noise margin, and that’s it. I’d argue that picture is about ten years out of date. The diagnostic and telemetry infrastructure running beneath modern FTTP and VDSL deployments is considerably more granular than anything BT’s PR team would volunteer in a press release, and the metadata it generates tells a story that goes well beyond “the line dropped at 02:14.”
This isn’t about paranoia. It’s about understanding what’s actually being collected, where it flows, and what can be inferred from it once you aggregate enough of it. That last part is where things get genuinely interesting.
What the ONT and DSLAM are actually logging
On an FTTP connection, the Optical Network Terminal (ONT) sitting on your wall is not a dumb passive device. It’s running firmware maintained by Openreach (usually supplied by Nokia, Adtran, or Huawei depending on the rollout wave), and it exchanges management traffic continuously with the Optical Line Terminal (OLT) at the local exchange or cabinet. That management plane uses OMCI (ONT Management and Control Interface) as defined in ITU-T G.988, and the volume of data passing over it is not trivial.
OMCI carries performance monitoring data on a 15-minute interval by default: upstream and downstream optical power levels, bit error rates, FEC correction counts, packet loss counters per GEM port, and PHY-layer frame statistics. On a VDSL2 or G.fast connection, the equivalent lives in the DSLAM’s line management daemon, pulling vectoring coefficients, SNR margins per sub-carrier (all 512 or 3479 of them on a full G.fast profile), and retransmission events via VDSL2’s G.998.4 protocol. Openreach’s NMS (Network Management System) pulls these at regular intervals. The telemetry doesn’t wait for a fault; it’s continuous.
What does that give you? At a minimum: precise timestamps for every sync event, every optical power fluctuation, and every period of elevated retransmission. That’s already a reasonably detailed activity fingerprint. Your router restarting at 07:23 every morning because someone hits the power strip is in there. The three-hour window each weekday afternoon where your SNR margin tanks because a neighbour’s amateur radio kit fires up is in there. Cross-reference enough subscribers on the same cabinet and you start building behavioural profiles that nobody signed a consent form for.
TR-069 and the management channel nobody reads the T&Cs for
Below the physical layer sits the application-layer management protocol most people have genuinely never heard of: TR-069, also known as CWMP (CPE WAN Management Protocol). If your ISP-supplied router is provisioned by BT, Sky, Vodafone, or any of the major UK retailers on the Openreach network, there is almost certainly a TR-069 ACS (Auto Configuration Server) calling home on a schedule your router’s admin interface won’t fully expose.
TR-069 was designed for remote provisioning, firmware updates, and diagnostics. In practice it does all of that, but the data model it exposes (standardised as TR-181 or the older TR-098) includes parameters that go considerably further than line stats. The ACS can query active LAN-side device counts, DHCP lease tables, connected SSID client lists, current WAN IP assignment, DNS query rates, and UPnP-mapped port entries. Whether an ISP’s ACS actually polls all of those parameters depends on their configuration, but the capability is baked into every TR-069-compliant CPE. I’ve looked at the exposed data model on several Openreach-provisioned routers by querying the local admin interface, and the TR-181 device tree is extensive.
The ACS server sits inside the ISP’s infrastructure rather than Openreach’s directly, but Openreach’s own systems can query fault-related telemetry through what BT refers to internally as the Broadband Service Operations Centre (BSOC) tooling. The practical separation between “ISP-side” and “Openreach-side” visibility is thinner than consumer-facing documentation implies, because Openreach is both the network operator and the wholesale supplier to those same ISPs, with shared fault-management APIs pulling from common data stores.
What the metadata actually reveals about you
Here’s the part that should make any technically literate person sit up. Individual data points from FTTP telemetry are mundane. Aggregated over time and correlated, they’re not.
Sync event timestamps give you wake/sleep patterns if the router is in a room with a smart power strip, or show occupancy rhythms if people habitually shut their router off overnight. Upstream traffic bursts at specific times, visible through GEM port counters even without DPI, correlate strongly with video calling, gaming sessions, or large uploads. Connected device counts from TR-069 LAN queries change as people come and go. SNR degradation patterns on a cabinet can flag environmental changes (building work, electrical interference) but also map to physical access patterns in shared premises.
None of this requires packet inspection. It’s all metadata. And metadata at scale has a well-documented history of being more revealing than the content it describes. The NCSC’s own guidance on logging for security purposes acknowledges that metadata aggregation is a primary intelligence technique precisely because of how much can be inferred from timing and volume patterns alone.
I’d draw a direct parallel here to the way TfL and train operators harvest behavioural data through Oyster and contactless tap patterns. The mechanism is different but the inference model is structurally similar: timestamp sequences plus identifiers plus location or context equals a behavioural profile nobody explicitly consented to create.
Where the data flows and who can touch it
Openreach’s network management infrastructure runs across multiple data centres, with NMS platforms that have been progressively consolidated as FTTP rollout accelerated. Wholesale ISPs access fault data through Openreach’s Wholesale Broadband Connect (WBC) portals and their B2B APIs. Law enforcement requests for subscriber metadata go through BT Group’s Legal Intercept team under RIPA/IPA frameworks, but the telemetry data held by Openreach itself sits in a slightly grey zone: it’s not communications content, so the Investigatory Powers Act’s stricter warrant requirements don’t automatically apply to all of it.
Retention periods for operational telemetry aren’t publicly documented in a way that would satisfy an ICO audit in my view, and Openreach’s privacy notices are written at a level of generality that makes it difficult to establish exactly how long 15-minute OMCI performance monitoring intervals are kept before aggregation or deletion. Under UK GDPR, legitimate interest processing for network management is a valid basis, but proportionality of retention is a genuine question. The ICO has the jurisdiction to investigate, though broadband network telemetry hasn’t been a public enforcement priority.
This sits in similar territory to the concerns around telematics black boxes in vehicles, where the data collected for a stated operational purpose (fault detection / safe driving scoring) contains far more inferential richness than the stated purpose requires. In both cases, the secondary use question is the one that never quite gets answered in the T&Cs.
The firmware attack surface on ONTs
Separate from the data governance questions, the diagnostic infrastructure creates a concrete security surface. ONT firmware from vendors like Nokia (formerly Alcatel-Lucent) and Adtran receives updates pushed over the OMCI management channel. Openreach controls the update schedule. The authentication mechanism for firmware delivery is not publicly documented at a level that would let independent researchers verify its integrity, which should give pause.
A compromised update delivery pipeline is a worst-case scenario, but a realistic one. If you want a parallel for how that can go wrong, look at the OTA firmware vulnerabilities researchers have been documenting in vehicle CAN bus systems. The attack vector pattern is the same: a management channel with privileged access to physical hardware, over-the-air update capability, and limited external auditability. The ONT sits between the public fibre network and your home LAN. That’s a position of significant trust.
Local access to ONT management interfaces is another angle. Some Nokia ONT models expose a local HTTP management interface on the WAN-facing side with credentials that are either default or derivable from the serial number. Openreach has pushed firmware updates to close some of these, but the attack surface changes with each hardware generation and the rollout of new ONT variants during FTTP expansion means older, less-patched units are in service for extended periods.
What you can actually do about it
Realistically, if you’re on the Openreach network, you cannot opt out of ONT telemetry. The management plane is not optional; it’s how the network functions. You can, however, put your own router behind the ISP-supplied CPE and disable TR-069 polling if your ISP allows it, which some do. Using a third-party router (not provisioned by the ISP’s ACS) removes most of the LAN-side data exposure, though it doesn’t touch the physical-layer telemetry from the ONT itself.
Using a VPN removes the content layer from ISP visibility, but it doesn’t obscure the timing and volume metadata that the telemetry infrastructure captures. If you genuinely want to understand the full scope of what your connection is reporting, running a packet capture on the management VLAN (if your ISP’s configuration allows you to see it) is the closest thing to ground truth. Most people won’t, and that asymmetry of knowledge between subscriber and network operator is, in my view, precisely what needs more public scrutiny.
The telemetry infrastructure inside UK broadband isn’t secret, but the aggregate picture of what it knows about you has never been clearly explained to the 12+ million premises Openreach now passes with FTTP. That gap between technical reality and public understanding is where the interesting questions live.
Frequently Asked Questions
What is TR-069 and does my Openreach router use it?
TR-069 (CWMP) is a remote management protocol that allows ISPs to configure, update, and query your router without local access. If you have an ISP-supplied router on the Openreach network (BT, Sky, Vodafone, etc.), it almost certainly runs TR-069. The ISP’s Auto Configuration Server polls the router periodically for diagnostics, device counts, and configuration state.
Can Openreach see what websites I visit through telemetry data?
Openreach’s physical-layer telemetry does not involve deep packet inspection and does not capture URL-level browsing data. However, the metadata it collects, including traffic volume, timing patterns, and sync events, can be used to infer behavioural patterns without ever reading actual content. A VPN removes ISP-level content visibility but does not hide timing or volume metadata from the network infrastructure.
How long does Openreach keep broadband telemetry data?
Openreach does not publicly document specific retention periods for operational telemetry like OMCI performance monitoring intervals. Under UK GDPR, data processed for legitimate network management purposes must be kept no longer than necessary, but the proportionality of Openreach’s actual retention schedules has not been publicly tested by the ICO. You can submit a Subject Access Request to BT Group to request information about data held about your line.
What is an ONT and can it be hacked?
An ONT (Optical Network Terminal) is the device Openreach installs at your premises to terminate the fibre connection. It runs firmware from vendors like Nokia or Adtran and has a management channel controlled by Openreach. Some ONT models have had local management interface vulnerabilities that expose default or derivable credentials, and firmware is delivered over the OMCI management channel with limited independent auditability.