# IoT Device Cybersecurity Capability Core Baseline^NISTIR^ ^8259A^

>>This publication is available free of charge at:
:arrow_right: https://doi.org/10.6028/NIST.IR.8259A :arrow_left:

## :memo:Introduction & Purpose
This publication defines a baseline set of device cybersecurity capabilities that organizations should consider when confronting the challenge of the Internet of Things (IoT). Device cybersecurity capabilities are cybersecurity features or functions that computing devices provide through their own technical means (i.e., device hardware and software). Furthermore, this baseline is not the only set of capabilities that exist. This baseline represents a coordinated effort to produce a definition of common capabilities, not an exhaustive list.

The core baseline has been derived from researching common cybersecurity risk management
approaches and commonly used capabilities for addressing cybersecurity risks to IoT devices,
which were refined and validated using a collaborative public-private process to incorporate all
viewpoints

> These capabilities were developed in the context of NISTIR 8259, Foundational Cybersecurity Activities for IoT Device Manufacturers

Regardless of an organization’s role, this baseline is intended to give all organizations a starting point for IoT device cybersecurity risk management, but the implementation of all capabilities is not considered mandatory.The unique risk context can be understood with the help of NIST Special Publication **800-30, Guide for Conducting Risk Assesments**.

## IoT device cybersecurity capability core baseline.

### I.
**Device Cybersecurity Capabilities:**
- ***Device Identification:*** The IoT device can be uniquely identified logically and physically.

**Common Elements:**
1. A unique **logical identifier**
2. A unique **physical identifier** at an external or internal location on the device **authorized entities** can access. **Note:** the physical and logical identifiers may represent the same value, but they do not have to.

**Rationale:**
- This capability supports asset management, which in turn supports vulnerability management, access management, data protection, and incident detection.
- The unique logical identifier can be used to distinguish the device from all others, usually for automated device management and monitoring. The unique logical identifier may also be used for device authentication, but consideration should be made to select an appropriate identifier for the purpose.
- The unique physical identifier can be used to distinguish the device from all others whenever the unique logical identifier is unavailable, such as during device deployment and decommissioning, or after a device failure.
- The capability may also need an additional logical identifier that will not necessarily be unique which is used for more specific purposes such as device intent signaling.

**IoT Reference Examples:**
- CSA: 1
- CSDE: 5.1.1
- CTIA: 4.13
- ENISA: GP-PS-10
- GSMA: CLP13_6.6.2, 6.8.1,6.20.1
- IEC: CR 1.2
- IIC: 7.3, 8.5, 11.7, 11.8
- IoTSF: 2.4.8.1, 2.4.14.3, 2.4.14.4
- OCF: 7.1.1
- PSA: C1.4, R2.1

### II.

**Device Cybersecurity Capability:**
- ***Device Configuration:*** The **configuration** of the IoT device’s **software** can be changed, and such changes can be performed by authorized entities only.

**Common Elements:**
1. The ability to change the device’s software configuration settings
2. The ability to restrict configuration changes to authorized entities only
3. The ability for authorized entities to restore the device to a secure configuration defined by an authorized entity

**Rationale:**
- This capability supports vulnerability management, access management, data protection, and incident detection.
- An authorized entity may want to alter a device’s configuration for a variety of reasons, including cybersecurity, interoperability, privacy, and usability.
- Most cybersecurity capabilities are at least somewhat dependent on the presence of a device configuration capability.
- Unauthorized entities may want to change a device's configuration for many reasons, such as gaining unauthorized access, causing the device to malfunction, or secretly monitoring the device's environment.
- The ability to restore a secure configuration for a device is helpful when the current configuration contains errors, has been damaged or corrupted, or is otherwise no longer thought to be trustworthy.

**IoT Reference Examples:**
* BITAG: 7.1
* CSA: 22
* ENISA: GP-TM-06
* IEC: CR 7.4, CR 7.6
* IIC: 7.3, 7.6, 8.10, 11.5
* IoTSF: 2.4.8.17, 2.4.15
* ISOC/OTA: 26
* OCF: 5.3.3, 8.2, 12, 13.3.1
* PSA: C2.3, R6.1, R7.1

### III.

**Device Cybersecurity Capability:**

- ***Data Protection:*** The IoT device can protect the data it stores and transmits from unauthorized access and modification.

**Common Elements:**

