ENISA Good Practices for Security of IoT: Secure Software Development Lifecycle, explained

Section 1 of the report notes that when ENISA's consulted experts were asked how many phases the SDLC comprises, "the vast majority of them considered that the SDLC comprises up to six phases." Section 2 addresses each in turn:

Section 2.7, "Security in SDLC," layers a cross-cutting discipline on top of all six phases: security maturity assessment (the report names Common Criteria, CMMI, BSIMM, IEC 62443-4-1 and OpenSAMM as reference models), security gates with defined metrics between phases, and continuous documentation management — the report calls documentation "a cross-cutting activity during the SDLC process that is often not considered as essential" despite its role in making a complex IoT build "understandable, traceable, and subject to monitoring and auditing."

Chapter 3 opens with an asset taxonomy (Table 1), grouping what needs protecting into categories including Human Factor (Business Owners/BI analysts, Software Team roles such as Testers/Integrators/Developers/Architects/Designers, Security Team roles such as the CISO/security engineers/penetration testers/incident responders, Operators, End Users, Contractors, and Decision Makers), Software Design assets (business and security requirements, metrics, quality gateways, use cases, specifications, design tools), and Software Development assets (underlying hardware components, firmware, operating systems, compilers and simulation environments). The report is explicit that "the lowest level of the taxonomy is indicative and not exhaustive" — it is a working reference, not a closed list.

Section 3.2 builds a corresponding threat taxonomy, and Section 3.3 grounds both taxonomies in three worked attack scenarios: Insecure Credentials in Embedded Devices, Lack of Flexibility to Secure Communications, and Insecure Software Dependencies in Cloud Services — each walked through to show which assets and SDLC phases a realistic attack chain touches.

Section 4.2 explains the methodology behind the report's central deliverable: "extensive desktop research" plus stakeholder interviews produced "a list of 16 domains that provide a comprehensive view of the Secure IoT SDLC landscape," organized into three groups:

Each domain contains individually numbered practices with a short description — for example, under Training and Awareness: PE-01 "define a corporate strategy for specific security training," PE-02 "promote security awareness at all organisation levels," PE-03 assess whether security skills need updating, and PE-04 allocate resources to track emerging security topics. Annex A maps every numbered practice in full detail to the threats and external references it addresses, which is where a team building an actual compliance or audit checklist from this report should start.

ENISA's report is explicitly positioned as one building block among several, not a standalone framework: it names OWASP IoT Top 10, the OWASP Application Security Verification Standard, and the SAFECode Fundamental Practices for Secure Software Development paper among its own supporting references, and Section 2.7 points to IEC 62443-4-1 as one of several maturity models a team can use to benchmark its own secure-development process. A device maker following OWASP's firmware security testing methodology or working toward IEC 62443-4-1 secure-development-lifecycle conformance will recognize most of this report's 16 domains already — ENISA's contribution is organizing them specifically around the IoT asset and threat taxonomy in Chapter 3, rather than introducing a competing scheme. ENISA's 2020 Guidelines for Securing the Internet of Things report, in turn, explicitly builds on this one, extending the same good-practice logic from the software process out to the full physical-and-logical IoT supply chain (semiconductor fabrication, component manufacturing, distribution), and a 2017 ENISA baseline study on IoT security recommendations set the horizontal context both narrower studies refine.

No regulation known to us names this specific ENISA report as a required control for any legal duty — treat any claim that following it satisfies a specific regulatory requirement (such as the EU Cyber Resilience Act's secure-development obligations) as to be confirmed against the actual regulatory text, not assumed from this guide. Where the report earns its keep is as a free, structured gap-analysis tool: a team can walk its own six-phase SDLC against the report's 16 domains, see which of the People/Processes/Technologies practices it already has evidence for, and use the gaps to prioritize where a firmware SBOM or dependency review would close the most exposure fastest, since Chapter 3's threat taxonomy consistently ties insecure third-party and legacy dependencies to concrete attack scenarios.