This article explores the vertical standard ETSI EN 304 633© for internet-connected toys and the CRA presumption of conformity.

While currently in its draft stages, it serves as the definitive roadmap for manufacturers to ensure their playthings aren’t just fun, but CRA-compliant. As a hypothetical example illustrating EN 304 633©, we’ll use a toy robot below.

Should you not already have read the articles on

I recommend doing so.

Because ETSI EN 304 633 explicitly limits its scope to “internet-connected toys”, it is classified as a vertical standard tailored directly to the unique risks, physical operational environments, and asset types associated with toys (such as parental controls and data minimization for children). Considering the Standards sandwich, EN 304 633 is a product vertical.

DISCLAIMER: ETSI EN 304 633© has not yet been cited in OJEU as a harmonized standard. The article is based on collected draft insights and should not be seen as legal advice or technical recommendations.

Structure of EN 304 633

The primary goal of EN 304 633 is to establish harmonized cybersecurity requirements specifically for internet-connected toys. A toy falls within this scope if it has social interactive features (microphones, cameras, or speakers) or location-tracking features that communicate over the internet.

While the horizontal standard (also not yet cited in OJEU) EN 40000-1-2© provides the foundational risk management framework for all products with digital elements, EN 304 633 is a vertical standard that applies these principles specifically to internet-connected toys.

1. Determine the Product Context: EN 304 633 must define the “Intended Purpose and Reasonably Foreseeable Use” (IPRFU) for toys, including their operational environment. Also specify users and vulnerability as a key reflection point for toys.
2. Risk Acceptance Criteria: EN 304 633 must define the acceptable level of risk for toys, justified by the state of the art and regulatory factors.
3. Assets & Threats: Identifying assets (e.g., child’s voice data, location) and threats to those assets.
4. Risk treatment: EN 304 633 follows the EN 40000-1-2 priority order for risk treatment (the selection of Technical Requirements): Avoidance > Mitigation > Acceptance > Transfer. Risks inherent in the toy that cannot be mitigated must be clearly communicated to stakeholders (e.g., parents).

Infographic #1 aims to provide an overview of the standard, with examples.

To be harmonized EN 304 633 under CRA

Cybersecurity requirements for internet connected toys

Overview with examples

Section 4: Product Context

Product functions, architecture and interfaces

Requirement example Definition of functional assets, supporting systems, operational environment, and interfaces (e.g., IF.Human C for user interaction). This determines the toy's scope.

Assessment Criteria Detailed review of architecture documentation, use cases, and interfaces. Verification that all functional assets are mapped to impact classes according to Annex D.

Section 5: Technical requirements specifications

Vulnerability and Lifecycle

Known exploitable vulnerabilities & Updates

Requirement example The product shall be free of known exploitable vulnerabilities. Automatic security updates shall be enabled by default throughout the support period.

Assessment Criteria Execution of vulnerability analysis via scanning tools and verification that automatic update mechanisms are active and operational on the toy in its default state.

Default configuration and Reset

Requirement example Shipping with most secure settings and providing a functional reset to a defined secure state.

Assessment Criteria Physical and logical audit of the toy's out-of-the-box configuration and functional testing of the secure reset-to-defined-state command.

Authentication and Access

Authentication and access control mechanisms

Requirement example Use of unique credentials and restriction of functional assets (camera, mic, actuators) to authorized users to mitigate unauthorized access.

Assessment Criteria Testing protection against brute-force, token spoofing, and presentation attacks. Verification of strength levels (Basic to Strong) as specified in Annex E.

Integrity and Confidentiality

Integrity protection

Requirement example Verification of software package integrity and protection of communication for integrity-relevant data.

Assessment Criteria Cryptographic audit of software package digital signatures and analysis of communication streams to verify protection against unauthorized modification as per Annex E.

Confidentiality protection

Requirement example Protection of sensitive data (like captured audio or video) during communication and on persistent storage.

Assessment Criteria Forensic check of device persistent storage for encryption and TLS protocol analysis for confidential data in transit, matching normative levels in Annex E.

Privacy and Resilience

Data minimization and deletion

Requirement example Processing limited to essential data assets. Permanent and secure deletion mechanisms for user data.

Assessment Criteria Functional flow audit to confirm essential-only data processing and forensic verification that deletion commands permanently remove data.

Availability and Attack surface

Requirement example Resilience against network flooding (DoS) and hardening of physical and logical interfaces.

