# How is TR-369 secured? TLS, end-to-end encryption, certificates and roles Dodderware engineering team · Published 2026-10-28 · https://blog.dodderware.com/tr-369-security/ [Leer en español](https://blog.dodderware.com/es/seguridad-tr-369/) > **Short answer:** TR-369 secures USP at three levels. Each Message Transfer Protocol must use secure transport, normally TLS, when traffic crosses network boundaries. When brokers or proxies sit in the path, Secure Message Exchange can run TLS inside USP Records between the two Endpoints. And every Controller is authenticated and given a Role, whose rwxn permissions the Agent checks before acting on a Message. An Agent on a customer’s ONT will reboot, change Wi-Fi settings or download firmware when a Controller asks. So TR-369 spends a whole section on who that Controller is and what it may touch. This guide walks through how USP protects the channel, the Message and the data model, with the requirement behind each step. ## Where does USP put its security? Because USP links components that may also speak protocols outside its scope, “security must be considered from end-to-end”, so USP “contains its own security mechanisms” (§1.6.2). The architecture lists them as separate building blocks: MTP security, “a system for end-to-end confidentiality, integrity and identity authentication”, and access control on a per element basis (§2). Communication between Endpoints is secured by the MTP, by a USP Session Context, or both (§2.1). The [TR-369 overview](https://blog.dodderware.com/what-is-tr-369/) shows where these sit in the protocol. 1. **TLS handshake** (MTP): The Agent requires an X.509 certificate from its peer. 2. **Certificate checked** (Authentication): The Endpoint ID in the certificate must match the Record’s from_id. 3. **Role determined** (Authorization): Assigned, inherited from a trusted CA, or untrusted on first use. 4. **Permission check** (Every Message): The Role must allow the action before the Agent performs it. *What an Agent checks before it acts on a Controller’s Message. Diagram by Dodderware, based on TR-369 §4.1.2, §8.1, §8.8 and §8.9.* ## What does TLS protect on the MTP? R-MTP.0 requires secure transport “when USP Messages cross inter-network boundaries”, and MTPs that run over TCP are expected to implement at least TLS 1.2 (§4.1.2). Three rules shape how an Agent uses it: - **The peer shows a certificate.** When TLS secures an MTP, the Agent must require an X.509 certificate (R-MTP.1). - **The certificate names the Endpoint.** It carries the Endpoint ID in its subjectAltName extension, and Records whose `from_id` does not match must not be processed (R-SEC.0a). Endpoint IDs are explained in [USP Agent vs Controller](https://blog.dodderware.com/usp-agent-vs-controller/). - **Clocks matter.** An Agent that can obtain absolute time should wait for it before setting up TLS. If it connects without it, it must ignore the certificate’s validity dates, and once it has accurate time it must check them (R-MTP.2, R-MTP.3). The specification also recommends that Agents encrypt all MTPs, “enable it by default, and not implement the ability to disable it” (§8.1). Each binding’s TLS rules are in [USP transports compared](https://blog.dodderware.com/usp-mtp-websocket-mqtt-stomp/). ## When is MTP encryption not enough? When something sits in the middle. If the MTP connection runs directly between Agent and Controller, MTP encryption “is sufficient to provide end-to-end encryption and security” (§8). If a proxy or broker sits between them, USP-layer End to End Message Exchange is required, “or the intermediate device must be a trusted part of the end-to-end ecosystem” (§8). That trusted intermediary is a **Trusted Broker**: it makes sure the `from_id` of each brokered Record matches the Endpoint’s certificate or credentials, or it belongs to a closed ecosystem whose Endpoints can be trusted not to spoof their IDs (§1.4). It must authenticate every client with a unique client certificate and make sure their communication cannot be forwarded to another party (R-SEC.4b). And it “MUST NOT inspect USP payloads contained in USP Records” (R-SEC.4c). When the MTP does not protect a Record, the sender must still protect the integrity of its non-payload fields (R-E2E.29), with an ECDSA P-256 signature or, once a TLS session exists, an HMAC based on SHA-256 (§6.3). ## How does end-to-end Secure Message Exchange work? Broker-based transports and proxies are why it exists: bindings only secure each hop (§6.4). The originating Endpoint secures the payload before segmentation and transmission, and the receiving Endpoint decrypts it after reassembly (§6.4). The Record’s `payload_security` field says how: `PLAINTEXT` or `TLS12`, meaning TLS 1.2 or later (§4.1.3.1). The TLS handshake itself travels inside USP Records, so Endpoints using `TLS12` must exchange Records within an E2E Session Context (R-E2E.41). The Endpoint that started the Session Context acts as TLS client, and a new TLS session takes two round trips (§6.4.1.1). | Requirement | What it demands | | -------------------- | ----------------------------------------------------------------------------------------------------- | | R-E2E.40 | TLS 1.2 or later, `ECDHE-ECDSA-AES128-GCM-SHA256` for TLS 1.2 and `TLS-AES128-GCM-SHA256` for TLS 1.3 | | R-E2E.40a, R-E2E.40b | ECDHE key exchange with the NIST P-256 curve, ECDSA signatures with P-256 and SHA-256 | | R-E2E.42 | No TLS renegotiation | | R-E2E.43 | Mutual authentication with X.509 certificates | ## How does an Agent decide to trust a Controller? Controllers are authenticated with X.509 certificates, or with shared secrets on a UNIX domain socket MTP (§8.1). Before processing a Controller’s Message, the Agent must hold that Controller’s certificate information, or a Trusted Broker’s, and have a cryptographically protected connection to it (R-SEC.0). Then it works out the Role: - **Trusted Certificate Authorities.** The Agent can trust a CA only to vouch for a Controller’s identity, or also to grant a Role that the Controller inherits (§8.3, §8.9.2.4). Stored CA information includes at least a fingerprint and its algorithm (R-SEC.2). - **Self-signed certificates and TOFU.** Accepting them is Agent policy. If allowed, the Controller gets an “untrusted” Role on first use (R-SEC.6): the Agent trusts the certificate for encryption but will “heavily restrict what the Controller is authorized to do” (§8.5). The Agent must remember which certificate goes with which Endpoint ID, or every use becomes a first use (R-SEC.8, §8.5). - **Challenges.** A passphrase or PIN, printed on the packaging for example, can raise a Controller’s Role. A factory-default value must be unique to the Agent, not derivable from what it reveals, and tries must be limited (§8.7, R-SEC.14 to R-SEC.16). An Agent must clear all cached encryption sessions and Role authorizations when it reboots (R-SEC.21). ## How do Controllers authenticate Agents? Controllers must authenticate Agents with X.509 certificates, a shared secret, or a Trusted Broker that vouches for them (R-SEC.9). Shared secrets that are not unique per device “are not recommended”, and neither is one certificate shared by several Agents through a wildcarded Endpoint ID, which Controllers need not support (§8.6, R-SEC.11). For self-signed Agent certificates, the choice is the Controller’s: refuse them, let a person approve each Agent, or accept them automatically (§8.5). > **Where DWS Support fits** > > DWS Support’s USP controller handles Agent certificates in Strict or Trust-On-First-Use mode, with an approval > workflow in the console where an administrator accepts or rejects them. For the people using the console, roles are > built from per-action permissions such as reboot or factory reset, and every device command is recorded. > > [See DWS Support](https://dodderware.com/products/dws-support/) ## What can a Controller do once it is trusted? A Role is the set of permissions, an access control list, that an Agent grants a Controller over its Instantiated Data Model (§1.4). The Agent must confirm those permissions before performing any action in a Message (R-SEC.1), and the error for a refusal is 7006 “Permission denied” (§7.8). Roles live in `Device.LocalAgent.ControllerTrust.Role.` entries. Each Permission entry names its Targets (the Path Names it covers), an Order, and four permission strings: Param, Obj, InstantiatedObj and CommandEvent (§8.9.2.1). Each string has four characters, always in the order `rwxn`, for Read, Write, Execute and Notify, with a dash for each missing one. The specification’s example grants full access, then takes back the trust settings (Param lines shown): ```text Device.LocalAgent.ControllerTrust.Role.1.Permission.1.Order = 1 Device.LocalAgent.ControllerTrust.Role.1.Permission.1.Targets = Device Device.LocalAgent.ControllerTrust.Role.1.Permission.1.Param = rwxn Device.LocalAgent.ControllerTrust.Role.1.Permission.2.Order = 2 Device.LocalAgent.ControllerTrust.Role.1.Permission.2.Targets = Device.LocalAgent.ControllerTrust Device.LocalAgent.ControllerTrust.Role.1.Permission.2.Param = ---- ``` Within one Role, the entry with the larger Order wins where Targets overlap. Across Roles, permissions add up, so `r---` and `---n` give `r--n` (§8.9.2.3). Three special Roles have fixed jobs (§8.9.2.2): `UntrustedRole` for any Controller not yet authorized for another Role, `BannedRole` for revoked certificates, and `SecuredRoles` for Controllers allowed to read secured Parameters. Any other Controller reads those as a null value, such as an empty string. Agents should also expose each Controller’s `AssignedRole` and `InheritedRole`, so users can spot rogue Controllers (R-SEC.1a). > **Did you know?** > > Permissions also hide what exists. If a Controller lacks Read permission on an Object or Parameter, the Agent treats it > as if it were not in its Supported Data Model (R-GET.1). The specification calls this “intended to act as a security > feature”: a Controller that cannot list an Object’s elements should not discover them by probing with Get (§7.5.1). ## Did you know? - An Agent that accepts a self-signed Controller certificate must give that Controller an “untrusted” Role on first use. (TR-369 §8.5, R-SEC.6) - A Trusted Broker vouches for the identity of the Endpoints it carries, yet it must not inspect the USP payloads in their Records. (TR-369 §8.4, R-SEC.4c) - Permissions are written as four characters, rwxn, for Read, Write, Execute and Notify, with a dash for each one a Role lacks. (TR-369 §8.9.2.1) - An Agent that connects before it has accurate time must ignore the validity dates in the certificate it receives. (TR-369 §4.1.2, R-MTP.2) - End-to-end Secure Message Exchange forbids TLS renegotiation. (TR-369 §6.4.1.1, R-E2E.42) ## Questions people ask ### Does TR-369 require TLS? An MTP must use secure transport when USP Messages cross inter-network boundaries, and MTPs over TCP are expected to implement at least TLS 1.2 (R-MTP.0, §4.1.2). Inside a LAN it may not be necessary. When TLS is used, the Agent must require an X.509 certificate from its peer (R-MTP.1). ### Is TLS on the MTP enough for end-to-end security? When the MTP connection runs directly between Agent and Controller, yes. When a proxy or broker sits in between, USP-layer End to End Message Exchange is required, unless the intermediary is a trusted part of the end-to-end ecosystem (§8, §8.1). ### What is Trust On First Use in USP? TOFU is the policy that makes self-signed certificates usable. The first certificate an Endpoint presents is accepted and remembered for its Endpoint ID, and an Agent that allows it gives that Controller an “untrusted” Role on first use until someone raises it (§8.5, R-SEC.6 to R-SEC.8). ### What is a Trusted Broker in USP? An intermediary trusted to vouch for the from_id of the Endpoints it brokers. It must authenticate clients with unique certificates, keep their communications confidential and never inspect USP payloads (§1.4, §8.4, R-SEC.4b, R-SEC.4c). ### What does rwxn mean in USP? It is how a Role’s permissions are written. The letters stand for Read, Write, Execute and Notify, always in that order, and a dash marks a missing permission, as in r--n (§8.9.2.1). ### Which cipher does USP end-to-end encryption use? Endpoints that protect payloads with TLS must implement ECDHE-ECDSA-AES128-GCM-SHA256 for TLS 1.2 and TLS-AES128-GCM-SHA256 for TLS 1.3, with ECDHE and ECDSA on the NIST P-256 curve (R-E2E.40, R-E2E.40a, R-E2E.40b). ## Sources - Broadband Forum, TR-369 – The User Services Platform, Issue 1 Amendment 5 (USP 1.5), January 2026. - Dodderware, DWS Support product and engineering documentation. - §1.4: Definitions (Role, Trusted Broker, End to End Message Exchange) - §1.6.2, §2, §2.1: Security as a design goal, architecture components, how Endpoint communication is secured - §4.1.2, §4.1.3.1: Securing MTPs, the payload_security field - §6, §6.3, §6.4: End to End Message Exchange, Record integrity, Secure Message Exchange - §7.5.1, §7.8: Read permission in Get (R-GET.1), error 7006 Permission denied - §8, §8.1 to §8.8: Authentication, RBAC, trusted CAs, Trusted Brokers, self-signed certificates, Agent authentication, challenges - §8.9: Theory of operations, Roles, permissions and special Roles [Read the TR-369 specification](https://usp.technology/specification/index.htm) TR-369 © The Broadband Forum. All rights reserved. Quoted briefly and paraphrased for commentary; the diagrams are Dodderware’s own. --- **Manage TR-069 and TR-369 devices from one console.** DWS Support brings every ONT and home router into one web console, whichever protocol it speaks: TR-069 through GenieACS or a built-in ACS, TR-369 through a native USP controller. Self-hosted on your infrastructure. [Request a demo](https://dodderware.com/products/dws-support/#get-started)