[Home](/)/[Resources](/resources)/NIST IoT Cybersecurity

USCybersecurityRegulation guide

# NIST IoT Cybersecurity — SP 800-213 and Device Baseline

NIST Special Publication 800-213 (IoT Device Cybersecurity Guidance for the Federal Government) and its companion document SP 800-213A (IoT Device Cybersecurity Capability Core Baseline) define the cybersecurity capabilities that IoT devices should support — both for federal procurement and, increasingly, as the framework underpinning commercial IoT security labelling programs including the FCC Cyber Trust Mark.

Copy Link[Share on WhatsApp](https://wa.me/?text=https%3A%2F%2Fkrono-labs.com%2Fguides%2Fus-nist-iot-cybersecurity)

At a glance

Framework

NIST SP 800-213 / 800-213A

Capability areas

6 baseline areas

Consumer label

FCC Cyber Trust Mark

Supporting docs

NISTIR 8259 series

Mandatory?

Federal procurement; voluntary commercial

## NIST SP 800-213 structure and scope

### NIST SP 800-213 — Federal Agency Guidance

SP 800-213 provides guidance for federal agencies on how to identify IoT devices in their environments, assess those devices against cybersecurity requirements, and select devices that meet procurement standards. It frames IoT security in terms of the agency's system security plan and FISMA obligations, and directs agencies to use SP 800-213A as the device capability baseline.

### NIST SP 800-213A — Device Capability Baseline

SP 800-213A is the companion document manufacturers engage with most directly. It defines six capability areas that IoT devices should support to be suitable for federal procurement and to meet the intent of the IoT Cybersecurity Improvement Act. Each capability area is defined with baseline activities — specific behaviours the device must support — and enhanced activities for higher-security applications.

### NISTIR 8259 Series — Supporting Documents

The NISTIR 8259 series provides additional depth on device cybersecurity capabilities (8259A), non-technical supporting capabilities (8259B), federal profile (8259C), and a catalogue of IoT capabilities (8259D). Together with SP 800-213 and 800-213A, the 8259 series forms a comprehensive framework for IoT device security from the manufacturer's perspective.

### Relationship to NIST CSF and SP 800-53

SP 800-213 is designed to complement the NIST Cybersecurity Framework (CSF) and SP 800-53 (Security and Privacy Controls for Information Systems). Where CSF and SP 800-53 address organisational and system-level security, SP 800-213A addresses the device-level capabilities that IoT devices must provide for agencies to implement those broader controls. The three frameworks work together across different layers of federal cybersecurity.

## The six device capability baseline areas (SP 800-213A)

Each baseline capability area represents a functional security behaviour that an IoT device must support for an operator to effectively manage its security. These are device-side capabilities — not policy decisions by the operator — and they must be built into the product before it ships.

01

Device identification — the device must have a unique logical identifier (such as a serial number or hardware identifier) and must be able to report its manufacturer name, model designation, and serial number or equivalent unique identifier to authorised users and network management systems.

02

Device configuration — the device must support the ability to update its configuration to a secure state, disable features and functions that are not required for the device's operational role, and restore factory default settings in a way that removes user data and configuration.

03

Data protection — the device must protect data it stores and transmits using cryptographic mechanisms appropriate to the sensitivity of the data, implement secure key management, and protect sensitive configuration data (credentials, certificates, private keys) from unauthorised access or export.

04

Logical access to interfaces — the device must require authentication for access to each network interface and local interface, support role-based access control that limits what each authenticated user can do, and implement account lockout or equivalent controls after repeated failed authentication attempts.

05

Software update — the device must support the ability to update its software and firmware, verify the cryptographic authenticity and integrity of updates before applying them, and communicate the device's current software version and update availability status to authorised users and management systems.

06

Cybersecurity state awareness — the device must support event logging for security-relevant events (authentication attempts, configuration changes, software updates, anomalous network activity), provide a mechanism to access or export logs, and have the ability to report detected anomalies to external monitoring systems.

## Non-technical supporting capabilities

SP 800-213A distinguishes between technical device capabilities (what the device can do) and non-technical supporting capabilities (what the manufacturer communicates to buyers and operators). Both are required — a device that has all six technical capabilities but provides no documentation does not meet the full intent of the baseline.

### Security Capability Documentation

Manufacturers are expected to provide documentation that describes what each of the six baseline capability areas supports in their specific device. This is not just a checkbox — NIST expects manufacturers to explain how the capability is implemented, what interfaces it applies to, and any limitations or constraints on its use. Federal procurement officers use this documentation to assess whether the device meets their agency's requirements.

### Network Diagram and Data Flow Description

Manufacturers should provide a description of the expected network connections the device makes — including cloud connections, management interfaces, and update mechanisms — along with a description of what data flows over each connection. This supports the agency's ability to integrate the device into their network architecture and firewall rules without surprises.

### Known Vulnerability Sources Disclosure

NIST expects manufacturers to disclose where they publish information about known vulnerabilities in their devices — whether that is a security advisory page, a CVE database entry process, or a coordinated vulnerability disclosure programme. Buyers need to know how they will learn about future vulnerabilities and what the manufacturer's patch release process looks like.

### Hardening Guide

A hardening guide describes how to configure the device for a secure operational state — what features to disable, what default credentials to change, what network ports to close, and what security settings to enable. NIST expects this to be provided before purchase so buyers can assess the operational security posture of the device in their specific environment.

## FCC Cyber Trust Mark and NIST alignment

### FCC Cyber Trust Mark Mapping to SP 800-213A

The FCC Cyber Trust Mark (launched 2024) uses cybersecurity requirements derived from NIST SP 800-213A as its technical baseline for consumer IoT products. Products are tested against these requirements by accredited testing laboratories. Certification to the FCC Cyber Trust Mark requirements demonstrates alignment with the same baseline that governs federal procurement — creating a unified standard that spans government and consumer markets.

### Testing and Label Display Requirements

Products certified under the FCC Cyber Trust Mark programme display the mark on packaging and on the product. A QR code links to a public product security registry where consumers and buyers can verify the certification and access security information about the device. Testing is conducted by UL, CSA, or other FCC-authorised third-party administrators.

### Voluntary Programme with Mandatory Potential

The FCC Cyber Trust Mark is currently voluntary. However, FCC commissioners have indicated that the programme may evolve toward mandatory requirements for certain product categories — particularly those connected to critical infrastructure or used in federal facilities. Manufacturers who implement SP 800-213A capabilities now are well-positioned regardless of whether the programme becomes mandatory.

### Relationship to EU Cyber Resilience Act

Manufacturers selling in both the US and EU markets face both the FCC Cyber Trust Mark (US) and the EU Cyber Resilience Act (CRA), which applies from 2027. Both programmes share a foundation in device-level cybersecurity capabilities similar to SP 800-213A, but the CRA adds mandatory vulnerability reporting obligations, a 24-hour ENISA notification requirement for actively exploited vulnerabilities, and CE marking integration. Dual-market manufacturers should design to the more demanding of the two requirements.

## Frequently asked questions

### Is NIST SP 800-213A mandatory for commercial IoT products?

NIST SP 800-213A is not directly mandatory for commercial IoT products. It was developed under the IoT Cybersecurity Improvement Act, which applies to federal agency procurement and their contractors. For purely commercial products sold outside the federal supply chain, SP 800-213A compliance is currently voluntary. However, the FCC Cyber Trust Mark — which is gaining market traction — uses SP 800-213A as its technical baseline, and supply chain pressure from federal prime contractors is extending the effective reach of the standard into commercial markets.

### How does the FCC Cyber Trust Mark differ from the EU CRA?

The FCC Cyber Trust Mark is a voluntary labelling scheme for consumer IoT products, currently focused on demonstrating baseline security capabilities. The EU Cyber Resilience Act (CRA) is mandatory regulation applying to all products with digital elements sold in the EU, with significantly broader requirements including mandatory vulnerability reporting to ENISA within 24 hours of discovery, post-market surveillance obligations, and integration with CE marking. The CRA also covers a wider product scope than the Cyber Trust Mark. Manufacturers targeting both markets should implement the union of both requirements.

### What does 'device identification' mean in practice for SP 800-213A compliance?

Device identification under SP 800-213A means the device must have a unique logical identifier — typically a hardware serial number, MAC address, or cryptographic device identity — that is unique across all units of that model. The device must also be capable of reporting its manufacturer name, model number, and that unique identifier to authorised network management systems or users. In practice, this means the device firmware must expose these values through its management interface (web UI, CLI, SNMP, or API) in a way that a network management system can query and record them for inventory purposes.

### How do we document NIST SP 800-213A compliance for a hardware product?

Documentation for SP 800-213A compliance should address each of the six capability areas with a description of how the capability is implemented in the specific device. For each capability, describe: what the capability does, which interfaces it applies to, any limitations, and where the operator can find instructions to use it. Supporting documents should include a network diagram of expected connections, a data flow description, a list of where security advisories are published, and a hardening guide. This documentation package should be available to prospective buyers before purchase — NIST explicitly frames this as pre-sale transparency, not post-sale documentation.

**Disclaimer:** This page is an educational resource only and does not constitute legal or regulatory advice. NIST publications are updated periodically and FCC Cyber Trust Mark requirements are evolving. Always consult current NIST documents and qualified counsel for product-specific compliance decisions.

🇺🇸 US roadmap for your product

Every standard, document, and test that applies — free, no account required.

See your free roadmap[

Want an expert to take your product through 🇺🇸 US compliance for you?

One consultant from Krono's compliance team takes your product from requirements to legal sale, with a fixed quote before any work starts.

See compliance services](/services)

Learn this properly

In-depth course that teaches the full process, not just this one answer.

[Start the course — $149](/courses/12-fcc-cyber-trust-mark-iot-security)[Prefer to read? Get the book — $24.99](/books/12-fcc-cyber-trust-mark-iot-security)

Related guides

*   [US IoT Cybersecurity ActGuide to the IoT Cybersecurity Improvement Act of 2020 — NIST SP 800-213A baseline, federal procurement requirements, and the F…](/guides/us-iot-cybersecurity-act)
*   [EU Cyber Resilience ActEU Cyber Resilience Act for hardware: default-secure requirements, vulnerability disclosure, 24-hour incident notification, and the four Annex I product classes.](/guides/eu-cyber-resilience-act)
*   [RED Cybersecurity Delegated ActCommission Delegated Regulation (EU) 2022/30 activates RED Article 3.3(d)(e)(f) for Wi-Fi, Bluetooth, and cellular products.](/guides/red-cybersecurity-delegated-act)
*   [US Supply Chain SecurityComplete guide to US supply chain security.](/guides/us-supply-chain-security)