1. The ability to use demonstrably secure cryptographic modules for standardized cryptographic algorithms (e.g., encryption with authentication, cryptographic hashes, digital signature validation) to prevent the confidentiality and integrity of the device’s stored and transmitted data from being compromised
2. The ability for authorized entities torender all data on the device inaccessible by all entities, whether previously authorized or not (e.g., through a wipe of internal storage, destruction of cryptographic keys for encrypted data)
3. The ability for authorized entities to configure the cryptography use itself, such as choosing a key length.

**Rationale:**

- This capability supports access management, data protection, and incident detection.
- Authorized entities often want the integrity of their data protected so it is not inadvertently or intentionally changed, which could have a variety of adverse consequences (e.g., issuing the wrong command to a piece of equipment, concealing malicious activity).

**IoT Reference Examples:**

- AGELIGHT: 5, 7, 18, 24, 25, 34
- BITAG: 7.2, 7.10
- CSDE: 5.1.3, 5.1.4, 5.1.5, 5.1.8, 5.1.10
- CTIA: 4.8, 5.14, 5.15
- ENISA: GP-OP-04, GP-TM02, GP-TM-04, GP-TM-14, GP-TM-24, GP-TM-32, GPTM-34, GP-TM-35, GP-TM39, GP-TM-40
- ETSI: 4.4-1, 4.5-1, 4.5-2, 4.11-1, 4.11-2, 4.11-3
- GSMA: CLP13_6.4.1.1, 6.11, 6.12.1.1, 6.19, 7.6.1, 8.10.1.1, 8.11.1
- IEC: CR 3.1, CR 3.4, CR 4.1, CR 4.2, CR 4.3
- IIC: 7.3, 7.4, 7.6, 7.7, 8.8, 8.11, 8.13, 9.1, 10.4, 11.9
- IoTSF: 2.4.6.5, 2.4.7, 2.4.8.8, 2.4.8.16, 2.4.9, 2.4.12.2, 2.4.16.1, 2.4.16.2
- ISOC/OTA: 2, 17, 33
- OCF: 8.2, 11.2.1, 11.3, 14.2.2
- PSA: C1.1, C1.4, C2.4, D5.2, R2.2, R2.3, R6.1, R7.1

### IV.

**Device Cybersecurity Capability:**
***Logical Access to Interfaces:*** The IoT device can restrict logical access to its **local and network
interfaces,** and the protocols and services used by those interfaces, to authorized entities only.

**Common Elements:**
1. The ability to logically or physically disable any local and network interfaces that are not necessary for the core functionality of the device
2. The ability to logically restrict access to each network interface to only authorized entities (e.g., device authentication, user authentication)
3. Configuration settings for use with the Device Configuration capability including, but not limited to, the ability to enable, disable, and adjust thresholds for any ability the device might have to lock or disable an account or to delay additional authentication attempts after too many failed authentication attempts.

**Rationale:**
- This capability supports vulnerability management, access management, data protection, and incident detection.
- Limiting access to interfaces reduces the attack surface of the device, giving attackers fewer opportunities to compromise it. For example, unrestricted network access to an IoT device enables attackers to directly interact with the device, which significantly increases the likelihood of the device being compromised.
- Access to interfaces may be partially or completely limited based on the device’s state. For example, if a device has not been provisioned with proper network credentials, all access to/from network interfaces would be limited if using a secure onboarding scheme.

**IoT Reference Examples:**
- AGELIGHT: 10, 13, 14, 15, 16, 19
- BITAG: 7.1, 7.2, 7.3, 7.6
- CSA: 2, 4, 20
- CSDE: 5.1.2
- CTIA: 3.2, 3.3, 3.4, 4.2, 4.3, 4.9, 5.2
- ENISA: GP-TM-08, GP-TM09, GP-TM-21, GP-TM-22, GP-TM-25, GP-TM-27, GPTM-29, GP-TM-33, GP-TM42, GP-TM-44, GP-TM-45
- ETSI: 4.1-1, 4.4-1, 4.6-1, 4.6- 2
- GSMA: CLP13_6.9.1, 6.12.1, 6.20.1, 7.6.1, 8.2.1, 8.4.1
- IEC: CR 1.1, CR 1.2, CR 1.5, CR 1.7, CR 1.11, CR 2.1, CR 2.2, CR 2.13, CR 7.7, EDR 2.13
- IIC: 7.3, 7.4, 8.3, 8.6, 11.7
- IoTSF: 2.4.4.5, 2.4.4.9, 2.4.5.5, 2.4.6.3, 2.4.6.4, 2.4.7, 2.4.8
- ISOC/OTA: 3, 12, 13, 14, 15, 16
- NEMA: Segmenting Networks, User Management, Hardening Devices
- OCF: 5.1, 5.2, 10, 12
- PSA: C2.3, D2.1, D2.2, D2.3, D2.4, D3.1 D3.3, R3.1, R3.2, R3.3, R4.2, R4.5 R6.1

