How to use ETSI EN 18031 to meet RED cybersecurity requirements

This webinar explains ETSI EN 18031 series of standards in detail and how the harmonized standard EN 18031 can be used to meet the cybersecurity requirements in Radio Equipment Directive (RED). The webinar was held by cybersecurity experts from Nemko Group, a leading provider of testing, inspection and certification services globally.

Webinar Objectives

The webinar’s key objectives were:

1. To provide a theoretical overview of the Radio Equipment Directive (RED) articles 3.3(d), 3.3(e), and 3.3(f) and their corresponding standards (EN 18031-1, EN 18031-2, and EN 18031-3).
2. To explain the structure of the standards, including the different categories, requirements, and the concept of protecting “assets” (Network, Security, Privacy, Financial).
3. To explain how EN18031 series can be used to meet RED cybersecurity requirements.

Target Audience

The detailed discussion of implementation categories, decision trees, and specific security mechanisms makes it most relevant for

1. Technical Engineers (firmware, software, security) who are responsible for implementing cybersecurity features in the product.
2. Engineering Managers who are responsible for planning and allocating time and money into the different activities around cybersecurity.
3. Certification and Regulatory managers responsible for ensuring product compliance.

It is likely too granular for business owners, product managers, supply chain managers and C-suite executives.

Presenters and their profiles:

• • Oscar Firat: A cybersecurity evaluator, from Nemko Group, who assesses products against various IoT and OT (Operational Technology) regulations. His expertise includes ETSI EN 303 645, the EN 18031 series, IEC 62443, Common Criteria, and medical device regulations.
  • Daniel Breive Havre: A cybersecurity evaluator and senior engineer, from Nemko Group.

Summary of the Webinar

Webinar Structure and Objectives

The webinar is structured in two parts:

1. Theoretical Overview: An explanation of the legal requirements of the RED and the structure of the corresponding ETSI standards.

2. Practical Workshop: A hands-on demonstration showing how to document compliance and perform the required tests, guided by a provided Excel template designed to simplify the process.

The primary objective is to equip manufacturers to understand and navigate the complex requirements for placing compliant IoT products on the European market.

Regulatory Framework: The Radio Equipment Directive (RED) cybersecurity articles

The webinar focuses on three key articles of the RED that impose cybersecurity obligations on manufacturers of internet-connected radio equipment:

• • Article 3.3(d): Network Protection: Radio equipment must not harm the network or misuse network resources, thereby causing an unacceptable degradation of service.

  • Article 3.3(e): Protection of Personal and Privacy data: Equipment must incorporate safeguards to ensure the protection of personal data, privacy of the user, and traffic/location data.

  • Article 3.3(f): Protection from Fraud: Equipment must support features to ensure protection from monetary fraud, particularly for devices that enable the transfer of money or virtual currency.

Products under scope of RED cybersecurity articles

• • Articles 3.3 (d) apply to all internet connected radio equipment. The regulation defines this as any radio equipment that can communicate over the internet, either directly or indirectly
  • Articles 3.3 (e) apply to any product that is capable of processing personal data or location data. That includes all internet connect radio equipment from above and also other specific product categories like toys, childcare equipment and wearables.
  • Articles 3.3 (f) apply to any product that can transfer money, virtual currency or items of monetary value.

The Harmonized Standards: ETSI EN 18031 Series

To prove compliance with the RED articles, manufacturers can use the harmonized ETSI standards. The webinar maps the articles to the standards as follows:

• • EN 18031-1: Covers Network Protection (Article 3.3d).

  • EN 18031-2: Covers Personal Data and Privacy (Article 3.3e).

  • EN 18031-3: Covers Protection from Fraud (Article 3.3f).

A product may need to comply with one, two, or all three standards depending on its functionality. Across the three standards, there are a total of 14 technical categories containing over 100 specific requirements.

Core Compliance Methodology

The webinar explains that the entire compliance process revolves around a structured methodology for documenting how a product meets each requirement.

