NIST SP 800-213 and 800-213A: Federal IoT Device Guide

Federal agencies may not buy or use an IoT device that their CIO determines prevents compliance with NIST's IoT standards, and NIST SP 800-213 is the guidance that tells them how to decide what a device must be able to do. SP 800-213 and its companion catalogue SP 800-213A were published as final on 29 November 2021 under the IoT Cybersecurity Improvement Act of 2020. They are written from the buyer's side: how an organisation assesses a device it plans to add to a system, turns its NIST SP 800-53 controls into device cybersecurity requirements, and handles devices that fall short. The manufacturer side, what a product should offer out of the box, is covered in the NIST IR 8259 IoT Device Cybersecurity Baseline Guide, which this guide links rather than repeats. It is written for agency system owners, ISSOs, acquisition staff and the contractors and manufacturers who sell connected devices to them, and it works equally well for any organisation that runs its risk programme on SP 800-53.

Key takeaways

A buyer's process, not a product label: SP 800-213 places device requirements inside system risk management, so the same camera can need different requirements in two different systems.
800-213A is the catalogue: it lists device cybersecurity capabilities (seven groups from Device Identification to Device Security) and non-technical supporting capabilities from manufacturers (four groups), each mapped to SP 800-53 Rev. 5 controls.
The federal profile starts at low: Appendix A of SP 800-213A is a profile built on the SP 800-53 low baseline, intended as a starting point that moderate and high systems tailor further.
The law adds teeth: section 7 of Public Law 116-207 bars agencies from procuring or using non-compliant devices from two years after enactment, with waivers for national security, research, or devices secured by alternative effective methods.
Device identity is the foundation: Device Identification and Logical Access to Interfaces capabilities map to IA-3, IA-4, IA-2 and AC-2, which makes every IoT device a non-human identity to inventory and govern.

What it is and who it applies to

SP 800-213, IoT Device Cybersecurity Guidance for the Federal Government: Establishing IoT Device Cybersecurity Requirements, gives background and recommendations for assessing how a device an organisation plans to acquire fits into its system. SP 800-213A, the IoT Device Cybersecurity Requirement Catalog, provides the features and functions a device needs to support security controls, plus the actions needed from manufacturers and other parties. Both are final, with no later revision listed on the NIST site as of 8 November 2026. The Act requires NIST to review its IoT standards at least every five years, so watch for an update.

Element	SP 800-213 position
IoT device	A device with at least one transducer (sensor or actuator) for interacting directly with the physical world and at least one network interface; it may rely on hubs or cloud services for some functions
Primary audience	Federal agencies and their system owners, security staff and acquisition teams
Legal driver	IoT Cybersecurity Improvement Act of 2020 (Pub. L. 116-207, approved 4 December 2020)
Risk framework	NIST Risk Management Framework (SP 800-37) with controls from SP 800-53 Rev. 5
Excluded	National security systems are excluded from the Act's OMB policy duties

Question	NIST IR 8259 series	SP 800-213 and 800-213A
Who uses it	Manufacturers designing products	Organisations buying and integrating devices
Output	Core baseline of capabilities a typical customer expects	System-specific device requirements, some flagged as key
Risk basis	Expected customer needs	The agency's system risk assessment and control baseline
Control mapping	High-level capabilities	Detailed sub-capabilities mapped to SP 800-53 Rev. 5

Structure and key requirements

SP 800-213 has four sections: an introduction, background considerations (systems and elements, how devices support security, and how they create challenges), identifying device cybersecurity requirements, and understanding risk management options. Section 3 is the core process:

Understand the use case (3.1): what the device is for, what data it collects, where data is stored and shared, its physical and safety interactions, organisation-specific needs such as PIV-based authentication, and the manufacturer's development and vulnerability practices.
Assess risk (3.2): work out how the device changes threat sources, vulnerabilities, likelihood and impact, and update the system risk assessment.
Identify requirements (3.3): allocate the needed controls, translate them into device and non-technical capabilities using the 800-213A mappings, tailor out what does not apply, and flag key requirements a device must meet to be integrated.
Manage gaps (section 4): where a device cannot meet requirements, use compensating controls, rely on other system elements such as a gateway or cloud service, accept the risk, or do not integrate the device.

