Version SNAPSHO

OWASP IoT Security Verification Standard

Version SNAPSHOT December 22, 2020

OWASP IoT Security Verification Standard SNAPSHOT

Table of Contents
Frontispiece 4

Using the ISVS 6

V1: IoT Ecosystem Requirements 10

V2: User Space Application Requirements 14

V3: Software Platform Requirements 18

V4: Communication Requirements 23

V5: Hardware Platform Requirements 27

Glossary 29

3
OWASP IoT Security Verification Standard SNAPSHOT

Frontispiece

About the Standard

The OWASP Internet of Things Security Verification Standard (ISVS) is a community effort to establish a
framework of security requirements for Internet of Things (IoT) applications. The requirements provided
by the ISVS can be used at many stages during the product development life cycle including design, de-
velopment, and testing of IoT applications.

Copyright and License

Copyright © 2021 The OWASP Foundation.

This document is released under the Creative Commons Attribution ShareAlike 4.0 license. For any reuse
or distribution, you must make clear to others the license terms of this work.

Version 1.0, 22 January 2021

Project Leads

• Cédric Bassem
• Aaron Guzman

Contributors and Reviewers

• Théo Rigas
• Leo Dorrendorf
• Anna Schnaiderman

4
OWASP IoT Security Verification Standard SNAPSHOT

The IoT Security Verification Standard is built upon the hard work of volunteers and contributors. The
project originated as part of an appendix by the OWASP Application Security Verification Standard and
was decided the topic of IoT needed its own standard.

If a credit is missing from the credit list above, please contact the project leaders: aaron.guzman@owasp.org
& cedric.bassem@owasp.org or log a ticket at GitHub to be recognized in future updates.

5
OWASP IoT Security Verification Standard SNAPSHOT

Using the ISVS

The OWASP Internet of Things Security Verification Standard (ISVS) aims to establish levels of confidence
in the security of IoT applications by providing requirements and best practices for connected devices.

IoT applications are often composed of many interconnected applications that together form a complex
ecosystem. Securing an IoT application thus boils down to securing the ecosystem. The ISVS, therefore,
specifies security requirements for embedded applications and the IoT ecosystem in which these reside
while referring to existing industry-accepted standards as much as possible.

The ISVS security model

The security control requirements provided by the ISVS can be represented as a stack. At the bottom, re-
quirements for the hardware platform (V5) are provided. Throughout the ISVS, the hardware platform is
regarded as the different hardware components that make up the foundations for your connected device.
On top of the hardware platform are the Software Platform (V3) and the Communication (V4) require-
ments that make use of the hardware platform to enable rich application development. Requirements
for these applications are provided in the user space applications requirements layer (V2). Finally, the IoT
Ecosystem chapter provides a series of requirements that form the glue between the connected device
and the surrounding ecosystem (V1).

6
OWASP IoT Security Verification Standard SNAPSHOT

Security Verification Levels

The ISVS describes three security verification levels, with each level increasing in depth. Each level con-
tains a set of requirements mapped to security-sensitive capabilities and features.

ISVS Level 1

The goal of level one requirements is to provide protection against attacks that target software only,
i.e. attacks that do not involve physical access to the device. Level one requirements aim to provide a
security baseline for connected devices where physical compromise of the device does not result in high
security impact. These are devices where the deviceʼs IP should not be protected, where no sensitive in-
formation is being stored on the device, and where compromise of one device does not allow an attacker
to move laterally to other devices or systems on the IoT ecosystem.

7
OWASP IoT Security Verification Standard SNAPSHOT

An example of a level one device is a smart light bulb created with off the shelf hardware and software
components. Compromise of the light bulb would not result in an attacker gaining access to state-of-the
art technology. If no personal data is stored on the device, there is no data to be stolen. If authentication
and authorization are correctly implemented on the supporting cloud infrastructure, the worst thing the
attacker could do is spoof the status of the compromised light bulb.

ISVS Level 2

The goal of level two requirements is to provide protection against attacks that go beyond software and
that target the hardware of the device. Devices that adhere to level two requirements are devices where
compromise of the device should be avoided. These are devices where the deviceʼs IP should be pro-
tected to a reasonable extent and where there is some form of sensitive information stored on the de-
vice.
Examples of level two devices are smart locks, alarm systems, smart cameras, and medical devices that
aggregate measurement data and send it to a physician for analysis.

ISVS Level 3

