OWASP ISVS: the IoT Security Verification Standard, explained

Last updated: 2026-10-29

OWASP's IoT Security Verification Standard (ISVS) is an Incubator Project framework of numbered security requirements, organised into five categories spanning the whole IoT stack — ecosystem design, user-space application, software platform, communication protocol and hardware — for teams building or assessing connected devices. Its own README describes it as "a community effort to establish an open standard of security requirements for Internet of Things (IoT) ecosystems," usable "at many stages during the Development Life Cycle including design, development, and testing." Led by project leaders Cédric Bassem and Aaron Guzman, and licensed under CC BY-SA 4.0, ISVS began life as an appendix to OWASP's own Application Security Verification Standard before growing into an independent project. As of this guide's research date, the project's GitHub repository flags its text as release candidate 1.0.0-RC2, with an explicit banner reading: "This is a release candidate under community review and may change before the final release. It is not yet a finalized standard."

Five requirement categories

Reading the current master-branch source files directly, this guide counted the following requirement totals, broken down by subsection:

Category	Requirements	Subsections
V1: IoT Ecosystem Requirements	44	Application and Ecosystem Design (6) · Supply Chain (9) · Secure Development (15) · Logging (7) · Incident Response (3) · End-of-Life and Update Support Policy (4)
V2: User Space Application Requirements	26	Identification & Authentication (13) · Authorization (4) · Data Protection (4) · Cryptography (5)
V3: Software Platform Requirements	50	Bootloader (9) · OS Configuration (11) · Linux (5) · Software Updates (13) · Security Chip Integrations (4) · Kernel Space Application Requirements (2)
V4: Communication Requirements	48	General (8) · Machine-to-Machine (3) · Bluetooth (10) · Wi-Fi (5) · Zigbee (8) · LoRaWAN (5)
V5: Hardware Platform Requirements	13	Design (13)

That totals 181 requirement rows in the version of the source this guide read on the master branch. The project's own RC2-era release notes separately describe "165 security requirements" as the RC2 baseline figure — this guide treats the gap as a sign that ISVS, like many living OWASP community documents, continues to be edited between a tagged release and its onward master branch, rather than a contradiction to resolve in either direction. Confirm the exact count against whichever specific tagged release (or dated commit) your own assessment depends on.

Three verification levels, one per assurance tier

Like OWASP's other verification standards — see our OWASP ASVS, MASVS and SCVS guides — ISVS assigns each requirement to one of three cumulative levels: Level 1 for baseline, software-only-attack resistance; Level 2, adding requirements relevant once hardware-involved attacks and more sensitive data enter scope; and Level 3, aimed at critical systems and adding defense-in-depth and anti-tampering requirements. Higher levels build on lower ones rather than replacing them — a Level 3 product is still expected to meet every Level 1 and Level 2 requirement underneath it.

What RC2 added: incident response and post-quantum cryptography

The project's own release notes for this update describe several substantive additions over the prior candidate:

A new Incident Response subsection (V1.5), covering credential-compromise handling and device-validation procedures.
Added anti-brute-force and periodic-reauthentication requirements inside V2.1 (Identification & Authentication).
Strengthened wireless requirements — Bluetooth raised to "5.3+ at L3 with mandatory 128-bit encryption and encrypted advertising," and WPA3 mandated for Level-3 Wi-Fi.
Seven new Level-3 post-quantum cryptography (PQC) requirements, spread across V2, V3 and V4, targeting algorithms including ML-KEM, ML-DSA and SLH-DSA — aligned to NIST's post-quantum cryptography standards and aimed, per the release notes, at "devices designed in 2025 with 2027+ deployment timelines."
Documentation additions covering non-conformity guidance and risk-based decision frameworks, plus corrected sequential numbering where two requirement IDs had been skipped in an earlier draft.

The same notes defer a V3 platform-requirements refresh, an overview-figure redesign, and new attack-scenario documentation to a planned 1.1 release.

How ISVS fits with ISTG and FSTM

OWASP maintains three complementary IoT/firmware projects rather than one all-in-one standard. Our OWASP Firmware Security Testing Methodology guide quotes FSTM's own framing directly: "the OWASP IoT Security Verification Standard (ISVS) defines WHAT security controls must be implemented, while FSTM defines HOW to test firmware components," while the separate IoT Security Testing Guide (ISTG) "provides additional test cases for hardware interfaces, wireless protocols, network services, and user interfaces." OWASP's own recommendation is to use all three together — ISVS as the control checklist a product should meet, ISTG for the device's broader non-firmware attack surface, and FSTM for exercising the firmware image itself — rather than treating any single project as sufficient on its own. See also our OWASP IoT Top 10 guide for the companion risk-category list these verification requirements are designed to address.

A workable starting point

Treat ISVS as pre-final. With the project's own banner stating it is "not yet a finalized standard," confirm the exact requirement text and IDs against the specific release (or master-branch commit) you cite before building a compliance claim on it.
Pick the level that matches your threat model, not the highest by default — Level 1's software-only-attack baseline is appropriate for many consumer products, while Level 3's anti-tampering and PQC requirements target critical or long-lifecycle deployments.
Start with V1 Ecosystem and V3 Software Platform. Secure development process, supply-chain handling, bootloader integrity and update mechanisms are prerequisites that the application- and communication-layer requirements in V2 and V4 build on.
Flag the new PQC requirements early for long-lifecycle devices. If a product's expected service life extends past 2027, the Level-3 ML-KEM/ML-DSA/SLH-DSA requirements are worth scoping into cryptographic design now rather than retrofitting later.
Use ISVS, ISTG and FSTM together, not interchangeably — ISVS tells you what to verify, FSTM tells you how to test the firmware image, and ISTG covers the rest of the device's attack surface.

