Summary

  • An active IOTOPS draft proposes a signed path for replacing a device's Manufacturer Usage Description URL. It is revision 03 of a working-group Internet-Draft, not a published RFC.
  • A manufacturer changing hostnames after an acquisition may need to keep the old MUD file reachable and use its signed contents to announce a new canonical URL. Under the proposal, a cross-host HTTP 301 alone should not be trusted.
  • The controller must bind each move to the accepted root file and signing identity. A new owner cannot treat a new domain, a familiar certificate authority or a firmware update notice as proof that the existing fleet has moved.

The most expensive thing in an IoT acquisition may be a URL printed years before the lawyers arrived. Under RFC 8520, a device can advertise a Manufacturer Usage Description, or MUD, URL. A network controller retrieves the manufacturer's file and turns its description of expected connections into local access policy. Once deployed, that small address is a route into the firewall's decision process. It can outlive a product line, a hosting contract and the company on the box.

The IOTOPS draft dated 1 November 2026 asks what happens when the file must move. The authors use a hypothetical toaster and a hypothetical corporate acquisition. The scenario is concrete: the file's path changes, the host changes, or the signer changes while devices already sold continue reporting the old URL. A purchaser who controls the new website does not thereby control the old device's accepted policy lineage.

The shortcut that opens another product's door

Changing a MUD file in place has its own trap. If new firmware needs a wider set of connections, the new file can authorize those connections for old firmware that still has weaker safeguards. If a later file removes a connection, an unupgraded device may be classified as misbehaving for traffic its installed software still needs. The draft's answer is to let different firmware releases lead to different MUD URLs, while keeping the controller's acceptance rule tighter than “the vendor signed something.”

That last phrase matters. A manufacturer may sign files for several products. A compromised device able to alter the MUD URL announced through DHCP or LLDP could point at another product's legitimately signed file, perhaps one with broader access. Pinning the manufacturer's general signing authority would verify the signature and still choose the wrong permission set. The proposed controller begins with an accepted root MUD file for this device and limits subsequent URLs to a controlled succession from it.

The small move is deliberately narrow. A candidate URL keeps the original base URI and path prefix, changing the final segment, and its file is signed by an equivalent end-entity identity under the same trusted certificate authority and subject name. RFC 3986 supplies the URI syntax used to parse that boundary. The draft also asks controllers to remember previously retrieved URLs: a device that returns to an old file may be attempting to roll back to permissions that were abandoned for a reason. This is a proposed policy for controllers configured to check signed MUD files; RFC 8520 itself does not require every controller to verify signatures or settle the first trust decision.

Moving the house while the old doorbell still rings

A large move uses the old file as a bridge. Once the controller accepts a file at an allowed URL, that signed file can declare a new canonical MUD URL in its own MUD-URL attribute. Future moves are measured from the new canonical address. The file is the handover document. A naked redirect is only a web-server instruction.

For a hostname change, the draft says the old location must remain available long enough for existing devices to pass through that handover. It says a controller SHOULD NOT accept an HTTP 301 that changes hostname. The buyer's tidy server migration collides with the installed fleet's trust boundary. Old controllers must be able to fetch and validate the bridge before the new host becomes the starting point.

The cache has a vote too. A manufacturer needs an old file served so a controller can discover changed contents; the draft invokes validators and cache controls whose behavior is described in RFC 9111. If the old location's refresh behavior cannot be managed, the draft describes an intermediate URL within the accepted path and two firmware updates before the final destination. That is a possible route around a specific cache problem, not a count of updates required for every acquisition. An acquirer that shuts down the predecessor's host too early can strand devices on a stale policy even while the new site looks perfect in a browser.

Signing authority can move without the same freedom as a website. The draft illustrates a certificate-authority change bridged through a chain that preserves the end-entity subject name. It expressly does not support changing the signing subject name by that route. A corporate name on a purchase agreement, a new CA and a familiar logo are separate facts. The controller needs a valid chain under its accepted identity policy.

The decisive missing evidence in a real transaction is a fleet matrix: which firmware revision each device runs, which URL it announces, which signed MUD file each controller accepted, when the old file was refreshed, and which access policy was actually installed. A signature alone cannot supply that operating record. Nor does the draft report a deployed migration or a population of affected devices. A buyer can inspect those records during diligence; the result decides how long the old host and signer must be kept alive.

The draft is still an Internet-Draft. Its proposal already identifies the asset a hurried acquisition checklist misses. The old URL is not stale marketing copy. It is the first link in a chain that can grant or withhold network access from devices the new owner has paid to inherit. Turn it off before the chain crosses, and the buyer has purchased a fleet whose firewall instructions still live at the seller's address.

IOTOPS draft · RFC 8520 · RFC 3986 · RFC 9111