The goal of level three requirements is to provide requirements for devices where compromise should be
avoided at all cost. Devices where there is highly sensitive information stored on the device or where com-
promise of the device can result in fraud. In addition to the security requirements provide by level one
and two, level three requirements focus on defense-in-depth techniques that attempt to hinder reverse
engineering and physical tampering efforts.
Examples of level three devices consist of hardware crypto wallets, smart-meters, connected vehicles,
medical implants, recycle machines that trade aluminium cans for money.

Recommended Use

IoT applications can differ a lot from one another. Some applications make use of sensors and hubs,
some donʼt have sensors. Some run embedded Linux, some do not. While the ISVS aims to structure
and define requirements in such a way thatʼs widely applicable as possible, not all of the requirements
in the ISVS may apply to your specific device. We strongly encourage tailoring ISVS to your use case and
focus on high impact requirements that are most important to your environment. This may require a risk
assessment to understand the desired level of security required.
Even though the standard is called a verification standard, its use goes much wider than providing re-
quirements for verifying the overall security posture of connected devices. The fact that requirements

8
OWASP IoT Security Verification Standard SNAPSHOT

are written from a verification perspective ensures that each requirement is measurable and achievable
in practice. As a result, requirements can be used at different stages in a connected deviceʼs development
process. Some example use cases are presented below.

• During the design of the supporting hardware platform, the hardware platform requirements in
V5 are created so that they can be used to validate that the hardware platform provides all of the
functionality that is required to implement the security requirements described in the other re-
quirement category chapters.

• The requirements listed in the ISVS can be used during the requirement elicitation phase of the
project.

• The requirements can be used to assess the overall security posture of a deviceʼs environment.
It can help to define test cases, or it can be used by security professionals to assess the deviceʼs
implementation.

Document Structure

The subsequent chapters of this standard provide an overview of the different requirements categories
described above. Each requirement category has a dedicated chapter in which the requirements are
listed together with references to relevant standards. Definitions on the different words used throughout
the standard are provided in Appendix A - Glossary

9
OWASP IoT Security Verification Standard SNAPSHOT

V1: IoT Ecosystem Requirements

Control Objective

System security design performed prior to the development, and a security process which continuously
supports system development and is integrated into all phases of its life-cycle, are necessary fundamen-
tals for creating a secure product architecture and implementation.

A secure development process ensures the identification and documentation of all sensitive information
and functionality which are needed for the system, enforces all the security controls on the appropri-
ate level, and ensures that end-users and customers are notified about vulnerabilities and that security
solutions are delivered on time.

The supply chain has vital importance for the security of the every project. A secure development process
verifies that all security requirements for the suppliers and third-party code are implemented, so that
their security controls are set with the appropriate security level, and no development-time features are
left on the completed devices, exposing them to vulnerabilities.

To ensure the security of all software produced, the build process for the system software must be done
in a secure build environment that verifies the integrity and authenticity of all components. The code
must be written using best security practices and compiled using the best security options available.

Security Verification Requirements

Application and Ecosystem Design

# Description L1 L2 L3

1.1.1 Verify that all applications in the IoT ecosystem are developed with a ✓ ✓ ✓
level of security that is in line with the security criticality of the
application.
1.1.2 Verify that all components and communication channels in the IoT ✓ ✓ ✓
applicationʼs ecosystem have been identified and are known to be
needed. Remove or disable any that arenʼt necessary.
1.1.3 Verify that sensitive information and security critical actions have been ✓ ✓ ✓
identified and documented.
1.1.4 Verify that the location where sensitive data is stored in the ecosystem is ✓ ✓ ✓
clearly identified and separated from unprivileged storage locations.

10
OWASP IoT Security Verification Standard SNAPSHOT

# Description L1 L2 L3

1.1.5 Verify that security controls are enforced server-side and that data and ✓ ✓ ✓
instructions are not blindly trusted by server-side components.
1.1.6 Verify that a responsible disclosure policy has been established and that ✓
it is easily found on the company website. Ensure that the policy
provides a clear overview on how vulnerabilities can be communicated
securely and how theyʼll be followed up on.
1.1.7 Verify that users and relevant stakeholders are notified when ✓ ✓ ✓
vulnerabilities are identified through established communication
channels (website, e-mail …).

Supply Chain

# Description L1 L2 L3

1.2.1 Verify that each application (including firmware) in the ecosystem ✓ ✓ ✓

