In this article, we examine the draft of the vertical standard CRA EN 304 632, its scope, requirements and how to use this standard to achieve compliance.
EN 304 632 is a product-specific cybersecurity standard for smart home security products that supports compliance with the Cyber Resilience Act (CRA). The draft standard provides guidance for identifying cybersecurity risks, implementing appropriate security controls, and generating evidence that may support future CRA conformity assessments.
By translating general CRA obligations into requirements tailored to residential security products, EN 304 632 helps manufacturers address the specific cybersecurity challenges associated with this category of products and their particular threat landscape.
The scope of EN 304 632 standard covers smart home products with security functionalities (SHPSF), as defined in Commission Implementing Regulation (EU) 2025/2392, category number 17. These products protect the physical security of consumers in a residential setting and can be controlled or managed remotely from other systems, as well as hardware and software that centrally control such products:
Smart door locking devices
products with digital elements that control physical access to a residence, including exterior locks, interior locks, and object locks for securing valuables.
Baby monitoring systems
products with digital elements that monitor the presence or activity of persons (especially infants) in a residential setting, using audio/video input, motion detection, or fall detection.
Alarm systems
products with digital elements that detect hazardous situations (intrusion, fire, gas, hold-up) and notify users or trigger actuator responses (sirens, lights).
Home security cameras
products with digital elements that capture video and/or audio for residential physical security purposes.
Central control hardware and software
gateways, mobile applications, and cloud-based Remote Data Processing Solutions (RDPS) that centrally control or manage the above products.
Some examples of products included but not limited to are:
It is important to notice that smart home products are only covered when they provide a residential physical security function as defined in clause 4. Products with digital elements that do not provide such functions — for example, a generic smart speaker without security functionality — are not in scope.
The structure can be understood through the following key blocks:
Clause 1 — Scope: defines which products fall within scope and which are excluded.
Clause 2 — References: normative references (prEN 40000-1-3 for vulnerability handling, Agreed Cryptographic Mechanisms) and informative references (CRA Regulation, implementing regulations, etc.).
Clause 3 — Definitions: extensive glossary of architecture-related terms, asset categories, communication types, data asset types, function asset types, interface types, operational environments, and user categories — all specific to smart home security products.
Clause 4 — Product context: describes the product functions (residential physical security functions and supporting functions), product architecture (hardware/software architectural components), operational environments (fully controlled, partially controlled, mobile), interfaces (human, machine, logical, physical), and user categories (consumers, service providers, manufacturers).
Clause 5 — Requirements specifications: the core technical requirements for the product, organized into 12 requirement groups.
Clause 6 — Assessment criteria: detailed compliance verification procedures for each requirement.
Annexes:
EN 304 632 covers 12 groups of technical requirements for smart home security products:
Vulnerability Handling Conformity for smart home security products is based on the baseline requirements referenced from the horizontal standard plus product-specific considerations.
The harmonized standard dictates that the product manufacturer is expected to implement vulnerability handling processes according to CEN/CLC JT013090:2026 (prEN 40000-1-3) "Cybersecurity requirements for products with digital elements – Vulnerability Handling", so this document shall also be consulted.
The standard requires compliance with prEN 40000-1-3 for the SHPSF, and additionally specifies that products must have no known exploitable vulnerabilities at the time of market launch (NKEV-MKAV). Vulnerabilities that emerge after launch are subject to the ongoing vulnerability handling processes defined in prEN 40000-1-3.
The EN 304 632 standard has been created to comply with the CRA and understand the essential cybersecurity requirements for smart home products with security functionalities. The requirements in this document follow a risk-based approach, applying conditionally to ensure that security measures are appropriate to the deployment context and level of threat exposure.
Smart home products with security functionalities must comply with the standard when they provide residential physical security functions. Products without security functionality are not in scope.
To determine which requirements are applicable to a specific product, the standard provides a structured approach based on impact classes:
It would be reasonable to determine that a battery-powered door sensor (low confidentiality impact, local communication only, fully controlled environment) requires lower protection levels than a cloud-connected security camera (high confidentiality impact, public communication, mobile deployment).
When the risk assessment has been determined, the next step is analyzing which cybersecurity requirements are applicable. Tables with a mapping between impact classes and requirements are included to understand which requirements have to be applied. Some of the requirements have been defined specifically for smart home security products while others — such as no known exploitable vulnerabilities and state-of-the-art cryptography — are addressed by applying the requirements described in horizontal standards.
All the stakeholders related with smart home products with digital elements will be impacted directly or indirectly by CRA requirements:
Product teams
shall establish roadmaps to ensure that the products are designed, developed, and produced considering the necessary cybersecurity requirements. This includes implementing secure update mechanisms, access control, integrity/confidentiality protection, logging, and secure boot. They shall also establish procedures to enforce all the necessary requirements for the product, including those related to documentation, default configurations, and vulnerability management. Products with time-sensitive functions (e.g., real-time alarm transmission) must carefully balance update scheduling against availability requirements.
Security teams
from product companies shall now ensure a secure lifecycle for every product with digital elements, including vulnerability handling and enforcement of security requirements throughout all the product lifecycle. They must ensure that preinstalled passwords and cryptographic keys are unique per device, that logging mechanisms capture appropriate events at the correct impact level, and that log files are backed up to a separate physical location for high-impact products.
Legal and compliance teams
will have to elaborate the EU declaration of conformity as well as many other obligations, such as providing related manufacturer information (name, trademark, contact details) and declaration of conformity (original or simplified), or keeping the technical documentation and the EU declaration of conformity at the disposal of the market surveillance authorities for at least 10 years or for the support period, etc.
The most significant impact for users
is that it improves a better understanding and access to information related to the cybersecurity of a product. Users must carefully read Annex II of Regulation (EU) 2024/2847 to verify that all the elements that shall accompany the product are provided. These elements include unique identification information about the product, contact points to receive and report vulnerabilities, security properties information, how updates are received and installed, etc. Users will also benefit from clear, distinct security notifications and visual indicators for security-related configuration changes.
EN 304 632 requirements overlap significantly with the horizontally applicable EN 18031 series (ICT product cybersecurity). Of the 51 technical requirements, approximately 15 (29%) can largely reuse EN 18031 test methods and results, 24 (47%) require partial supplementation, and 12 (24%) demand entirely new testing capabilities.
Three representative examples illustrate the reuse model:
Example 1 — [AUM-FH] Authentication (Basic Coverage, reuse ~80%)
EN 304 632 requires authentication for functions whose use can cause harm, with strength levels determined by a matrix of impact class × attack surface. EN 18031 AUM-1 through AUM-6 provide comprehensive coverage of authentication mechanisms across all three parts. The core test methodology — conceptual assessment, functional completeness, functional sufficiency — is directly reusable.
What's new in EN 304 632: a four-tier strength classification (Basic / Normal / Enhanced / Strong) with specific attack-type coverage per tier (e.g., Enhanced must resist person-in-the-middle attacks, Strong must resist elaborate security token spoofing). The test plan reuses EN 18031 authentication test cases as the baseline, then supplements with Annex E attack-type-specific tests for each applicable strength level.
Example 2 — [SDC-AUM-FH] Default Authentication Configuration (Partial Coverage, reuse ~50%)
EN 304 632 requires that products ship with authentication mechanisms enabled at the appropriate strength level by default. EN 18031 AUM-2 requires that authentication mechanisms exist and are properly implemented, but does not mandate that they be enabled in the factory default state.
The test plan reuses EN 18031's authentication mechanism verification, but adds a mandatory default-state inspection step: restore the product to factory defaults, then verify that (1) authentication is active, (2) the strength level matches the required matrix entry, and (3) no configuration bypass is available without authentication. This supplementary step requires approximately 4 additional test hours per product variant.
Example 3 — [AVAI-TIME-RECO-POW] Restoration After Power Loss (No Coverage, 0% reuse)
EN 304 632 requires that hardware architectural components resume connectivity and functionality as soon as power supply is restored after a loss of power. EN 18031 has no equivalent requirement — this is specific to smart home security products where power interruptions directly impact physical security (e.g., a smart lock must re-establish its functions after a power outage).
The test plan requires entirely new capability: a controlled power-cycling test rig, measurement of recovery time from power restoration to full operational state, and verification that all time-sensitive security functions (lock control, alarm transmission, sensor polling) resume within acceptable bounds. Estimated development: 16 person-hours for test procedure + 4 hours per product test execution.
Consider a smart door lock with the following characteristics:
| Requirement | Applicable Control | Evidence |
|---|---|---|
| [AUM-FH] Authentication | AUTH.Enhanced authentication for remote unlock via public communication | Test: attempt unlock without authentication; verify rejection. Test: verify authentication strength meets Enhanced level (see Annex E.1.1.4) |
| [SDC-AUM-FH] Default config | Authentication enabled by default in factory state | Inspection: inspect product in default configuration; verify authentication is required |
| [NKEV-SUM-AUTO] Auto updates | Automated security update mechanism | Test: connect to internet; verify updates are downloaded and installed without user intervention |
| [AVAI-TIME-OUTA-NOT] Non-availability notification | Warn user before/during unavailability of lock function | Test: simulate power loss; verify notification is sent to user |
| [AVAI-TIME-RES-PRIO] Power prioritization | Prioritize lock function during low battery | Test: simulate low battery; verify lock function is prioritized over non-critical functions |
| [LOG-HIGH] Logging | Log all authentication attempts and access attempts | Inspection: verify log files contain timestamps, authentication events, and access attempts |
| [INT-SWPCK] Software integrity | Verify integrity and authenticity of software packages before installation | Test: attempt to install unsigned package; verify rejection |
| [CONF-SSM] Secure storage | Confidentiality-protecting storage for cryptographic keys | Test: verify cryptographic keys are stored using mechanisms meeting CONF.SSM.Normal strength (partially controlled environment) |
Applus+ uses first-party and third-party cookies for analytical purposes and to show you personalized advertising based on a profile drawn up based on your browsing habits (eg. visited websites). You can accept all cookies by pressing the "Accept" button or configure or reject their use. Consult our Cookies Policy for more information.
They allow the operation of the website, loading media content and its security. See the cookies we store in our Cookies Policy.
They allow us to know how you interact with the website, the number of visits in the different sections and to create statistics to improve our business practices. See the cookies we store in our Cookies Policy.
Based on your behavior on the website (where you click, how long you browse, etc.) we establish parameters and a profile for you to display ads that correspond to your interests. See the cookies we store in our Cookies Policy.