Assessment Criteria Network load testing against logical interfaces and hardware inspection to confirm the removal or disabling of physical debug headers (e.g., JTAG).

Logging and Monitoring

Requirement example Generating security logs for asset-relevant events with synchronized timestamps.

Assessment Criteria Triggering security events (e.g., failed logins) to verify automated log generation and auditing the accuracy of time synchronization (NTP).

Section 6: Vulnerability handling activities

Coordinated vulnerability handling requirements

Requirement example Establishment of requirements specifications for vulnerability handling as cited in the normative references.

Assessment Criteria Verification of manufacturer activities, inputs, and outputs against the referenced vulnerability handling standard based on documentation and record review.

Annex Summary

CRA Relationship (Informative)

Relationship between the present document and the essential requirements of EU Regulation 2024/2847 (Cyber Resilience Act).

Application Guidance (Informative)

Guidance for applying standard requirements to typical Internet Connected Toy architectures and categories.

Risk Assessment Methodology (Informative)

Information on the risk methodology used for asset impact classes and detailed threat scenarios mapping Threat Actors, Actions, and Assets.

Asset Impact Mapping (Normative)

Normative tables mapping data and function assets to their respective impact classes.

Protection Measures (Normative)

Normative strength levels (Basic to Strong) for authentication, integrity, and confidentiality mechanisms.

Risk Coverage Profiles (Informative)

Detailed view of cybersecurity risks covered or not covered by the current document.

Standard Integration (Informative)

Relationship between this document and horizontal standards ETSI EN 303 645 / ETSI TS 103 701.

Infographic #1

Meet the Robo-Pal 3000

To understand how the standard works in the real world, let’s look at a hypothetical Robo-Pal 3000, a toy robot that connects via Wi-Fi, features a camera and a mic for recognizing friends, and uses GPS so parents can find it if it’s left “somewhere”.

Determining the Scope and Profile

Under Scope, the Robo-Pal is an “internet-connected toy” because it has social interactive features (camera/mic), location tracking, and internet connection. Given that it processes video and location data, it is categorized as having a High-impact security profile.

Based on the feature set, Robo-Pal is CRA-classified as an Important Class I product. See CRA Annex III, Important products with digital elements, Class I, item 18: “Internet-connected toys … that have social interactive features (e.g. speaking or filming) or that have location tracking features.” To gain the CRA presumption of conformity, we must comply with the vertical product standard, here being EN 304 633.

Applying Technical Requirements

The manufacturer must implement specific cybersecurity controls defined in the product’s technical requirements specifications. For our Robo-Pal, these include, e.g.:

Requirement	Application to Robo-Pal
Default parental control	By default, the robot must deny the child access to security settings and restrict who can "call" the robot's speaker.
Automated updates	Since it connects to a public network, it must support and default to automated security updates to patch vulnerabilities without user intervention.
Authentication for harmful functions	The robot must verify an entity's identity (e.g., the parent's app) before allowing it to access the camera or GPS.
Secure storage	The robot must use "confidentiality-protecting secure storage" (encryption) for sensitive data like Wi-Fi passwords and user profiles.

Vulnerability Handling

The Robo-Pal must also comply with (also not yet cited in OJEU) EN 40000-1-3© for vulnerability management. This means the manufacturer must have a process for receiving, verifying, and remediating security flaws reported by researchers or discovered internally.

While ETSI EN 304 633 handles the toy’s internal security features, it delegates the “maintenance” duties to the EN 40000 series for vulnerability management.

Wrap-up

Here is a recap of some essential takeaways.

EN 304 633 is a vertical standard (not yet cited in OJEU and harmonized). It takes universal cybersecurity principles and “toys-ifies” them, focusing on the unique risks children face, such as unauthorized microphone access or location tracking.

Because Robo-Pal 3000 features social interaction (camera/mic) and tracking (GPS), a toy like the Robo-Pal is categorized as CRA Important Class I (Annex III, Pt 18). This allows manufacturers to use Module A (Internal Control) for conformity, provided they strictly adhere to this harmonized standard.

The standard’s strength lies in its modular Annex structure, which guides a product from design to the shelf on Legal & Risk, Execution, and Evidence.

By following the EN 304 633 prescriptive path, manufacturers gain a CRA presumption of conformity, legally signaling to regulators and parents alike that the toy is not just a gadget, but a secure companion for a child.

Graphics created with AI-support.