1. Protecting “Assets”: The central concept is the protection of “assets,” which are defined differently depending on the standard.

   • Security Assets: Common to all standards. Includes sensitive parameters like passwords, cryptographic keys, and security functions.

   • Network Assets: Configuration data and sensitive network functions.

   • Privacy Assets: Personal data (information that can identify a person), traffic data, and location data.

   • Financial Assets: Information related to monetary transactions, such as credit card numbers or cryptocurrency details.

2. Decision Trees and Information Identifiers: For each requirement, the standard provides a decision tree—a series of binary (yes/no) questions. The manufacturer’s answers guide them through the tree. Based on the path taken, specific Information Identifiers (questions about the product’s implementation) are activated. The manufacturer must then provide detailed descriptions and justifications for their answers, explaining how their device meets the requirement.

Detailed Breakdown of Key Technical Categories

The webinar provides a deep dive into the requirements within the most important technical categories:

1. Access Control Mechanism (ACM)

This is one of the largest and most critical topics. It focuses on ensuring that only authorized entities (users, software, etc.,) can access the protected assets.

• • ACM-1 & ACM-2: Require the manufacturer to identify all access control mechanisms and ensure devices are implemented with proper authorization process.

  • Requirements for Toys & Childcare Equipment ACM-3 to ACM-6: These are particularly strict.

    • Access to external content must be restricted to authorized sources by default.

    • Third-party access to a child’s personal information must be restricted by default.

    • Parents or guardians must be given the ability to configure and restrict a child’s access to assets and functions.

2. Authentication Mechanism (AUM)

This category mandates the use of mechanisms to verify the identity of an entity trying to gain access.

• • AUM-1: Require authentication for access via both network interfaces (e.g., remote login) and user interfaces (e.g., physical screen).

  • AUM-2: Requires that devices should have at least a one factor authentication enabled on them.

  • AUM-3: The system must validate authenticators properly by using all relevant properties (e.g., if a password is used to authenticate the device must distinguish between upper and lower-case letters in the password).

  • AUM-4: Users must be able to change their authenticators (e.g., their password) except in some instances.

  • AUM-5: The requirements in this subsection address password policies. Factory default passwords must be unique per device or the user must be forced to change them on first use.

  • AUM-6: The mechanism must be resilient to brute-force attacks, for example by implementing time delays or limiting login attempts.

3. Secure Update Mechanism (SUM)

This category ensures that the product’s software and firmware can be securely updated to patch vulnerabilities.

• • SUM-1: The equipment must provide at least one update mechanism.

  • SUM-2: The mechanism must validate the integrity (the update hasn’t been corrupted) and authenticity (the update is from a legitimate source) of the new software before installation, typically using cryptographic signatures.

  • SUM-3: The update process should be automated or require minimal human intervention.

4. Secure Storage Mechanism (SSM)

This category addresses the protection of sensitive assets that are stored persistently on the device.

• • SSM-1: The equipment must use a secure storage mechanism to protect assets unless physical or logical measures in the device’s operational environment provide equivalent protection.

  • SSM-2: Stored assets must be protected with an integrity mechanism (e.g., digital signature) to prevent unauthorized modification.

  • SSM-3: Stored assets must be protected with a confidentiality mechanism (e.g., encryption) to prevent unauthorized viewing.

5. Secure Communication Mechanism (SCM)

This category ensures that data transferred to or from the device is protected against eavesdropping, tampering, and impersonation.

• • SCM-1: Requires the manufacturer to identify all communication mechanisms that transfer sensitive assets.

  • SCM-2: Communication channels must use “best practice” methods to ensure the integrity and authenticity of the data, proving it hasn’t been altered and comes from a legitimate source.

  • SCM-3: Communication channels must use “best practice” methods to ensure the confidentiality of the data, typically through encryption.

  • SCM-4: The mechanism must protect against replay attacks, where an attacker re-sends a valid data transmission. This is often solved with sequence numbers or timestamps.

