EU CRA Reporting for Connected Toys: Can Your Team Beat the 24-Hour Clock?

A vulnerability report arrives at 16:40 in Europe. The researcher names a Bluetooth chipset, but not the toy models using it. The Shenzhen factory has closed for the day. The firmware house says three builds may be affected; the app agency owns the signing account; and nobody is sure who can file the regulatory notification.

That is the real Cyber Resilience Act challenge for connected toys. It is not simply knowing the law. It is moving from a first signal to a defensible decision while evidence is incomplete and responsibilities are split across companies and time zones.

The EU Cyber Resilience Act (CRA) reporting obligations have applied since 11 September 2026. The Act's main product obligations apply from 11 December 2027. According to the European Commission's CRA overview, the regulation entered into force on 10 December 2024. Manufacturers now have to report actively exploited vulnerabilities and severe incidents affecting products with digital elements through ENISA's Single Reporting Platform (SRP).

For a connected-toy team, readiness starts with a product-control system: which model contains which hardware, firmware, app, cloud service and third-party component; who receives a warning; who decides; and how a mitigation reaches users.

> Important: This article is operational guidance, not legal advice or a product-specific cybersecurity assessment. Confirm product scope, economic-operator roles, reportability and notification content with qualified EU legal/compliance and cybersecurity advisers. Current ENISA platform guidance can change, so verify it when an event occurs.

1. Start with the role and scope gate

Do not wait for an incident to decide what the “product” is. For each connected range, map:

The physical toy and hardware revision; embedded firmware and bootloader; Bluetooth, Wi-Fi or cellular module; companion iOS or Android app; remote data processing, cloud APIs and account services; voice, chat, camera or location features; libraries, SDKs and separately marketed components; and update, key-signing and service-tool dependencies.

Then identify the legal manufacturer for CRA purposes. A factory may manufacture the item, a developer may own code and an importer may place goods into distribution, but a brand selling under its own name or trademark may carry the manufacturer's responsibilities. A supply agreement can require rapid notice and evidence sharing; it does not automatically transfer statutory responsibility.

Scope is product-specific. Do not assume that every digital feature, accessory or old model receives identical treatment. The Commission's implementation FAQs explain that Article 14 reporting also applies to in-scope products placed on the market before 11 December 2027. That does not mean every other CRA obligation applies retroactively in the same way.

Record the scope and role decision, adviser, date, product family and assumptions. During an incident, a documented decision is far more useful than a debate reconstructed from memory.

2. Build the minimum product and software inventory

A team cannot assess an affected population if it cannot connect a component name to sellable products. Keep one operational inventory, not separate factory, app and compliance spreadsheets that disagree.

Product identity — Brand, model, SKU, EAN/GTIN and EU markets.

Build identity — Hardware revision, factory and production dates/lots.

Software — Firmware, bootloader, app and cloud/API versions.

Components — Wireless modules, chipsets, libraries, SDKs and maintainer.

Ownership — Business owner plus factory, firmware, app and cloud contacts.

Distribution — Importers, distributors, retailers and approximate installed base.

Update route — OTA, app-store, cloud-side, service-tool or no remote route.

Signing/control — Who holds code repositories, signing keys and release authority.

Support state — Current, discontinued, supported-until date and known constraints.

Evidence — SBOM/component records, test reports, release notes and change history.

Treat the inventory as a release gate. When a component, firmware build or cloud dependency changes, update the record before shipment. This complements, rather than replaces, the electrical and product-compliance controls described in Awen Hollek's battery-operated toy practical build guide.

A “discontinued” flag is not a deletion instruction. Older connected toys may remain in homes, stores or distribution, and Article 14 reporting can still be relevant. Preserve their version, component and update-route evidence.

3. Separate the reporting triggers before the alarm arrives

Create two triage lanes and make legal/compliance review part of the clock.

Actively exploited vulnerability

The Commission FAQs distinguish an actively exploited vulnerability from a weakness found without evidence of malicious exploitation. The mandatory trigger depends on reliable evidence that a malicious actor exploited the vulnerability. A good-faith research report or internal penetration-test finding is not automatically an actively exploited-vulnerability notification merely because the weakness is serious.

That does not mean “do nothing.” Log it, acknowledge it safely, assess exposure, protect the researcher channel, notify relevant maintainers and consider applicable voluntary reporting or other duties with advisers. Do not force the evidence into the wrong regulatory category.

Severe incident affecting product security

Run a separate severe-incident assessment. Capture what happened, what security properties or users were affected, duration, spread, products/markets involved and whether the incident meets the legal threshold. A cloud compromise, malicious firmware distribution or attack on a voice service may require a different evidence path from a component vulnerability.

