What NIST published

NIST published the final NIST Internal Report 8349, Methodology for Characterizing Network Behavior of Internet of Things Devices, on August 28, 2025. The report describes techniques for capturing, documenting, and characterizing the network communication behavior an IoT device needs across use cases and lifecycle conditions.

NIST explains that this work can support network access controls and generation of Manufacturer Usage Description files. The report is a methodology, not a certification that a device is secure and not a universal allowlist for every product.

Expected behavior depends on scenario. Setup, normal operation, update, failure, and decommissioning may contact different services or use different protocols. A device controlled through a phone, hub, voice service, physical input, or cloud workflow may produce different traffic for the same apparent user outcome.

The report therefore emphasizes capturing the full intended range rather than one idle trace. It also recognizes that device software changes over time. A useful characterization needs enough context to connect observed traffic with device state and intended behavior.

From packet capture to useful policy

IoT inventories often know that a device exists but not what it should communicate with. A versioned behavior profile can support segmentation, firewall policy, anomaly investigation, and supplier review. It also forces product teams to document dependencies that otherwise remain hidden until a service endpoint changes.

The methodology is valuable because it separates “unexpected” from “malicious.” Traffic outside the current profile is a signal to investigate. It may indicate compromise, a firmware change, a regional service, an untested recovery path, or an incomplete characterization. Automatically blocking every deviation can break setup, update, or safety-relevant communication.

Device manufacturers can use the methodology to document their products and improve customer guidance. Network operators and enterprise defenders can build enforceable communication policy. Cloud providers and researchers can use the profiles to reason about dependencies and change.

Firmware, mobile-app, and cloud teams are affected because expected network behavior spans the entire product, not only the embedded device. Security teams need version and regional context before treating a destination as approved.

Build a representative behavior profile

Select representative hardware, firmware, configuration, region, account state, and network conditions. Capture setup, normal operations, local and remote control, update, credential renewal, service outage, recovery, reset, and decommissioning. Record DNS, time, certificate, content-delivery, analytics, and support dependencies rather than filtering them out as background.

Map each flow to a documented product function and owner. Version the profile with firmware, app, and cloud changes. Review destinations for least privilege and decide which behavior can be represented in MUD or other network policy.

Test enforcement in a staged environment. Observe what fails, preserve an emergency recovery path, and monitor policy denials. Treat policy updates as product changes with review and rollback.

Do not block a fleet from one short lab capture. Do not assume one unit represents all regions, SKUs, optional features, and account states. Do not label every content-delivery address or changed IP as compromise without resolving its service identity.

Do not treat a MUD file as the complete threat model. Local interfaces, cloud authorization, update trust, physical access, and unsafe product behavior remain separate concerns.

Maintain the profile as product evidence

Track NIST and NCCoE updates, related MUD guidance, and corrections to the report. More importantly, monitor the product dependencies that invalidate a profile: firmware releases, mobile-app behavior, certificate infrastructure, analytics endpoints, content-delivery changes, and regional services. A profile review should be part of release management, with a diff that explains newly allowed or removed communication instead of silently broadening network policy. Retain the capture evidence behind every approved change.

The publication date, purpose, and methodology summary come from NIST. The rollout and policy recommendations above are IoT 01 analysis. A behavior profile remains evidence tied to a tested version and scenario; it should never be presented as timeless ground truth.

Use the NIST publication and its referenced MUD standards for implementation. Revisit profiles whenever firmware, mobile applications, cloud dependencies, regions, certificates, or product workflows change.