maintains a software bill of materials (SBOM) cataloging third-party
components, versioning, and published vulnerabilities.
1.2.2 Verify that potential areas of risk that come with the use of third-party ✓ ✓ ✓
and open-source software have been identified and that actions to
mitigate such risks have been taken.
1.2.3 Verify the device is released with firmware and configuration ✓ ✓ ✓
appropriate for a release build (as opposed to debug versions).
1.2.4 Verify that access to debugging interfaces (e.g. JTAG, SWD) is disabled or ✓ ✓
protected before shipping the device. Processors may refer to this as
code protection, read back protection, CodeGuard, or access port
protection.
1.2.5 Verify debug capabilities in FPGAs are disabled. ✓ ✓
1.2.6 Verify that devices are provisioned with a cryptographic root of trust that ✓ ✓
is hardware-based and immutable.
1.2.7 Verify that code integrity protection mechanisms are enabled and locked ✓ ✓
in hardware before shipping the device to customers. For example,
ensure secure boot is enabled and the boot configuration locked.

11
OWASP IoT Security Verification Standard SNAPSHOT

# Description L1 L2 L3

1.2.8 Verify third-party code and components are analyzed using static ✓ ✓
analysis tools to ensure backdoors are not introduced.
1.2.9 Verify debug paths and traces are depopulated from production PCBs. ✓

Secure Development

# Description L1 L2 L3

1.3.1 Verify that each application in the ecosystem is built using a secure and ✓ ✓ ✓
repeatable build environment.
1.3.2 Verify GPL based firmware has its source code published and that no ✓ ✓ ✓
sensitive or proprietary information is accidentally included in the
process.
1.3.3 Verify that use of banned C/C++ functions (i.e. memcpy, strcpy, etc.) are ✓ ✓
replaced with safe equivalents functions (e.g. Safe C).
1.3.4 Verify packages are downloaded and built from trusted sources. ✓ ✓ ✓
1.3.5 Verify build pipelines only perform builds of source code maintained in ✓ ✓ ✓
version control systems.
1.3.6 Verify that compilers, version control clients, development utilities, and ✓ ✓ ✓
software development kits are analyzed and monitored for tampering,
trojans, or malicious code
1.3.7 Verify packages are compiled with Object Size Checking (OSC). ✓ ✓
e.g. -D_FORTIFY_SOURCE=2
1.3.8 Verify packages are compiled with No eXecute (NX) or Data Execution ✓ ✓
Protection (DEP). e.g. -z,noexecstack
1.3.9 Verify packages are compiled with Position Independent Executable ✓ ✓
(PIE). e.g. -fPIE
1.3.10 Verify packages are compiled with Stack Smashing Protector (SSP). ✓ ✓
e.g. -fstack-protector-all
1.3.11 Verify packages are compiled with read-only relocation (RELRO). ✓ ✓
e.g. -Wl,-z,relro

12
OWASP IoT Security Verification Standard SNAPSHOT

# Description L1 L2 L3

1.3.12 Verify release builds do not contain debug code or privileged diagnostic ✓ ✓ ✓
functionality.
1.3.13 Verify that debug and release firmware images are signed using different ✓ ✓
keys.
1.3.14 Verify that debug information does not contain sensitive information, ✓ ✓ ✓
such as PII, credentials or cryptographic material.
1.3.15 Verify that embedded applications are not susceptible to OS command ✓ ✓ ✓
injection by performing input validation and escaping of parameters
within firmware code, shell command wrappers, and scripts.

References

For more information, see also:

• OWASP ASVS: https://owasp.org/www-project-application-security-verification-standard/

• OWASP MASVS: https://github.com/OWASP/owasp-masvs
• OWASP Threat modelling: https://owasp.org/www-community/Application_Threat_Modeling
• OWASP SCVS: https://github.com/OWASP/Software-Component-Verification-Standard
• OWASP Secure SDLC Cheat Sheet: https://github.com/OWASP/CheatSheetSeries/blob/master/
cheatsheets_excluded/Secure_SDLC_Cheat_Sheet.md
• Microsoft SDL: https://www.microsoft.com/en-us/sdl/
• OWASP C-based Toolchain Hardening Cheat Sheet: https://cheatsheetseries.owasp.org/
cheatsheets/C-Based_Toolchain_Hardening_Cheat_Sheet.html
• OWASP Embedded Application Security: https://owasp.org/www-project-embedded-application-
security/

13
OWASP IoT Security Verification Standard SNAPSHOT

V2: User Space Application Requirements

Control Objective

The purpose of the controls listed in this chapter is to ensure secure access to an IoT system by users and
machines and to protect sensitive data by using security best practices.

Authentication and authorization are necessary to secure access. Relevant controls include strong
unique secure identity, user role segregation, and the concept of least privilege. Authentication is the
act of establishing, or confirming, the identity of someone (or something) as authentic, as a basis to
believe that claims made by a person or about a device are correct and resistant to impersonation.
Additional necessary controls include preventing recovery or interception of authentication credentials
such as passwords. Authorization is the act of establishing, or confirming someone (or something) has
access rights to resources or actions satisfying the secure access policy.

