EN 40000-1-x: A sneak-peek under the hood

We’re taking a sneak-peek under the hood of the coming EN 40000-1-x family of harmonized horizontal standards using a hypothetical smart-home thermostat product.

DISCLAIMER: The EN 40000-1-x series has not yet been cited on OJEU. This article is based on various draft findings and must not be seen as legal or technical advice, but rather as inspiration for action.

The smart-home thermostat and the CRA classification

This smart-home thermostat falls into the CRA “Default” product category.

When a relevant harmonized vertical product standard exists, it must be met for the presumption of CRA conformity. These verticals are reserved for products listed as “Important Class I or II” (CRA Annex III) or “Critical” (CRA Annex IV).

But vertical harmonized product standards are not generally expected for standard smart-home thermostats unless they include specific security functionalities that elevate them to a higher risk category. If, for some reason, a thermostat is marketed as having specific security functionalities (e.g., acting as a hub for a security system – hardly likely), it could be moved to Important Class I, and a vertical standard might apply.

In this article, we’ll assume no relevant vertical, thus focusing only on the (coming) harmonized family of horizontal standards, EN 40000-1-x.

Under the hood of the EN 40000-1-x series

Before analyzing the chosen hypothetical smart-home thermostat example, let’s have a look under the hood of EN 40000-1-x. Again, based on the various draft insights collected, do have that in mind going forward.

EN 40000-1-2 defines principles for cyber resilience, a risk-based lifecycle approach, and generic activities for product development and maintenance. It is process-oriented and intended to guide risk assessment and treatment across all product stages.

EN 40000-1-4 provides a library of generic security requirements (security controls) mapped to the ESRs; it is product-oriented and gives concrete controls and assessment criteria.

EN 40000-1-3 addresses Vulnerability Handling.

This is the helicopter view of the process of producing a cyber-secure product:

Assets: What are we protecting? (Firmware, user data, hardware).

Threats: Who/what wants to harm the assets? (Unauthorized access, DoS,…).

Risk: The “Likelihood x Impact” of a threat hitting an asset.

Security Objective: The specific goal to neutralize a risk (e.g., “Ensure data integrity”).

Controls: The actual technical implementation (e.g., AES-256 encryption).

The hypothetical smart-home thermostat: Product Context

Intended purpose: residential indoor temperature control

Reasonably foreseeable use: remote control via app, integration with smart speakers

Operational environment: home Wi‑Fi, cloud backend, mobile app

Architecture: MCU + Wi‑Fi module, BLE commissioning, cloud MQTT, REST API

Users: consumers, installers, cloud operators

Data flows: Sensor → MCU → Wi‑Fi → cloud

External interfaces: Wi‑Fi, BLE, cloud API, mobile app

Landing the helicopter

After landing the helicopter, the aim of the Interactive Guide below is to convey the detailed analysis results concisely and provide you with a practical understanding of the process. It is purely hypothetical, but the aim is to open the hood, not to delve into strictly validated details. Only a fragmented analysis result is conveyed, e.g., not covering all ESRs.

We start the guide assuming that we’ve gotten the Product Context right. Click around and discover the various artifacts:

01Identify Assets

02Identify Threats

03Assess Risks

04Define Objectives

05Select Controls

06Implement Controls

07Verify Risk

Step 1: Identify Assets

We first establish what needs protection within the Thermostat ecosystem (Device, Cloud, App).

ID	Asset Category	Description
A1	Telemetry	Temperature data, user setpoints, and heating/cooling schedules.
A2	Actuation	HVAC control commands transmitted to the boiler/relay.
A3	Credentials	Wi-Fi PSK, User account passwords, and Cloud API tokens.
A4	Code	Firmware, bootloader, and sensitive configuration files.
A5	Identity	User profile (PII), email, and device serial numbers.

Step 2: Identify Threats

Mapping potential threat vectors to the assets identified in the previous step.

Asset	Threat Scenario	Threat ID
A2 Actuation	Unauthorized hijacking of temperature controls to cause discomfort/damage.	Threat.UnauthorizedAccess
A3 Credentials	Sniffing Wi-Fi credentials during the Bluetooth-to-Wi-Fi onboarding phase.	Threat.DataInTransitDisclosure
A4 Code	Attacker replaces legitimate firmware with a malicious version to create a botnet.	Threat.ProcessedDataTampering
A1 Telemetry	Insecure default settings allow public scanning of internal temperature.	Threat.UnsecureDefaultConfig

Step 3: Assess Risks