How the examples in SP 800-213 play out

NIST illustrates the process with everyday devices, and the examples show why the same catalogue yields different requirements.

Smart speaker with remote access: if the use case needs remote connections, the device must be able to deny, authenticate, authorise and terminate them, and the manufacturer must document how to configure that. Without those capabilities the remote access control cannot be met on the device.
Smart appliance: authentication and authorisation are device capabilities, but they only help if the manufacturer's instructions explain how to set them, so a non-technical Documentation requirement travels with the technical one.
Motion sensor: a device bought to improve physical security may add network vulnerabilities that outweigh its benefit, which is a risk decision, not a checklist item.
Constrained device with a deprecated encryption module: significant compensating controls may be needed, for example terminating encryption at a gateway and isolating the device on its own segment.
Outdoor device: durable housing can be a requirement because physical damage threatens availability and integrity.

The practical lesson is to write requirements per use case and record the reasoning, because the reasoning is what an assessor and a future buyer of a replacement device will need.

The SP 800-213A catalogue

Capability group	Code	Example sub-capabilities	Example SP 800-53 mappings
Device Identification	DI	Identifier management, device authentication support, physical identifiers	IA-3, IA-4, CM-8
Device Configuration	DC	Configuration privileges, authorised changes, configuration control	AC-3, CM-5, CM-6
Data Protection	DP	Cryptography, key management, storage, secure transmission	SC-12, SC-13, SC-28, SC-8
Logical Access to Interfaces	LA	Authentication, failed attempts, authorisation, roles, remote connections	IA-2, AC-7, AC-2, AC-17
Software Update	SU	Update capability, update application support	CM-3, SI-7, SI-2
Cybersecurity State Awareness	CS	Event identification, logging content, time stamps, log protection	AU-2, AU-3, AU-8, SI-4
Device Security	DS	Execution isolation, communications, resource limits, device integrity, onboarding	SC-7, SC-39, SR-9, SC-16
Documentation	DO	Development assumptions, capabilities, maintenance, authenticity support	PL-1, IA-1
Information and Query Reception	IQ	Reception of vulnerability information, query response	Mapped in the catalogue
Information Dissemination	ID	Cybersecurity alerts and event notification	Mapped in the catalogue
Education and Awareness	EA	Secure configuration, end of life, backup, vulnerability management guidance	Mapped in the catalogue

NIST stresses that a mapping shows controls a capability may support, not that every mapped control is required. The catalogue is a menu filtered by your baseline and use case.

Identity and NHI requirements

Every connected device is a non-human identity on the network, and 800-213A makes that concrete.

Unique identity (DI:IMS, DI:PID): the device should support a unique logical identifier and physical identifiers, which feed IA-4 identifier management and CM-8 inventory. Record serial, MAC and certificate identifiers at receipt. See the Device and IoT Identity Guide.
Device authentication (DI:DAS): supports IA-3, device identification and authentication before connection. Prefer certificate-based identity with hardware-protected keys; the IoT Device Identity with TPM and DICE Guide and the IoT and Device Certificate Provisioning (EST, SCEP) Guide cover how.
Interface authentication and roles (LA:AUN, LA:AUZ, LA:ROL): management interfaces need authenticated access, authorisation and role separation, supporting IA-2 and AC-2. Default and shared credentials fail these requirements.
Onboarding (DS:ONB): mapped to IA-5 and SC-16; secure network onboarding replaces shared Wi-Fi keys with per-device credentials. See the IoT Device Onboarding Guide.
Actions based on identity (DI:AID): the system uses device identity for access decisions, logging and monitoring, which is how network segmentation and anomaly detection key on devices.
Agency identity needs: SP 800-213 cites PIV-based authentication as an organisation-specific requirement to check at the use case stage, so ask whether admin access to the device can use agency credentials.

Implementation steps