Protection of sensitive data including credentials, and fair treatment of private information, are neces-
sary to ensure secure use of system resources, such as files containing data or code, and the contents of
memory.

Many controls in this chapter are implemented through cryptography. Therefore additional controls are
necessary to select the right cryptographic primitives and configure them with secure credential stor-
age.

Security Verification Requirements

Identification & Authentication

# Description L1 L2 L3

2.1.1 Verify that all forms of users and accounts in the IoT ecosystem can be ✓ ✓ ✓
uniquely identified.
2.1.2 Verify that all connected devices within the IoT ecosystem can be ✓ ✓ ✓
uniquely identified including connected to the cloud, hubs, as well as to
other devices (sensors).
2.1.3 Verify strong user and device authentication is enforced across the IoT ✓ ✓ ✓
ecosystem.
2.1.4 Verify that user, services, and device authentication schemes share a ✓ ✓ ✓
common framework centrally managed in the IoT ecosystem.

14
OWASP IoT Security Verification Standard SNAPSHOT

# Description L1 L2 L3

2.1.5 Verify certificate based authentication is preferred over password based ✓ ✓ ✓

authentication within the IoT ecosystem.
2.1.6 Verify good password policies are enforced throughout the IoT ✓ ✓ ✓
ecosystem by disallowing hardcoded passwords and provisioning
duplicate identities or passwords across devices.

Authorization

# Description L1 L2 L3

2.2.1 Verify that sensitive information such as personal identifiable ✓ ✓ ✓

information (PII) and API keys are stored securely using encryption to
protect from data leakage, and integrity checking to protect against
unauthorized modification.
2.2.2 Verify that IoT system accounts across users, services and devices share ✓ ✓ ✓
a common authorization framework.
2.2.3 Verify that devices enforce the concept of least privilege by limiting ✓ ✓ ✓
applications and services that run as root or administrator.
2.2.4 Verify that ownership is validated upon registration and as part of ✓ ✓ ✓
decommissioning when devices move across accounts. e.g. Device
reselling, leasing, and renting.
2.2.5 Verify device debug capabilities can only be accessed by approved staff ✓ ✓
(e.g. support and engineering teams) and verify that access is
monitored/logged.

Data Protection

# Description L1 L2 L3

2.3.1 Verify that sensitive information such as personal identifiable ✓ ✓ ✓

information (PII) used by the device is stored securely on the device.
Protection can include encryption against data leakage, and hashing or
integrity checking against unauthorized modification.

15
OWASP IoT Security Verification Standard SNAPSHOT

# Description L1 L2 L3

2.3.2 Verify that in case a device is decommissioned, or in case the owner ✓ ✓ ✓

changes, all sensitive information such as PII data and credentials can
be removed from the device.
2.3.3 Verify that in case a device is decommissioned, or the owner changes, it ✓ ✓ ✓
is marked as such for auditable purposes in a centrally managed
database in the ecosystem.
2.3.4 Verify that sensitive information maintained in memory is overwritten ✓ ✓
with zeros as soon as it is no longer required.

Cryptography

# Description L1 L2 L3

2.4.1 Verify cryptographic secrets are unique per device. ✓ ✓ ✓

2.4.2 Verify proper use of cryptography. Only standard and strong algorithms ✓ ✓ ✓
should be used, with adequate key size and secure implementations.
2.4.3 Verify secure sources of randomness are provided by the operating ✓ ✓
system and/or hardware for all security needs.
2.4.4 Verify that cryptographic secrets used by the device are stored securely ✓ ✓
by leveraging functionality provided by dedicated security chips.
2.4.5 Verify that cryptographic primitives used by the device are provided by ✓ ✓
dedicated security chips.
2.4.6 Verify the cryptographic libraries used are certified to be compliant with ✓ ✓
a recognized cryptographic security standard.

References

For more information, see also:

• OWASP Authentication Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_

Cheat_Sheet.html
• OWASP Access Control Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Access_
Control_Cheat_Sheet.html

16
OWASP IoT Security Verification Standard SNAPSHOT

• OWASP Top 10 Privacy Countermeasures: https://owasp.org/www-pdf-archive/OWASP_Top_10_

