Manufacturer Usage Description (MUD, RFC 8520), explained

Manufacturer Usage Description (MUD) is an IETF Standards Track mechanism, defined in RFC 8520, that lets a single-purpose network device — an IoT sensor, a camera, an industrial controller — tell the network what access it actually needs, so the network can restrict it to exactly that and nothing more. Published in March 2019 as a Proposed Standard by Eliot Lear (Cisco Systems), Ralph Droms (Google) and Dan Romascanu, its Abstract states the goal plainly: "to provide a means for end devices to signal to the network what sort of access and network functionality they require to properly function." MUD replaces the manual, per-device firewall rule-writing that most networks either skip entirely or get wrong, with a manufacturer-authored, machine-readable policy that any compliant network can fetch and enforce.

Why MUD exists: "Things," not general-purpose computers

RFC 8520 is explicit about the class of device it targets: not laptops or phones, but "Things" — devices built to do one job, whose legitimate network behavior is therefore narrow and predictable by design. A smart light bulb has no business reasons to talk to an arbitrary IP address on the internet; a building-access controller has no reason to accept inbound connections from the guest Wi-Fi. MUD gives the manufacturer of such a device a standard way to say so, up front, rather than leaving every network operator to guess or every device to run wide open by default. This is the same gap that drives device-level security scanning generally: a device's actual network behavior is often undocumented until someone watches it, which is why passive traffic analysis (see our OT pcap analysis skill) and declared-intent mechanisms like MUD are complementary, not competing, approaches.

How the MUD URL gets to the network

A device signals where to find its policy by emitting a MUD URL through one of three mechanisms RFC 8520 defines:

Mechanism	How it carries the MUD URL
DHCP	A new DHCPv4 option (161) or DHCPv6 option (112), registered with IANA in Section 17, sent during normal address configuration
X.509 certificate	A non-critical certificate extension, id-pe-mud-url (OID 1.3.6.1.5.5.7.1.25), typically embedded in an IEEE 802.1AR manufacturer-installed certificate
LLDP	A vendor-specific TLV frame, using IANA's Organizationally Unique Identifier registry, for devices on a wired LAN that use Link Layer Discovery Protocol

Whichever path carries it, the MUD URL points to a MUD file: a YANG-modeled JSON document (registered IANA media type application/mud+json) that describes the device and spells out the access-control policy its manufacturer recommends — for instance, a list of specific domains, or local network roles, the device should be allowed to reach.

MUD manager: who actually enforces the policy

The MUD manager (RFC 8520 also notes "MUD controller" as a legacy synonym for the same role) is the network-side component that retrieves a device's MUD file once it sees the MUD URL, validates it, and converts the manufacturer's recommended policy into real network controls — typically access-control lists scoped to that specific device. The split of responsibility is the point: the manufacturer authors what "normal" looks like for its own product, once, at build time; the network operator's MUD manager does the enforcement, continuously, without needing any out-of-band knowledge of what the device is supposed to do. A small device vendor gains a standard way to ship security intent without having to build or operate any network infrastructure of its own.

What RFC 8520 itself warns about (Section 16)

The specification is unusually direct about its own limits:

• Spoofing the manufacturer claim: "Things claiming to be of a certain manufacturer SHOULD NOT be included in that manufacturer grouping without additional validation of some form."
• Certificate/domain trust drift: "MUD managers SHOULD cache certificates used by the MUD file server. When a new certificate is retrieved for whatever reason, the MUD manager should check to see if ownership of the domain has changed."
• Rogue CA risk: a certificate authority could sign a certificate "that contains the same subject name as is listed in the MUDsigner field in the manufacturer certificate, thus seemingly permitting a substitute MUD file for a device."
• Weak identity binding: "Implementations SHOULD NOT grant elevated permissions... to devices that do not strongly bind their identity to their L2/L3 transmissions."

The throughline across all four: MUD constrains a device to its declared profile — it does not, on its own, prove the device presenting a given MUD URL is the genuine article. A device maker relying on MUD as a security control still needs a real identity mechanism (such as the 802.1AR certificate the URL can ride inside) behind it.

Why this matters for device and firmware makers

For a manufacturer, publishing a MUD file is a concrete, low-cost way to document — in a machine-readable, standardized format — exactly what a device is supposed to do on a network, which doubles as evidence for a secure-development narrative alongside a firmware SBOM: an SBOM says what's inside the image, a MUD file says what the image is allowed to do once it's running. No regulation known to us at the time of writing names MUD as a required control for any device class; where it is useful is as an optional, standards-based way to narrow a device's attack surface and to give downstream buyers (and assessors) a precise, manufacturer-authored baseline to check observed behavior against. Confirm any specific regulatory or buyer-specific mapping before relying on it; this guide makes no such claim.

SoftWSP's firmware and device assessments can check a device's observed network behavior against its declared intent — whether that intent comes from a MUD file or from documentation — as part of a firmware security review: see Device & Firmware Security.

This guide summarises the public IETF RFC 8520 specification; it does not constitute legal or compliance advice.