Define “awareness” with counsel and preserve the exact signal, timestamp, recipient and escalation steps. The 24-hour period is too short to lose six hours arguing about when an inbox message became organisational knowledge.

4. Put the reporting clock on one page

ENISA’s current SRP FAQ sets out the reporting sequence. The clock starts when the manufacturer becomes aware of an actively exploited vulnerability or a severe incident affecting product security:

Early warning — Within 24 hours of becoming aware; Establish the event, affected product direction, available exploitation/incident evidence and immediate cross-border implications without waiting for a complete forensic answer.

Full notification — Within 72 hours of becoming aware; Update affected products/versions, severity, impact, evidence, mitigations, technical assessment and relevant indicators as facts mature.

Final report — actively exploited vulnerability — No later than 14 days after a corrective or mitigating measure is available; Explain the vulnerability, exploitation and measures, with final affected scope and remediation information.

Final report — severe incident — Within one month after the 72-hour notification; Provide the developed incident analysis, impact, cause where known and corrective/mitigating measures.

The first report is an early warning, not a finished root-cause analysis. Mark uncertain facts as preliminary, preserve their source, and maintain a decision log. The SRP supports a staged workflow, so information can mature between the early warning, notification and final report.

5. Design intake before detection

Publish or document one monitored security contact and route every likely observer into it: customer support, app reviews, researchers, distributors, importers, factories, firmware teams, cloud providers and component vendors.

Use this minimum intake form:

1. First-seen date, time and time zone. 2. Reporter name/contact and safe follow-up route. 3. Product model, hardware revision and serial/lot if known. 4. Firmware, app, operating-system and cloud/API versions. 5. Component, library, module or function implicated. 6. What was observed and how it was detected. 7. Evidence of malicious exploitation, if any, and its provenance. 8. Reproduction steps and limits—without asking for unsafe public disclosure. 9. Known users, markets, services or data affected. 10. Containment or mitigation already attempted. 11. Attachments, hashes, screenshots, logs or identifiers. 12. Internal owner and next update time.

Contracts should require immediate supplier escalation, evidence preservation, named 24/7 contacts and cooperation on mitigation. Test those contacts. An unread “security@” inbox or a WeChat group with no weekend owner is not an incident process.

6. Create a triage room with decision rights

A practical RACI should fit on one page:

CRA manufacturer / executive owner — Overall accountability, resources and risk acceptance.

Incident lead — Timeline, meetings, actions, evidence log and handovers.

Product owner — Sellable models, markets, installed base and business decisions.

Firmware/app/cloud leads — Technical scope, logs, reproduction, containment and releases.

Factory/component contacts — Build records, component lots, service tooling and supplier evidence.

EU legal/compliance adviser — Scope, role, trigger and notification review.

Customer communications owner — User, retailer, importer and support messaging.

SRP assigned representatives — Platform access, submission and regulator/CSIRT workflow.

ENISA's SRP page says assigned representatives use the platform and provides current registration, notification and interface guidance. Establish primary and secondary coverage, personal EU Login access with MFA where required by current guidance, and a handover plan. Never discover during an incident that the only authorised person is unavailable.

Write the China–EU handover rule explicitly: who owns the case at Europe close, who receives it in China, what evidence must be translated, and the next fixed update time. Avoid handing sensitive vulnerability details through uncontrolled consumer messaging accounts.

7. Prepare the SRP evidence pack

Create a secure incident folder template before it is needed. Include:

• defensible awareness timestamp and original report;

• product identities, versions, lots and EU markets;

• incident or vulnerability description;

• reliable exploitation evidence and provenance, where applicable;

• severity, likely impact and affected security properties;

• indicators, logs, hashes and preservation notes;

• suspected threat, attack path or root cause, clearly labelled if provisional;

• CVE or EUVD identifiers where available;

• third-party component provenance and maintainer contacts;

• immediate containment and available corrective/mitigating measures;

• user, importer, distributor and retailer communication decisions;

• every material decision, owner, timestamp and rationale; and

• copies or exports of submitted stages and follow-up correspondence.

Use the current SRP glossary and guidance at filing time; fields and platform procedures can evolve. Restrict access, follow data-protection requirements, and avoid collecting personal data that is unnecessary for the security case.

8. Control third-party components without guessing

Consider this tabletop scenario:

> A wireless-module maintainer reports active exploitation of a Bluetooth flaw. The same module appears in five toy models, but only two firmware branches enable the vulnerable function. One discontinued model lacks OTA updates; another uses a patched library from a different fork.