Privacy_Countermeasures_v1.0.pdf
• NIST SP800-63B - Digital Identity Guidelines: https://pages.nist.gov/800-63-3/sp800-63b.html
• FIPS 140-2 - Security Requrements for Cryptographic Modules: https://nvlpubs.nist.gov/nistpubs/
FIPS/NIST.FIPS.140-2.pdf
• ECRYPT CSA - D5.4 - Algorithms, Key Size and Protocols Report (2018): https://www.ecrypt.eu.org/
csa/documents/D5.4-FinalAlgKeySizeProt.pdf

17
OWASP IoT Security Verification Standard SNAPSHOT

V3: Software Platform Requirements

Control Objective

The bootloader is the first piece of code to run during the deviceʼs boot process. The firmware vendor
is responsible for configuring it correctly, otherwise its vulnerabilities can undermine the security of the
entire device, leading to compromise and device hijacking. Controls in this chapter ensure boot trustwor-
thiness by verifying cryptographic signatures on the loaded code, not allowing loading images loading
from external locations, and disallowing memory, shell, and other debug access during boot.

The operating system, and its kernel in particular, are central for device security, as they run in privileged
mode and implement critical device functionality, including many security primitives. This necessitates
best security practices for operating system and kernel configuration and hardening.

The Linux operating system is one of the most popular in IoT. It has many features from first-line security
to defense-in-depth, including the isolation mechanisms supported by namespaces and cgroups, and
additional kernel security modules for access controls.

Security Verification Requirements

Bootloader

# Description L1 L2 L3

3.1.1 Verify that the bootloader does not allow code to be loaded from ✓ ✓ ✓
arbitrary locations. Locations include both storage (SD, USB, etc.) and
network locations (over TCP/IP).
3.1.2 Verify bootloader configurations are immutable in production releases. ✓ ✓
3.1.3 Verify that communication interfaces such as, USB, UART, and other ✓ ✓
variants are disabled or adequately protected during every stage of the
deviceʼs boot process.
3.1.4 Verify that the authenticity of the first stage bootloader is verified by a ✓ ✓
trusted component of which the configuration in read-only memory
(ROM) cannot be altered. e.g. CPU Based Secure Boot/Trusted Boot
3.1.5 Verify that the authenticity of next bootloader stages or application code ✓ ✓
is cryptographically verified during every step of the boot process.

18
OWASP IoT Security Verification Standard SNAPSHOT

# Description L1 L2 L3

3.1.6 Verify that bootloader stages do not contain sensitive information ✓ ✓

(e.g. private keys or passwords logged to the console) as part of device
start-up.
3.1.7 Verify that firmware is stored in an encrypted volume at rest. ✓ ✓
3.1.8 Verify that Direct Memory Access (DMA) is not possible during boot. For ✓ ✓
example, ensure DMA is not possible via PCI connections.

OS Configuration

# Description L1 L2 L3

3.2.1 Verify that the embedded operating system is configured according to ✓ ✓ ✓

industry best practices, benchmarks, and uses secure defaults.
3.2.2 Verify that all network services exposed by the device on every network ✓ ✓ ✓
interface are necessary services and unnecessary services are removed
or disabled.
3.2.3 Verify that the device does not make use of of legacy or insecure ✓ ✓ ✓
protocols such as Telnet and FTP.
3.2.4 Verify that the OS kernel and software components are up to date and do ✓ ✓ ✓
not contain known vulnerabilities.
3.2.5 Verify that persistent filesystem storage volumes are encrypted. ✓ ✓
3.2.6 Verify that applications running on the device use the security features ✓ ✓
of the underlying operating system or kernel. Including cryptography,
key storage, random number generation, authentication and
authorization, logging, communications security.
3.2.7 Verify that memory protection controls such as Address Space Layout ✓ ✓
Randomization (ASLR) and Data Execution Prevention (DEP) are enabled
by the embedded operating system.
3.2.8 Verify hardware level memory protection is used and privilege levels are ✓ ✓
enforced.
3.2.9 Verify the embedded OS provides protection against unauthorized ✓
access to RAM (e.g. RAM scrambling).

19
OWASP IoT Security Verification Standard SNAPSHOT

# Description L1 L2 L3

3.2.10 Verify that an Integrity Measurement Architecture (IMA) is in use and ✓

appropriately configured.
3.2.11 Verify that that third-party applications and services are configured to ✓
execute within a containerized runtime environment (e.g. LXC, Docker,
etc.).

Linux

# Description L1 L2 L3

3.3.1 Verify that processes are isolated using Linux kernel namespaces. ✓ ✓
3.3.2 Verify that critical processes are configured to limit resources using ✓ ✓
control groups (cgroups).
3.3.4 Verify that Linux kernel capabilities are configured with a minimal set for ✓ ✓
processes that require elevated access.
3.3.5 Verify that SECure COMPuting (seccomp BPF) with filters are used and ✓ ✓
properly configured to only allow necessary system calls.
3.3.6 Verify the use of kernel security modules such as SELinux, AppArmor, ✓
GRSEC, and alike.