Find your IoT: inventory existing devices in each authorisation boundary using network discovery and procurement records; a device managed elsewhere may belong to another system.
Write a use case per device type: purpose, data, connections, physical effects and safety, following section 3.1.
Update the risk assessment: record how the device changes threats and impact for the system.
Start from the federal profile: for low impact systems use Appendix A of 800-213A; for moderate and high systems add the capabilities that support the extra controls in your baseline.
Tailor and flag key requirements: remove items that do not apply and mark the ones a device must meet, such as unique device authentication or signed updates.
Put requirements into acquisition: include them in solicitations and ask manufacturers for evidence: documentation (DO), vulnerability reception channels (IQ) and update commitments (SU, EA).
Test before deployment: verify key capabilities on sample units in a lab, including credential change, update signing and logging.
Handle gaps formally: document compensating controls (gateway, segmentation, monitoring), seek a section 7 waiver through the agency process where needed, or reject the device.
Monitor and retire: track vulnerability notices, apply updates, and plan replacement at manufacturer end of support.

Situation	Recommended route
Low impact system, commodity device meeting the profile	Use the federal profile as is and test key requirements
Moderate or high system	Tailor beyond the profile and require stronger evidence from the manufacturer
Device lacks a key capability but a gateway can provide it	Allocate the control to the gateway and document it in the system security plan
Device cannot be secured adequately	Request a waiver only where the CIO can justify national security, research or alternative effective methods; otherwise do not integrate

Evidence and assessment

Requirements from SP 800-213 flow into the system security plan and are assessed with the rest of the system controls, so evidence lives in the authorisation package.

Use case and risk records: the section 3.1 and 3.2 outputs per device type.
Requirement set: the tailored list of 800-213A capabilities with key requirements flagged and allocated to device or other system elements.
Manufacturer evidence: documentation, update and support commitments, vulnerability disclosure contacts.
Test results: lab verification of key capabilities on sample units.
Waivers and compensating controls: CIO determinations, waiver approvals and the controls relied on.

Metrics that show the programme works:

Percentage of IoT devices in the inventory with a documented use case and requirement set.
Percentage of devices authenticating to the network with unique credentials rather than shared keys.
Number of active section 7 waivers and their age.
Percentage of devices on a manufacturer-supported firmware version.
Median time from manufacturer security update release to deployment.

Mapping to other frameworks

SP 800-213 activity	NIST CSF 2.0	NIST SP 800-53 Rev. 5
Device inventory and identifiers	ID.AM-01	CM-8, IA-4
Device authentication	PR.AA-01	IA-3
Risk assessment of the device in the system	ID.RA-01	RA-3
Requirements in acquisition	GV.SC-06	SA-4
Software update and integrity	PR.PS-02	SI-2, SI-7
Logging and monitoring	DE.CM-01	AU-2, SI-4

SP 800-213 relies on the SP 800-53 baselines and tailoring process; see the NIST SP 800-53B Control Baselines and Tailoring Guide. Section 5 of the Act separately required NIST vulnerability disclosure guidelines aligned with ISO/IEC 29147 and 30111 where practicable, which bind contractors supplying agency systems; the Vulnerability Disclosure Policy Template helps suppliers meet that expectation.

Common pitfalls

Using the consumer label as the requirement: a consumer certification reflects home network assumptions, not your system's baseline; it is evidence, not the requirement set.
Treating every mapped control as required: NIST says mappings show possible support; untailored lists produce requirements no device can meet and waivers become routine.
Forgetting non-technical capabilities: a device with good features but no update commitment or vulnerability channel will become unsupportable.
No owner for device identities: certificates and credentials on devices expire or leak with no one tracking them.
Waivers without end dates: waivers for alternative methods should be reviewed and tied to replacement plans.
Shadow IoT outside procurement: devices bought on cards or bundled with facilities systems bypass the requirement process entirely.

Practitioner checklist

Inventory IoT devices per authorisation boundary with unique identifiers.
Write a section 3.1 use case for each device type.
Update the system risk assessment for each device type.
Start low impact requirement sets from the 800-213A federal profile and tailor moderate and high.
Flag key requirements, including unique device authentication and signed updates.
Put requirements and manufacturer evidence requests into every IoT solicitation.
Lab-test key capabilities on sample units before deployment.
Replace shared and default credentials with per-device credentials and track their expiry.
Document compensating controls and route waivers through the CIO process.
Track manufacturer support dates and plan replacement before end of life.

NIST SP 800-213: Setting IoT Device Requirements for Federal Systems