SoftWSP's device and firmware assessments can be scoped against ISVS's five requirement categories and level structure, including the newer post-quantum cryptography requirements for long-lifecycle devices: see Device & Firmware Security.

This guide summarises the public OWASP ISVS project page, its GitHub README and release notes, and the related FSTM and IoT Top 10 publications; ISVS is explicitly a pre-final release candidate as of this guide's research date, and this summary is not a substitute for the project's own current text and does not constitute compliance or legal advice.

More guides

ENISA Guidelines for Securing the Internet of Things (supply chain), explainedENISA's November 2020 Guidelines for Securing the Internet of Things — the six-phase IoT supply chain reference model, its threat taxonomy, and the Actors/Processes/Technologies good-practice categories; reproduction authorised provided the source is acknowledged.ENISA's SBOM Technical Advisory, explainedENISA's October 2026 Technical Advisory for Software Bill of Materials: its lifecycle model, the STRIDE threat model it applies to the SBOM ecosystem, its CI/CD integration guidance, and why it is advisory rather than a legal reading of the Cyber Resilience Act.ETSI TS 103 701 (conformance assessment for consumer IoT), explainedETSI TS 103 701 V1.1.1 (August 2021) — the companion test methodology for ETSI EN 303 645: the ICS/IXIT pro formas, Device Under Test / Supplier Organization / Test Laboratory roles, conceptual vs. functional test cases, and the PASS/FAIL/INCONCLUSIVE verdict rules.

Frequently asked questions

What is OWASP ISVS?

The IoT Security Verification Standard (ISVS) is an OWASP Incubator Project, described in its own README as "a community effort to establish an open standard of security requirements for Internet of Things (IoT) ecosystems," usable "at many stages during the Development Life Cycle including design, development, and testing." It is led by project leaders **Cédric Bassem** and **Aaron Guzman**, licensed under **Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)**, and originated as an appendix inside OWASP's own [Application Security Verification Standard](/guides/owasp-asvs/) before splitting into its own project. As of this guide's research date, the project's GitHub repository flags its latest published text as **release candidate `1.0.0-RC2`**, with an explicit banner stating "This is a release candidate under community review and may change before the final release. It is not yet a finalized standard" — treat ISVS as pre-final and re-check the project's own release page before citing a specific requirement ID as stable.

What are ISVS's five requirement categories, and how many requirements does each have?

Reading the current master-branch source files directly, this guide counted: **V1 IoT Ecosystem Requirements** — 44 requirements across six subsections (Application and Ecosystem Design, Supply Chain, Secure Development, Logging, Incident Response, End-of-Life and Update Support Policy); **V2 User Space Application Requirements** — 26, across Identification & Authentication, Authorization, Data Protection and Cryptography; **V3 Software Platform Requirements** — 50, across Bootloader, OS Configuration, Linux, Software Updates, Security Chip Integrations and Kernel Space Application Requirements; **V4 Communication Requirements** — 48, across General, Machine-to-Machine, Bluetooth, Wi-Fi, Zigbee and LoRaWAN; and **V5 Hardware Platform Requirements** — 13, all under a single Design subsection. That totals 181 requirement rows in the version of the source this guide read; the project's own RC2-era release notes separately describe "165 security requirements" as the RC2 baseline, a difference this guide attributes to ISVS being a continuously-edited community document where section counts can shift between the tagged release candidate and the live master branch — confirm the exact count against the specific tagged release you depend on rather than this guide's live read.

What are ISVS's three verification levels?

Following the same L1/L2/L3 pattern as OWASP's other verification standards, ISVS organises requirements by assurance level: **Level 1** targets baseline, software-only-attack resistance; **Level 2** adds requirements relevant once hardware-involved attacks and more sensitive data are in scope; and **Level 3** is aimed at critical systems, adding defense-in-depth and anti-tampering requirements — each higher level builds on, rather than replaces, the one below. The project's RC2-era release notes describe several Level-3-only additions along this pattern, including upgrading Bluetooth to "5.3+ at L3 with mandatory 128-bit encryption and encrypted advertising" and mandating WPA3 for Level-3 Wi-Fi.

What's new in the RC2 update, and how does ISVS relate to OWASP's ISTG and FSTM?

The project's own release notes for this update describe a new **Incident Response** subsection (V1.5) covering credential compromise and device validation, added anti-brute-force and periodic-reauthentication requirements in V2.1, and — notably — **seven new Level-3 post-quantum cryptography requirements** targeting algorithms including ML-KEM, ML-DSA and SLH-DSA, aimed at "devices designed in 2025 with 2027+ deployment timelines" and aligned to NIST's post-quantum standards. On scope: our [OWASP Firmware Security Testing Methodology guide](/guides/owasp-firmware-security-testing-methodology/) quotes FSTM's own framing of the three projects together — "the OWASP IoT Security Verification Standard (ISVS) defines WHAT security controls must be implemented, while FSTM defines HOW to test firmware components" — with the separate IoT Security Testing Guide (ISTG) covering "hardware interfaces, wireless protocols, network services, and user interfaces." OWASP's recommendation is to use ISVS as the requirements checklist, ISTG for the device's broader test surface, and FSTM for the firmware image itself.