Software Updates

# Description L1 L2 L3

3.4.1 Verify that packages and user space applications use over the air ✓ ✓
updates decoupled from firmware updates.
3.4.2 Verify that devices can be updated automatically upon a pre-defined ✓ ✓ ✓
schedule.
3.4.3 Verify that the authenticity of updates are cryptographically signed by a ✓ ✓ ✓
trusted source and verified before execution.

20
OWASP IoT Security Verification Standard SNAPSHOT

# Description L1 L2 L3

3.4.4 Verify that the update process is not vulnerable to time-of-check ✓ ✓ ✓

time-of-use attacks (TOCTOU). This is generally accomplished by
applying the update right after the authenticity of the update is
validated.
3.4.5 Verify that updates do not modify user-configured preferences, security, ✓ ✓ ✓
and/or privacy settings without notifying the user.
3.4.6 Verify that the device cannot be downgraded to known vulnerable ✓
versions (anti-rollback).
3.4.7 Verify that in the event of an update failure, the device reverts to a ✓ ✓ ✓
backup image or notifies the IoT ecosystem.
3.4.8 Verify that unsigned debug pre-production firmware builds can not be ✓ ✓ ✓
flashed onto devices.
3.4.9 Verify that encrypted firmware images are securely decrypted on the ✓ ✓
device.
3.4.10 Verify that the device authenticates to the update server component ✓ ✓ ✓
prior to downloading the update.
3.4.11 Verify that firmware updates are stored encrypted server-side. ✓ ✓

Security chip integrations

# Description L1 L2 L3

3.5.1 Verify that encryption is used on the bus between the security chip and ✓ ✓
other hardware components.
3.5.2 Verify that keys (either secret or private) used to enable encryption on ✓ ✓
the serial bus are properly secured on the host.
3.5.3 Verify any default vendor keys used in bus encryption are replaced in ✓ ✓
production builds.
3.5.4 Verify that deprecated insecure ciphers and hash functions (e.g. 3DES, ✓ ✓
MD5, SHA1) in new applications are not used, even if provided by the
hardware security chip.

21
OWASP IoT Security Verification Standard SNAPSHOT

Kernel space application requirements

# Description L1 L2 L3

3.6.1 Verify that loaded kernel modules are cryptographically signed and ✓ ✓
verified.
3.6.2 Verify that only required kernel modules are enabled during runtime. ✓ ✓ ✓

References

For more information, see also:

• ENISA - Baseline Security Recommendations for IoT: https://www.enisa.europa.eu/publications/

baseline-security-recommendations-for-iot/at_download/fullReport
• CIS Benchmarks: https://www.cisecurity.org/cis-benchmarks/
• TGC Guidance for Secure Update of Software and Firmware on Embedded Systems: https:
//trustedcomputinggroup.org/wp-content/uploads/TCG-Secure-Update-of-SW-and-FW-on-
Devices-v1r72_pub.pdf
• U-Boot documentation - Signature: https://github.com/u-boot/u-boot/blob/master/doc/uImage.
FIT/signature.txt
• GSMA - IoT Security Guidelines for Endpoint Systems: https://www.gsma.com/iot/wp-
content/uploads/2017/10/CLP.13-v2.0.pdf

22
OWASP IoT Security Verification Standard SNAPSHOT

V4: Communication Requirements

Control Objective

Devices use network communication to exchange data and receive commands within their ecosystem. So
that the different parties can trust the contents of communications, they need to be protected, ensuring
the authenticity of parties, integrity against malicious changes, and confidentiality against information
leakage. In practice, this translates to deploying up-to-date communication protocols and configuring
their security features, including cryptography. Since industry guidelines on secure TLS, Bluetooth, and
Wi-Fi change frequently, configurations should be periodically reviewed to ensure that communications
security is always effective.

• Always use TLS or equivalent strong encryption and authentication, regardless of the sensitivity of
the data being transmitted.
• Other security practices include certificate-based authentication with pinning and mutual authen-
tication.
• Use up to date configurations to enable and set the preferred order of algorithms and ciphers used
for communication.
• Disable deprecated or known insecure algorithms and ciphers.
• Use the strongest security settings available for Bluetooth and Wi-Fi communication.

Security Verification Requirements

General

# Description L1 L2 L3

