TR-369 (USP) in production: a study of what actually works in 2026

TR-369, the User Services Platform (USP), was released by the Broadband Forum in 2018 as the successor to the venerable TR-069 (CWMP). Six years on, USP is unquestionably the future of CPE management — but "the future" and "in production" are two different states. This is a plain-language field study of where USP stands in real ISP deployments in 2026: which transports have won, which agents ship USP support, and where the operational sharp edges still are.

For the standards themselves, we recommend reading the primary sources: the [Broadband Forum USP specification page](https://usp.technology/) is the authoritative index, and [TR-369 Amendment 3](https://www.broadband-forum.org/technical/download/TR-369.pdf) is the current baseline. The purpose of this post is not to duplicate the spec — it is to describe what we have seen operators actually do with it.

What USP changes, in three sentences

First, communication moves from long-polled HTTP with periodic informs (CWMP) to persistent, message-oriented transports — MQTT and WebSocket are the two that matter. Second, the data model formally splits into a device-facing agent and a controller-facing message bus, so an operator can have multiple controllers over the same fleet (device vendor + ISP + third-party analytics all coexisting). Third, notifications become first-class events instead of counter-polling exercises.

What actually ships in 2026

The controller landscape

Controllers — the ACS in TR-069 vocabulary — are the piece that has taken longest to mature. Open-source [OB-USP-AGENT](https://github.com/BroadbandForum/obuspa) is the reference agent implementation and is production-grade; the controller side is thinner. In practice, most ISPs today run either a legacy TR-069 server extended for USP (Netxol NMM does this natively — see [Netxol's TR-069/TR-369 solution page](/solutions/tr-069-acs)) or a vendor-proprietary controller from their CPE vendor.

The Netxol ACS implements CWMP and USP with MQTT and WebSocket transports on the same server, so operators can migrate CPE from CWMP to USP at their own pace without running two servers. This is documented in the [Netxol NMM module page](/products/modules/nmm).

The three real sharp edges

1. 1MQTT broker selection is not covered by the standard, and it matters. We have seen operators pick a general-purpose broker (Mosquitto, EMQX, HiveMQ) and hit scaling walls at 100K+ persistent connections. Netxol embeds a broker sized to the Core appliance tier so operators do not carry that decision.
2. 2TLS certificate rotation on the CPE is under-specified in every deployment we have seen. Operators end up building bespoke rotation flows. The USP spec covers certificate use but leaves operational rotation to implementers.
3. 3Multi-controller policies are a paper feature until you actually enable them. Most vendor agents technically support the "multiple controllers over one agent" USP model, but the policy engine to decide which controller wins a given operation is thin. Expect to standardise on one controller in the medium term.

The commercial takeaway for an FTTH operator today

If you are procuring CPE in 2026, USP-with-CWMP-fallback is now table stakes — refuse CPE that ships CWMP-only unless the price gap is decisive. On the controller side, treat USP as a required capability of your ACS but do not assume you will run USP-only anytime this decade: the installed base of TR-069-only CPE ages out slowly.