Threat Scenario	Impact	Likelihood	Initial Risk
HVAC Control Takeover (Disabling Heating in Winter)	High (Health/Safety)	Medium	High
Wi-Fi Password Theft (Network Lateral Movement)	Medium (Privacy)	Medium	Medium
Firmware Botnet (DDoS involvement)	High (Regulatory)	Low	Medium
Telemetry Leak (Privacy breach)	Low	High	Medium

Step 4: Define Security Objectives (SO)

Objectives derived to mitigate the identified risks

Asset	Primary Security Objective (SO)
A2 Actuation	SO.AccessControl, SO.ComAuth
A3 Credentials	SO.DataStoredConfidentiality, SO.SecureStartupConfig
A4 Code	SO.IntegrityProtection, SO.Updateability
A5 Identity	SO.DataMinimization, SO.SecureDataDeletion

Step 5: Select Controls (Mapping to CRA ESRs)

Selecting technical controls from the EN 40000-1-4 catalogue.

CRA Essential Requirement (ESR)	EN 40000-1-4 Controls & Descriptions
(d) Access Control	ACM-1 Applicability of access control mechanisms ACM-2 Appropriate access control mechanisms AUM-1 Applicability of authentication mechanisms AUM-2 Appropriate authentication mechanisms AUM-5-1 Requirement for factory default passwords AUM-6 Brute force protection
(e) Confidentiality	SCM-3 Confidentiality protection SCM-4 Replay protection CCK-1 Appropriate confidential cryptographic keys SSM-3 Confidentiality protection for secure storage
(c) Secure Updates	SUM-1 Applicability of update mechanisms SUM-2 Secure updates SUM-3 Automated updates UNM-4 User Security Update Notifications
(j) Attack Surface Reduction	GEC-2 Limit exposure of services via network interfaces GEC-5 No unnecessary external interfaces GEC-12 No Unneeded Software Components

Step 6: Implement Controls (Technical Spec)

Technical realization of the selected controls on the Smart Thermostat hardware.

Control ID & Name	Implementation Detail
AUM-2 Appropriate authentication mechanisms ACM-2 Appropriate access control mechanisms	Cloud API requires OAuth2 bearer tokens. Local PIN required for settings change.
SCM-3 Confidentiality protection CRY-1 Best practice cryptography	TLS 1.3 enforced for MQTT telemetry. No support for unencrypted fallback.
SSM-3 Confidentiality protection for secure storage CCK-2 Key generation mechanisms	Wi-Fi keys stored in HW Secure Element (ECC P-256). No cleartext on NAND flash.
GEC-8 Product integrity SUM-2 Secure updates	Hardware Root of Trust verifies signed firmware on every boot (Secure Boot).
GEC-10 Factory Reset	Physical reset button triggers secure erasure of the encryption key partition.

Step 7: Verify Residual Risk (Verification & RAC)

Initial High Risk	Mitigation Verification Action	Residual Risk
HVAC Hijacking	Verification: Penetration test of API + Bruteforce test on PIN login.	Acceptable (Low)
Firmware Tampering	Verification: Attempting to load an unsigned image (Secure Boot Fail Test).	Acceptable (Low)
Onboarding Sniffing	Verification: BLE traffic analysis during Wi-Fi setup phase.	Acceptable (Med)

Risk Acceptance Criteria (RAC) Met

Compliance File for CRA CE-Marking complete.

Interactive guide

Background: Not starting from a blank piece of paper

As with most standardization work, it builds upon existing achievements.

EN 40000-1-2 sources of inspiration

EN  IEC 62443‑4‑1

defines the secure development lifecycle (SDL) for industrial automation components — covering threat analysis, secure design, implementation, verification, and maintenance.

EN  40000‑1‑2

applies the same lifecycle logic to the CRA regulatory framework, translating engineering assurance into risk‑based conformity processes aligned with the Essential Security Requirements (ESRs).

EN 40000-1-4 sources of inspiration

EN 18031‑x series

was developed under the RED Delegated Act and contains the first structured, EU‑approved set of cybersecurity controls for radio equipment. It defines mechanisms (ACM, AUM, IDM, etc.) and requirements that manufacturers must implement.

EN  40000‑1‑4

inherits, generalizes, and extends EN  18031‑x. Under CRA, EN  18031‑x is not the harmonized horizontal standard. EN  40000‑1‑4 will be that for the technical controls.

EN  IEC 62443‑4‑2

defines technical security requirements for components in industrial automation systems — authentication, integrity, confidentiality, and secure communication.