4.1.1 Verify that communication with other components in the IoT ecosystem ✓ ✓ ✓
(including sensors, gateway and supporting cloud) occurs over a secure
channel in which the confidentiality and integrity of data is guaranteed
and in which protection against replay attacks is built into the
communication protocol.
4.1.2 Verify that in case TLS is used, that its securely configured with ✓ ✓ ✓
FIPS-based cipher suites (or equivalent).
4.1.3 Verify that in case TLS is used, the device cryptographically verifies the ✓ ✓ ✓
X.509 certificate.

23
OWASP IoT Security Verification Standard SNAPSHOT

# Description L1 L2 L3

4.1.4 Verify that for availability critical applications, either protection or ✓ ✓

detection of jamming is provided.
4.1.6 Verify that deviceʼs TLS implementation uses its own certificate store, ✓ ✓
pins to the endpoint certificate or public key, and disallows connections
from endpoints with different certificates or key, even if signed by a
trusted CA.
4.1.7 Verify that inter-chip communication is encrypted (e.g. Main board to ✓
daughter board communication).

Machine-to-Machine

# Description L1 L2 L3

4.2.1 Verify that unencrypted communication is limited to data and ✓ ✓ ✓

instructions that are not of a sensitive nature.
4.2.2 Verify that if shared secrets are used to cryptographically secure ✓ ✓ ✓
communication, that the same key is not hardcoded in each device or
sensor.
4.2.3 Verify MQTT brokers only allow authorized IoT devices to subscribe and ✓ ✓ ✓
publish message topics.
4.2.7 Verify certificates are favored over native username and passwords to ✓ ✓ ✓
authenticate MQTT transactions.

Bluetooth

# Description L1 L2 L3

4.3.1 Verify that pairing and discovery is blocked in Bluetooth devices except ✓ ✓ ✓
when necessary.
4.3.2 Verify that PIN or PassKey codes are not easily guessable. For example, ✓ ✓ ✓
verify PIN codes are not ʻ0000ʼor ʻ1234ʼ.
4.3.3 Verify devices that support for old versions of Bluetooth with simple ✓ ✓ ✓
modes of authentication require a PIN to pair devices.

24
OWASP IoT Security Verification Standard SNAPSHOT

# Description L1 L2 L3

4.3.4 Verify that for modern versions of Bluetooth, at least 6 digits are ✓ ✓ ✓
required for Secure Simple Pairing (SSP) authentication under all
versions except “Just Works”.
4.3.5 Verify that encryption keys are the maximum allowable size. Bluetooth ✓ ✓ ✓
has configurable key size parameters for establishing a session, with
configurations that allow keys of smaller size than the 16-32 byte size
used by AES.
4.3.6 Verify the most secure Bluetooth pairing method available is used. Verify ✓ ✓ ✓
Out Of Band (OOB), Numeric Comparison, or Passkey Entry pairing
methods are used depending on the communicating deviceʼs
capabilities.
4.3.7 Verify the strongest Bluetooth Security Mode and Level supported by the ✓ ✓ ✓
device is used. For example, for Bluetooth 4.1 devices, Security Mode 4,
Level 4 should be used to provide authenticated pairing and encryption.

Wi-Fi

# Description L1 L2 L3

4.4.1 Verify Wi-Fi connectivity is disabled unless required as part of device ✓ ✓ ✓

functionality. Devices with no need for network connectivity or which
support other types of network connectivity, such as Ethernet, should
have the Wi-Fi interface disabled.
4.4.2 Verify that WPA2 or higher is used to protect Wi-Fi communications. ✓ ✓ ✓
4.4.3 Verify that in case WPA is used, it is used with AES encryption (CCMP ✓ ✓ ✓
mode).
4.4.4 Verify that Wi-Fi Protected Setup (WPS) is not used to establish Wi-Fi ✓ ✓ ✓
connections between devices.

References

For more information, see also:

25
OWASP IoT Security Verification Standard SNAPSHOT

• OWASP Transport Layer Protection Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/

Transport_Layer_Protection_Cheat_Sheet.html
• NIST SP800-52r2 - Guidelines for the Selection, Configuration, and Use of TLS Implementations:
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r2.pdf
• IETF RFC 7525 - Recommendations for Secure Use of TLS and DTLS: https://tools.ietf.org/html/
rfc7525
• NIST SP800-121r2 - Guide to Bluetooth Security: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
NIST.SP.800-121r2.pdf
• NIST SP800-97 - Establishing Wireless Robust Security Networks: https://nvlpubs.nist.gov/
nistpubs/Legacy/SP/nistspecialpublication800-97.pdf