6. Logging Mechanism (LGM)

This category mandates that the device records security-relevant events for later analysis.

• • LGM-1 & LGM-2: The device must have a logging mechanism that stores data about relevant events in its persistent storage.

  • LGM-3: The logs must retain a minimum number of the latest events.

  • LGM-4: Log data must include a timestamp if the device has access to real-time information.

7. Deletion Mechanism (DLM)

This category ensures that users have control over their data and can securely erase it.

• • DLM-1: The equipment must provide a mechanism that allows a user to securely delete their personal data and sensitive security parameters from the device, especially for disposal or resale.

8. User Notification Mechanism (UNM)

This category ensures users are kept informed about changes that could impact their security or privacy.

• • UNM-1 & UNM-2: The device must have a mechanism to notify the user of any changes affecting the protection of their personal data. The notification must describe the change and how it will affect them.

9. Resilience Mechanism (RSM)

This category focuses on the device’s ability to withstand network-based attacks.

• • RSM-1: The equipment must use a resilience mechanism to mitigate the effects of Denial of Service (DoS) attacks and return to a defined, stable state after the attack is over.

10. Network Monitoring & Traffic Control (NMM & TCM)

These categories apply specifically to network equipment (e.g., gateways, routers) that connect other devices to the internet.

• • NMM-1: Network equipment must provide a mechanism to monitor network traffic to detect indicators of DoS attacks.

  • TCM-1: Network equipment must provide a mechanism to control network traffic (e.g., through filtering).

11. Confidential Cryptographic Keys (CCK)

This category sets specific requirements for the cryptographic keys used within the device.

• • CCK-1: Keys must support a minimum security strength of 112 bits.

  • CCK-2: The generation of keys must follow “best practice” cryptographic standards.

  • CCK-3: Pre-installed keys must be unique per equipment.

12. General Equipment Capabilities (GEC)

This is a broad category covering overall security hygiene and best practices.

• • GEC-1: The device’s software and hardware must not contain any publicly known, exploitable vulnerabilities.

  • GEC-2: In its factory default state, the device must only expose the minimum network interfaces and services necessary for basic operation to reduce the attack surface.

  • GEC-3: Authorized users must have the option to enable and disable optional network interfaces or services.

  • GEC-4: The user documentation must describe all exposed network interfaces and services.

  • GEC-5: Unnecessary physical interfaces must be disabled.

  • GEC-6: The device must validate all data input it receives from external interfaces.

  • GEC-7: Any sensing capabilities that affect user privacy (e.g., microphones) must be documented for the user.

  • GEC-8: Equipment that processes financial data must have a secure boot process that cryptographically verifies the integrity of its software.

13. Cryptography Mechanism (CRY)

This category acts as a final check on all cryptographic operations.

• • CRY-1: All cryptography used to protect assets must adhere to “best practice” standards unless a deviation is explicitly identified and justified.

Testing and Validation

Once the documentation is complete, the product must undergo testing. The webinar outlines two main types of functional assessments:

1. Functional Completeness Assessment: The evaluator tests the device to see if it has any undocumented security-relevant functionalities.

2. Functional Sufficiency Assessment: The evaluator tests the documented security features to verify that they work as described and are effective.

Conclusions from webinar

The webinar provides a good in-depth walk through of what the RED cybersecurity regulations require and what requirements are in the harmonized standards ETSI EN 18031 series. The webinar continues to provide practical hands on training on how to perform the analysis using the standards. We will cover this in part 2 of this article.

Related content

This webinar was focused on providing an in-depth understanding of EN 18031 series of standards and how EN18031 can be used to meet RED cybersecurity requirements. We covered a similar webinar by APPLUS+ Laboratories which provides a different explanation to the same problem. We, at iotregulations.com, believe that viewing both the webinars by Nemko Group and APPLUS+ Laboratories is the perfect stepping ground to performing self-assessments using EN 18031.