The final-product team must establish actual exploitability in each product—not just copy the component advisory. The Commission FAQs indicate that an integrated-component vulnerability may create notification duties for the final-product manufacturer when it is exploitable in that final product. If the weakness cannot be exploited there, mandatory actively exploited-vulnerability reporting may not be triggered, but documented analysis and maintainer/supplier escalation still matter.

Ask, in order:

1. Which models and lots contain the component? 2. Which firmware builds expose the function and configuration? 3. Is there reliable evidence of malicious exploitation relevant to the product? 4. Can cloud controls, app changes or configuration reduce exposure? 5. Who can produce, sign, test and distribute a fix? 6. How will users of a discontinued or offline model be reached? 7. What evidence supports the reportability decision for each product branch?

This is why an SBOM alone is not readiness. You also need configuration, build lineage, ownership and deployment reach.

9. Prove the mitigation can reach the toy

A technically correct patch has little value if the organisation cannot ship it. Test:

Firmware build and code-signing access; OTA capacity, rollback and failure recovery; app-store ownership, certificates and emergency-review route; cloud feature flags, credential rotation and API controls; factory service tools and field-return instructions; notices through apps, email, websites, retailers and distributors; contact routes for importers in each EU market; and evidence that the measure was offered, installed or otherwise communicated.

For toys using QR-linked instructions or experiences, maintain destination control and a backup user route; Awen Hollek's guide to QR codes on toys and playable AR explains the wider operational value of managed destinations. For teams using AI in concept development, keep experimental prompt workflows separate from production credentials and product-security evidence; see AI in toy ideation.

10. Run a 48-hour readiness test

Choose one current model and one discontinued model. At 09:00, inject a plausible component alert with incomplete version information. Then test whether the team can:

Establish and record awareness; identify models, versions and EU markets; reach the factory and technical owners; preserve evidence and distinguish fact from assumption; assess the two reporting triggers with advisers; access the SRP with resilient representative coverage; assemble a credible early-warning data set within 24 hours; develop the 72-hour update without overwriting the first record; and select a workable mitigation and user-contact path.

Red flags include no version inventory, an unmonitored shared inbox, signing keys controlled only by an agency, discontinued products missing from records, supplier terms without immediate incident notice, no secondary SRP coverage and no tested user-update route.

Awen Hollek can help overseas toy brands map China-side factories, firmware ownership, product versions, component responsibilities, escalation terms and update routes, then coordinate a practical tabletop. This supports the operating evidence trail; it is not a substitute for qualified legal advice, incident response or specialist cybersecurity testing.

Need help mapping China-side factories, firmware ownership, component responsibilities and escalation routes before the CRA clock starts? Talk to Awen Hollek about a practical connected-toy readiness tabletop.

Frequently asked questions

Do the CRA reporting obligations cover connected toys placed on the market before December 2027?

The Commission FAQs state that Article 14 reporting applies to in-scope products placed on the market before 11 December 2027. Do not infer that every other CRA obligation applies retroactively in the same way. Confirm the scope and your role for each product with qualified advisers.

Does an ethical-hacker report automatically trigger a 24-hour notification?

No. A good-faith discovery without reliable evidence of malicious exploitation is not automatically a mandatory actively exploited-vulnerability report. It still needs prompt intake, assessment, evidence preservation and responsible handling, and another reporting route or duty may apply.

When does the 24-hour clock start?

The legal deadline runs from the manufacturer becoming aware. Define and document how awareness is established for your organisation with legal/compliance advisers. Preserve the original timestamp, recipient, evidence and escalation history rather than trying to reconstruct them later.

Who reports: the EU importer, factory or brand?

It depends on the CRA role and product arrangement. The manufacturer carries the Article 14 reporting obligation discussed here; a brand selling under its own name or trademark may be the manufacturer even when a factory builds the toy. Importers and distributors have their own obligations. Confirm the exact role chain rather than relying on commercial labels.

What if an exploited third-party component is inside the toy?

Assess whether the vulnerability is exploitable in the final product and which builds expose it. The final-product manufacturer may also have a reporting duty. If it is not exploitable in that product, mandatory actively exploited-vulnerability reporting may not be triggered, but document the analysis and notify or coordinate with the supplier or maintainer as appropriate.

What should we prepare for the ENISA Single Reporting Platform?

Prepare the awareness record, product and version identities, EU markets, description, exploitation or incident evidence, severity and impact, component provenance, identifiers, mitigations, user impact and decision log. Use ENISA's current SRP glossary and guidance because stage-specific fields and procedures can change.