26
OWASP IoT Security Verification Standard SNAPSHOT

V5: Hardware Platform Requirements

Control Objective

Hardware is more difficult and more costly to compromise and subvert than software. Therefore hard-
ware security can provide a robust foundation for embedded device security. On the other hand, hard-
ware that contains backdoors or undocumented debug features can completely compromise the security
of the entire device.

The purpose of the controls listed in this chapter is to ensure that as long as hardware is available for
secure configuration, it is been configured in the most secure way possible. This includes disabling or
securing debug interfaces, setting up all existing alarms and sensor mechanisms to combat tampering,
using anti-cloning hardware protection such as OTP fuses, and the use of the MMU (Memory Management
Unit) for secure process isolation.

This chapter provides the requirements for the hardware platform, to guarantee secure configuration.
For example, 3.1.4 discusses correctly configuring secure boot. 5.1.2 requires that the platform support
this. 5.1.1 requires that the platform supports disabling debug interface. 1.2.4 requires that it is done so
in production.

Security Verification Requirements

Design

# Description L1 L2 L3

5.1.1 Verify that the platform supports disabling or protecting access to ✓ ✓

debugging interfaces (e.g. JTAG, SWD).
5.1.2 Verify that the platform supports validating the authenticity of the first ✓ ✓
stage bootloader.
5.1.3 Verify that cryptographic functions are provided by the platform. e.g. by ✓ ✓
leveraging dedicated functionality provided by the main chip or by
external security chips.
5.1.4 Verify that sensitive data such as private keys and certificates can be ✓ ✓
stored securely by leveraging dedicated hardware security features.
5.1.5 Verify that the platform provides memory and I/O protection capabilities ✓ ✓
so that only privileged processes can access certain resources.

27
OWASP IoT Security Verification Standard SNAPSHOT

# Description L1 L2 L3

5.1.6 Verify that the platform security configuration of the platform can be ✓ ✓
locked. e.g. through burning OTP fuses.
5.1.7 Verify that debugging headers are removed from PCBs. ✓ ✓
5.1.8 Verify the chosen hardware has no unofficially documented debug ✓ ✓
features, such as special pin configurations that can enable or disable
certain functionality.
5.1.9 Verify that the platform provides protection against physical ✓
decapsulation, side channel and glitching attacks.
5.1.10 Verify descriptive silkscreens are removed from PCBs ✓

References

For more information, see also:

• Common Weakness Enumeration (CWE) Hardware Design: https://cwe.mitre.org/data/definitions/

1194.html
• IoT Security - Physical and Hardware Security: https://www.embedded.com/iot-security-physical-
and-hardware-security/
• IETF RFC 8576 - IoT Security: State of the Art and Challenges (5.10 Reverse Engineering Considera-
tions): https://tools.ietf.org/html/rfc8576
• ENISA - Baseline Security Recommendations for IoT: https://www.enisa.europa.eu/publications/
baseline-security-recommendations-for-iot/at_download/fullReport
• GSMA - IoT Security Guidelines for Endpoint Systems https://www.gsma.com/iot/wp-content/
uploads/2017/10/CLP.13-v2.0.pdf
• NSA Hardware and Firmware Security Guidance: https://github.com/nsacyber/Hardware-and-
Firmware-Security-Guidance

28
OWASP IoT Security Verification Standard SNAPSHOT

Glossary

• Cryptographic material - All material, including documents, devices, or equipment that contains
cryptographic information and is essential to the encryption, decryption, or authentication of com-
munications.
• Device - Endpoint device that is capable of storing, generating, and processing data. A generic IoT
device will incorporate sensors, actuators and potentially a user interface.

• Firmware - Software that communicates with a deviceʼs hardware components through instruc-
tions and application interfaces.
• GPL - General Public License that allow freedom to use software for any purpose, freedom to
change the software, freedom to share the software, and freedom to share the changes made.
• PCB - PCB is an acronym for printed circuit board. It is a board that contains lines (traces) and
pads that connect components together via electrical signals.
• Privileged locations - An area in hardware or software that requires elevated access and permis-
sion sets.
• Security chip - Security chips provide the foundation for secure boot, secure storage, encrypting
data at rest, and are the basis for a hardware root of trust. They are often coprocessors within
system on chips (SoC) and field-programmable gate arrays (FPGA) but are also referred to as trusted
platform modules (TPM), and secure enclaves.
• Sensitive information - Data that requires protection against unauthorized access such as per-
sonal identifiable information (PII), protected health information (PHI), card holder data, private
keys, credentials, and personal data as defined by The EU General Data Protection Regulation
(GDPR).

29