ENISA Baseline Security Recommendations for IoT (2017), explained

ENISA's "Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures" is the EU cybersecurity agency's first major attempt to lay out, horizontally across every IoT sector, what the asset classes, threats, gaps and recommended good practices actually are. Published 20 November 2017 by the European Union Agency for Network and Information Security (ENISA — renamed the EU Agency for Cybersecurity in 2019, but still operating under the ENISA acronym), the report predates the device-specific regulatory wave that followed — ETSI EN 303 645, NIST's NISTIR 8259 series, the EU Cyber Resilience Act — and remains a useful reference for its asset taxonomy, threat taxonomy, and gap analysis, even as a 2017-era document whose specific recommendations have since been superseded by more prescriptive instruments.

Why ENISA tackled IoT horizontally instead of sector by sector

The report's Introduction explains the methodological choice directly: ENISA had already published a series of vertical IoT security studies — Smart Homes, Smart Cities and Intelligent Public Transport, Smart Grids, Smart Cars, Smart Airports, and eHealth and Smart Hospitals — but "a major challenge in defining baseline security measures for IoT is the entailed complexity that is brought by the diversity of application areas for IoT." Rather than adding another vertical study, this report "considers the horizontal aspects of IoT as seen across vertical sectors," aiming to define security measures that apply regardless of whether the deployment is a smart grid substation or a connected hospital device.

The report frames its own stakes starkly: "attacks on IoT deployments could dramatically jeopardise people's security, privacy and safety, while additionally IoT in itself can be used as an attack vector against other critical infrastructures." Its findings were grounded in 26 structured interviews with experts from industry, policy, academia and research across 9 EU member states and the US, synthesized into a release candidate that was then discussed and finalized at an ENISA IoT Security Experts Group (IoTSEC) workshop in The Hague on 20 October 2017.

The IoT asset taxonomy

Section 2.5 breaks the IoT ecosystem into a reference model (Figure 4), synthesized from eight existing architectures the report reviewed — including the AIOTI High Level Architecture, the FP7 IoT-A Architectural Reference Model, NIST's Network of Things, the ITU-T IoT reference model, and ISO/IEC CD 30141 — then maps assets against it (Table 2):

Asset group	Assets
IoT Devices	Hardware, Software (OS/firmware/applications), Sensors, Actuators
Other IoT Ecosystem Devices	Devices to interface with Things, Devices to manage Things, Embedded systems
Communications	Networks, Protocols, Infrastructure (routers, gateways)
Applications & Services	Data analytics and visualisation, Device and network management, Device usage
Information	At rest, In transit, In use

Based on expert-interview criticality ratings (Figure 6), the report found sensors, then device and network management controls, then communication protocols, gateways and applications/services rated as the most critical assets, each flagged critical by "at least two thirds or more of the experts interviewed" — a ranking the report explicitly caveats as horizontal and likely to shift for any specific vertical deployment.

The threat taxonomy and attack scenarios

Section 3.2 builds a threat taxonomy "consistent with the ENISA Threat Taxonomy," organizing concrete IoT threats under categories including Nefarious Activity/Abuse — malware, exploit kits, targeted attacks, distributed denial of service (DDoS), counterfeit malicious devices, attacks on privacy, and modification of information — each mapped (Table 3) to the specific asset groups it affects. Expert-weighted impact scoring (Figure 10) rated the overall average threat impact at 3.7 out of 5, with individual threats such as sensitive data leakage/modification (4.2/5), DDoS (4.2/5), and weak passwords (4.1/5) scored among the highest-impact.

Chapter 3 develops three critical attack scenarios in detail — IoT administration system compromise, value manipulation in IoT devices, and botnet/commands injection — chosen, per the report, for their combination of high likelihood and high impact across the asset taxonomy above.

Security measures: four categories, dozens of good practices