### V.

**Device Cybersecurity Capability:**
***Software Update:*** The IoT device’s software can be **updated** by authorized entities only using a secure and configurable mechanism.

**Common Elements:**
1. The ability to update the device’s software through remote (e.g., network download) and/or local means (e.g., removable media)
2. The ability to verify and authenticate any update before installing it.
3. The ability for authorized entities to roll back updated software to a previous version
4. The ability to restrict updating actions to authorized entities only
5. The ability to enable or disable updating
6. Configuration settings for use with the Device Configuration capability including, but not limited to:
- The ability to configure any remote update mechanisms to be either automatically or manually initiated for update downloads and installations
- The ability to enable or disable notification when an update is available and specify who or what is to be notified

**Rationale:**
- This capability supports vulnerability management.
- Updates can remove vulnerabilities from an IoT device.
- Updates can correct IoT device operational problems, which can improve device availability, reliability, performance, and other aspects of device operation.
- Some authorized entities will need automatic update capabilities to meet their cybersecurity goals and needs, while others would prefer or need more direct control over updates and their application.
- Some organizations may want a rollback capability in the event that an update inadvertently impacts critical applications or integration with other systems, while other organizations may prefer to eliminate the risk of someone intentionally or inadvertently rolling software back to a vulnerable version.

**IoT Reference Examples:**
- AGELIGHT: 1, 2, 4
- BITAG: 7.1
- CSDE: 5.1.9
- CTIA: 3.5, 3.6, 4.5, 4.6, 5.5, 5.6
- ENISA: GP-TM-05, GP-TM06, GP-TM-18, GP-TM-19
- ETSI: 4.3-1, 4.3-2, 4.3-7
- GSMA: 7.5.1
- IEC: CR 3.4, EDR 3.10
- IIC: 7.3, 11.5.1
- IoTSF: 2.4.5.1, 2.4.5.2, 2.4.5.3, 2.4.5.4, 2.4.5.8, 2.4.6.1
- ISOC/OTA: 1, 6, 8
- NEMA: Updating Devices
- OCF: 14.5
- PSA: C2.1, C2.2, R1.1, R1.2, R6.1

### VI.

**Device Cybersecurity Capability:**
***Cybersecurity State Awareness:*** The IoT device can report on its **cybersecurity state** and make that information accessible to authorized entities only.

**Common Elements:**

1. The ability to report the device’s cybersecurity state
2. The ability to differentiate between when a device will likely operate as expected from when it may be in a **degraded cybersecurity state**
3. The ability to restrict access to the state indicator so only authorized entities can view it
4. The ability to prevent any entities (authorized or unauthorized) from editing the state except for those entities that are responsible for maintaining the device’s state information
5. The ability to make the state information available to a service on another device, such as an event/state log server

**Rationale:**
- This capability supports vulnerability management and incident detection.
- Cybersecurity state awareness helps enable investigating compromises, identifying misuse, and troubleshooting certain operational problems.
- How the device makes other entities aware of a cybersecurity state will vary based on contextspecific needs and goals, but may include capturing and logging information about events in a persistent record that may have to be stored off the device, sending signals to a monitoring system to be handled externally, or alerting via an interface on the IoT device itself.

**IoT Reference Examples:**

* CSDE: 5.1.7
* CTIA: 4.7, 4.12, 5.7, 5.16
* ENISA: GP-TM-55, GP-TM56
* ETSI: 4.7-2, 4.10-1
* GSMA: CLP13_6.13.1, 7.2.1, 9.1.1.2
* IEC: CR 2.8, CR 3.9, CR 6.1, CR 6.2
* IIC: 7.3, 7.5, 7.7, 8.9, 10.3, 10.4
* IoTSF: 2.4.7.5
* NEMA: Monitoring Devices and Systems
* OCF: 5.1, 5.7, 8.6, 12, 13.8, 13.16
* PSA: C1.3, D1.1, D3.2, D3.4, D3.5, D5.1, R4.1, R4.3, R4.4