In this article, we examine the draft of the vertical standard CRA EN 304 633, its scope, requirements and how to use this standard to achieve compliance.
ETSI EN 304 633 is a product-specific cybersecurity standard, currently under development, designed to support compliance with the EU Cyber Resilience Act (CRA) for internet connected toys. The standard applies to products such as social interaction toys and location-tracking toys, translating the CRA’s general cybersecurity obligations into practical and assessable technical requirements for manufacturers.
As the CRA moves towards full application, manufacturers placing internet connected toys on the European market will need to demonstrate that their products meet essential cybersecurity requirements throughout their lifecycle. EN 304 633 provides a structured framework to help achieve this, covering areas such as secure default configurations, parental controls, vulnerability management, software updates, data protection, and security assessments.
Although the standard is still under development, it provides an early indication of how CRA requirements may be applied to internet connected toys and how future conformity assessments could be structured. This guide explains the scope, structure, and key requirements of EN 304 633, helping manufacturers understand how the standard fits within the broader CRA compliance framework.
ETSI EN 304 633 applies to two categories of internet-connected toys:
Social Interaction Toys
Toys with microphones, speakers and cameras supporting two-way communication.
Location Tracking Toys
Toys with GPS or location tracking capabilities.
A defining feature of this standard is its focus on the guardian-child relationship. Unlike general-purpose IoT devices, smart connected toys must implement parental controls that allow guardians to manage children’s access to security settings, external content sources, and communication entities. This is a unique requirement that sets EN 304 633 apart from other vertical standards.
Understanding the document structure helps you navigate the standard efficiently:
Chapter 4
Product Context & Impact Level Framework
Defines how to classify your product’s operational environment and determine its impact level across five dimensions: Functional Harm, Integrity, Confidentiality, Availability-Time and Availability-Loss.
Chapter 5
54 Security Requirements in 12 Categories
Contains the core technical requirements organized by functional domain. This is where the main implementation work happens.
Chapter 6
Assessment Criteria
Defines how each requirement is tested, including assessment objectives, preparation, activities and verdict assignment.
Annex C
Impact Level Definitions
Provides detailed criteria for Low, Medium and High levels across all five impact dimensions.
Annex D
Data & Function Asset Taxonomy
Lists pre-classified assets with their impact levels and provides a starting point for product assessment.
Annex E
Assessment Strength Tables
Contains seven lookup tables, Tables 2 to 8, that determine the required strength of security controls based on the product’s impact level and attack surface.
Key insight: For manufacturers of internet connected toys, the Impact Level is the central mechanism. Your product’s classification across five dimensions directly determines which of the 54 requirements apply and at what strength level. Spend time on Chapter 4 and Annex C. Getting this right upstream saves significant effort downstream.
Rather than listing all 54 requirements in ETSI EN 304 633, here is a summary of the 12 requirement categories and their core principles:
1. Known Exploitable Vulnerabilities (NKEV)
5 requirements. No known exploitable vulnerabilities at market release; maintain secure update capability throughout the product lifecycle. Covers vulnerability management, software update support, auto-updates, update notifications and core component updates.
2. Secure Default Configuration (SDC)
5 requirements. The product must be secure out of the box. Covers default authentication for harmful functions, auto-updates enabled by default, update notifications enabled by default, factory reset capability and default parental control restrictions.
3. Access Control & Authentication (ACM/AUM)
6 requirements. Only authorized entities can access functions that could cause harm. Includes access control, parental control support, authentication strength, least privilege, revocable permissions and guardian-child authorization differentiation.
4. Integrity Protection (INT)
2 requirements. Prevent unauthorized tampering of software and data. Covers software package verification in Table 4 and integrity-protected communication in Table 5.
5. Confidentiality Protection (CONF)
2 requirements. Protect sensitive data from unauthorized access. Covers secure storage in Table 6 and communication protection in Table 7.
6. Data Minimization (DMIN)
1 requirement. Only process confidential data according to its stated intended purpose. Documented justification is required.
7. Availability Protection (AVAI)
10 requirements. Ensure critical functions remain operational under failure and attack scenarios. Covers power-loss recovery, local operation during network loss, reconnection, unavailability notifications, resource prioritization, amplification control, DoS rate limiting and update scheduling.
8. Attack Surface Limitation (LAS)
6 requirements. Minimize exposed interfaces and applications. Covers input validation, input sanitization, physical and logical interface minimization, application minimization and secure boot.
9. Logging & Monitoring (LOG)
7 requirements. Provide audit trails for security event detection and investigation. Covers three tiered log levels, timestamps, persistent storage and automatic backup.
10. Deletion Mechanism (DLM)
1 requirement. Support permanent deletion of user-related data, including subsets, with an easy-to-use mechanism.
11. Other Technical Requirements
9 requirements. Ensure a secure user experience. Covers security function availability notifications, clear security notification language, GUI security configuration visualization, state-of-the-art cryptography, key length requirements and password complexity rules.
12. Vulnerability Handling
References prEN 40000-1-3 for a complete six-stage vulnerability management lifecycle, explained in the following section.
ETSI EN 304 633 does not reinvent vulnerability handling. Instead, it references prEN 40000-1-3 (CEN/CLC JT013090:2026) as the technical specification for vulnerability management. This is both a standard requirement and a direct CRA regulatory obligation effective September 11, 2026.
The prEN 40000-1-3 framework consists of six stages:
| Stage | Key Activities | Your Obligation |
|---|---|---|
| Preparation | Establish vulnerability handling strategy; form PSIRT team; publicize reporting channels | Must be completed before September 2026 |
| Receipt | Provide discoverable reporting mechanism; acknowledge receipt within 5 working days | Receive reports from global security researchers |
| Verification | Validate exploitability; assess CVSS impact score | Technical validation for each valid report |
| Remediation | Develop patches; conduct verification testing | Provide fixes within a reasonable timeframe |
| Release | Publish advisories with CVE ID; provide patches; coordinate disclosure | Transparent and timely disclosure |
| Post-release | Monitor patch adoption; update documentation | Continuous improvement |
Bottom line: If you comply with prEN 40000-1-3, you are presumed to comply with both the EN 304 633 requirement NKEV-MKAV and the CRA vulnerability reporting obligation. Establish your PSIRT team and public reporting channel before September 2026. This is not optional.
If you are just beginning your EN 304 633 compliance journey, prioritize these three actions:
Action 1: Complete Your Impact Level Self-Assessment
Use Chapter 4 and Annex C of the standard to classify your product across the five impact dimensions. This single exercise determines which of the 54 requirements apply to your connected toy and at what strength level. Getting this right early prevents both over-engineering, by implementing stronger controls than necessary, and under-engineering, by missing requirements that do apply.
Action 2: Build Your SBOM and Document Your Update Mechanisms
Generate a complete Software Bill of Materials (SBOM) in SPDX or CycloneDX format, and document the update mechanism for every software component. These two artifacts are prerequisites for multiple requirements, including NKEV-SUM-SUPPORT, NKEV-SUM-PROVIDE and NKEV-SUM-AUTO, and are among the first things a Notified Body will request.
Action 3: Establish Your PSIRT Team and Public Vulnerability Reporting Channel
With the September 2026 deadline approaching, this is the most time-sensitive action. You need: a dedicated Product Security Incident Response Team with clear responsibilities; a publicly accessible vulnerability reporting page on your website; and an internal cross-departmental response process connecting R&D, Security, Legal and PR.
Product/R&D Teams
Key impact: Must redesign internet connected toys for secure-by-default; all 54 requirements affect product design decisions.
Action required: Integrate security requirements into the product design phase and conduct the impact level assessment before feature freeze.
Security Teams
Key impact: Must build vulnerability handling capability through a PSIRT and prepare for assessment.
Action required: Establish a PSIRT; prepare an SBOM, vulnerability handling policy and CVD policy; and build internal testing capability.
Legal/Compliance Teams
Key impact: Must track the regulatory timeline and coordinate standard updates.
Action required: Monitor ETSI and the EU Official Journal for standard updates and prepare EU Declaration of Conformity templates.
Customers (Guardians)
Key impact: Gain stronger privacy protections and parental controls.
Expected outcome: Improved security features, including parental controls, clear security notifications and data deletion options.
To illustrate how an ETSI EN 304 633 requirement translates from regulation to implementation and evidence, consider NKEV-SUM-AUTO (Automated Security Updates):
| Step | Detail |
|---|---|
| Requirement | “Where the internet connected toy has the capability to connect to a public network, the internet connected toy shall support the automated update of its software.” |
| Applicable Condition | Your product connects to a public network, for example through Wi-Fi to a cloud service. |
| Control Implementation | Implement an automatic update mechanism that: (1) checks for updates from your update server; (2) downloads updates automatically; (3) installs updates without user intervention; and (4) verifies update integrity before installation. |
| Assessment Evidence | A test report documenting that: (1) the update server was configured with a new software version; (2) the product automatically detected, downloaded and installed the update without human intervention; (3) the software version changed as expected; and (4) an update log entry was generated. |
Note: This requirement maps to EN 18031-2 [SUM-3], meaning that if you have already completed an EN 18031 assessment, this test result can be directly reused as EN 304 633 compliance evidence.
For manufacturers who have completed or plan to complete an EN 18031 assessment under the RED Directive cybersecurity framework, the reuse breakdown is:
| Reuse Category | Count | Description |
|---|---|---|
| Efficient Reuse | 15 | EN 18031 assessment results directly satisfy EN 304 633 requirements; no additional testing. |
| Conditional Reuse | 19 | EN 18031 covers the baseline; supplementary testing is needed for EN 304 633 incremental requirements. |
| New Assessment | 19 | EN 18031 does not cover these requirements; full independent testing is required. |
| DLM-PERM | 1 | Added as the 54th requirement; it was a gap in the original gap analysis table. |
The 19 “New Assessment” items concentrate in availability protection, with 10 requirements, and default configuration, with 3 requirements. These are areas where CRA vertical standards go beyond the scope of RED.
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.