Chapter 4 and Annex A lay out detailed good practices (each with a GP-xx-nn identifier) organized under Policies (security/privacy by design, asset management, risk and threat identification), Organisational/People/Process measures (end-of-life support, vulnerability/incident management, HR security training, third-party relationships), and Technical Measures spanning hardware security, trust and integrity management, strong default security and privacy, authentication, authorisation, cryptography, secure communications, logging, and monitoring/auditing. Two worked examples from Annex A: GP-TM-55 requires implementing "a logging system that records events relating to user authentication, management of accounts and access rights, modifications to security rules, and the functioning of the system," with logs "preserved on durable storage and retrievable via authenticated connections"; GP-TM-57 recommends performing "periodic audits and reviews of security controls" and running "penetration tests at least biannually." Each good practice is cross-referenced (Annex A's reference column) against contemporaneous standards and guidance the report reviewed, including ISO/IEC 27001, NIST SP 800-53, OWASP's Security by Design Principles, GSMA's IoT Security Guidelines, and the IoT Security Foundation.

Six gaps, and seven recommendations to close them

Chapter 5 identifies six gaps the report's interviews and literature review surfaced as the most prominent barriers to IoT security maturity:

1. Fragmentation in existing security approaches and regulations — "no common EU-wide approach to cyber security in IoT," leaving manufacturers to take their own ad hoc approach.
2. Lack of awareness and knowledge — including, notably, "differences in fundamental terminology" around safety versus security even among security professionals themselves.
3. Insecure design and/or development — evidenced by recurring real-world issues: "public vulnerabilities ... left unfixed," services "exposed through different entry points, with unnecessary communication ports left open," and "weak passwords policies or default passwords left unchanged."
4. Lack of interoperability across IoT devices, platforms and frameworks, worsened by manufacturer-proprietary protocols.
5. Lack of economic incentives for manufacturers to absorb the cost of security features.
6. Lack of proper product lifecycle management, spanning patching, updates, and secure deployment practices.

Chapter 6 (Table 8) then maps each gap to one of seven high-level recommendations, each addressed to a named set of stakeholders:

#	Recommendation	Addressed to
1	Promote harmonization of IoT security initiatives and regulations	Industry, providers, manufacturers, associations
2	Raise awareness for the need for IoT cybersecurity	Industry, providers, manufacturers, associations, academia, consumer groups, regulators
3	Define secure software/hardware development lifecycle guidelines for IoT	Developers, platform operators, industry
4	Achieve consensus for interoperability across the IoT ecosystem	Industry, providers, manufacturers, associations, regulators
5	Foster economic and administrative incentives for IoT security	Industry, associations, academia, consumer groups, regulators
6	Establishment of secure IoT product/service lifecycle management	Developers, platform operators, industry, manufacturers
7	Clarify liability among IoT stakeholders	Industry, regulators

Recommendation 6 is worth quoting directly for how closely it anticipates requirements formalized years later: security updates "need to be provided where practically possible without special knowledge requirements or financial obligations on the end user/consumer within a defined term and conditions until 'end-of-support,'" and that end-of-support date "must be clearly defined by the manufacturer/provider ... and must be clearly communicated to the end user/consumer" — language that prefigures the support-period disclosure obligations later written into instruments like the EU Cyber Resilience Act and EN 18031.

Where this 2017 report sits today

This is a 2017 horizontal reference document, not a current conformance baseline. ENISA's own Legal Notice states the publication "does not necessarily represent state-of-the-art and ENISA may update it from time to time" — and the specific good practices in Annex A predate testable, certifiable standards such as ETSI EN 303 645 (2020) and NIST's NISTIR 8259 series, as well as ENISA's own later, narrower Guidelines for Securing the IoT Supply Chain (2020) and SBOM Technical Advisory. Its continuing value is as the vocabulary and problem-framing layer underneath that later work — the asset taxonomy, threat taxonomy and gap analysis a team can use to scope an IoT security program before mapping onto a certifiable standard.

A workable starting point

1. Use the asset taxonomy to scope a review, not to certify one. Table 2's four asset groups (devices, other ecosystem devices, communications, applications/services/information) give a quick checklist for making sure a security review hasn't silently left out gateways, management interfaces, or data-in-use — but this report sets no pass/fail bar the way EN 303 645 or EN 18031 do.
2. Treat the six gaps as a maturity self-check. If your organization can't point to concrete mitigations for fragmentation, awareness, insecure design, interoperability, incentives, and lifecycle management, you likely have real exposure on all six — the report's gap list still reads as current for many smaller IoT manufacturers in 2026.
3. Don't cite this report's good practices as a certification baseline. For consumer IoT, go to ETSI EN 303 645; for supply-chain specifics, go to ENISA's own 2020 IoT supply chain guidelines — use this 2017 report for the underlying threat model and vocabulary, not as the compliance target itself.
4. Reuse its end-of-support disclosure language as a floor, not a ceiling. Recommendation 6's call for a clearly communicated, no-extra-cost update commitment until a defined end-of-support date is now a regulatory requirement in several markets — restating it internally as policy is a useful way to confirm current practice already meets what was, in 2017, only a recommendation.
5. Reproduction is authorised, with attribution. ENISA's own Copyright Notice states "Reproduction is authorised provided the source is acknowledged" — a lower bar than many standards bodies' paywalled texts, making this report genuinely citable in full rather than only in short quotations.

SoftWSP's firmware and device security assessments map directly onto this report's asset taxonomy — hardware, firmware, communications protocols and backend services — and its named gaps around insecure design, patching and lifecycle management: see Device & Firmware Security.

This guide quotes ENISA's own published text of "Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures" (November 2017): Executive Summary, Introduction, Section 2 (IoT paradigm, architecture, asset taxonomy), Section 3 (threats and risk analysis), Chapter 4 and Annex A (security measures and good practices), Chapter 5 (gaps analysis), and Chapter 6 (high-level recommendations). It is not a substitute for the full 103-page report, and does not constitute compliance or certification advice.