EU Cyber Resilience Act (CRA) reporting obligations started on 11 September 2026. For IoT manufacturers in Thailand and ASEAN planning launches in the EU, the UK, Singapore and Japan, ETSI EN 303 645 can serve as a common evidence matrix before market-specific work begins. It does not, however, automatically confer legal conformity, certification or a security label. This guide shows how to organise device, firmware, update and log evidence once, then adapt it responsibly for the CRA, UK PSTI, Singapore CLS and Japan JC-STAR.
Why ETSI EN 303 645 matters now
ETSI’s official release identifies ETSI EN 303 645 V3.1.3 (2024-09) as the current edition. It provides an outcome-oriented cybersecurity baseline for consumer IoT rather than prescribing one implementation for every device. Singapore’s Cyber Security Agency describes the standard as covering 14 broad provisions.
The operational value for a Thailand factory is not limited to Europe. Connected cameras, gateways, sensors, smart controllers and service terminals are often built on a shared hardware and firmware platform, then sold as regional SKUs. Yet each destination has its own scope, responsible parties, assessment route and public claims: the EU CRA, the UK Product Security and Telecommunications Infrastructure regime, Singapore’s Cybersecurity Labelling Scheme (CLS) and Japan’s JC-STAR.
Answering each market questionnaire from scratch creates duplicate tests, inconsistent wording and scattered files. The better pattern is to translate ETSI topics into internal controls, attach engineering and operating evidence, and map the same controlled evidence to each destination. What is shared is the evidence source and governance—not the destination authority’s legal or certification decision.
What changed on 11 September 2026?
The European Commission states that, from 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents affecting the security of products with digital elements. The framework calls for an early warning within 24 hours of awareness and a full notification within 72 hours. These time limits do not mean every defect or outage is reportable. Teams must assess the official trigger and the facts of the case, with specialist advice where needed.
This deadline turns product security from a pre-launch checklist into a live operating capability. A manufacturer cannot assemble a useful early warning in 24 hours if it cannot quickly identify affected models, firmware versions, sold regions, exploitation information, mitigations and accountable contacts. An ETSI-based evidence matrix can connect those facts before an event occurs. Most other CRA obligations apply fully from 11 December 2027, so the reporting start is a practical early test of lifecycle readiness.
ETSI EN 303 645 is not a law, certificate or automatic passport
ETSI EN 303 645 is a European standard describing baseline outcomes for consumer-IoT security. It is not the CRA itself, a UK PSTI statement of compliance, a Singapore CLS label or a Japan JC-STAR label. Even when a product is designed and tested against ETSI, the team must separately examine market scope, economic-operator roles, required documents, assessment level, application process and marking rules.
Nor does the presence of “IoT” in a product description make every industrial device subject to the same consumer regime. Consumer products, industrial-only equipment, embedded components, medical products and automotive products may sit under different scopes or sector-specific rules. A Thailand manufacturing location, a sale to a European business and an eventual consumer use can each matter differently. Document intended use, distribution, brand ownership and the roles of manufacturer, importer and distributor; confirm uncertain legal scope with qualified advisers.
The standard remains highly useful because major control themes overlap: passwords, vulnerability reporting, software updates, protection of sensitive parameters, secure communications, attack-surface reduction, integrity, resilience, telemetry, personal data, deletion, installation and input validation. A single control register makes additional requirements, reusable tests, translations and customer answers easier to govern.
Separate “baseline adopted,” “tested,” “certified” and “legally conformant”
| Claim | Practical meaning | Evidence to check |
|---|---|---|
| Baseline adopted | ETSI topics are reflected in product requirements | Applicability statement, specifications, owners |
| Self-assessed | The company checked controls using its own method | Checklist, results, open gaps |
| Third-party tested | A laboratory assessed a defined sample and scope | Edition, scope, report and exclusions |
| Scheme approved or labelled | A destination scheme process was completed | Registration, SKU, level and label conditions |
| Legal conformity declared | The responsible operator made a market-specific declaration | Scope analysis, technical file and declaration |
Avoid writing “ETSI compliant, therefore CRA compliant.” A defensible statement is: “ETSI EN 303 645 is used as the common baseline; CRA scope, legal requirements, reporting operations and technical documentation are managed as separate deltas.”
Model the connected product through four evidence surfaces
A matrix built only from visible app features misses manufacturing and lifecycle controls. Divide the product into DEVICE, FIRMWARE, UPDATE and LOG so evidence remains traceable from development through field support.
DEVICE: identify the product and accountability boundary
Record product name, model, hardware revision, SKU, destination, connectivity, factory defaults, administration interfaces, dependent cloud services, mobile apps and third-party libraries. The model on the packaging should reconcile with the product identifier in the SBOM and the support website. In OEM/ODM programmes, define who designs, manufactures, owns the brand, publishes updates and receives vulnerability reports.
For passwords, “no default password” is not enough. Evidence should cover credential generation at the factory, per-device uniqueness, onboarding, the post-reset state, service accounts, rate limiting or lockout, and secret storage. Build and shipment controls should also prove that manufacturing accounts and debug access are absent from released units.
FIRMWARE: reproduce exactly what is running
Connect source revision, build ID, signatures, boot chain, SBOM, compiler and CI/CD records, configuration variants and vulnerability assessment. When a vulnerability is disclosed, the goal is to identify affected sold SKUs and versions within hours—not after a manual exchange of spreadsheets.
Integrity evidence should include behaviour when signature verification fails, rollback controls, recovery images, key custody and rotation, and key injection in manufacturing. For a Thailand line, define how a signed release from development reaches the programming station, which operator or system authorises it, and which log proves the installed hash.
UPDATE: prove the support promise and delivery capability
Control the update policy, minimum support period, vulnerability priorities, remediation targets, signature checks, staged rollout, failure recovery, customer communication and end-of-support. UK PSTI includes publication of the minimum security-update period as one of its baseline requirements. The public promise must be consistent with component availability, cloud funding and engineering capacity.
For CRA readiness, retain not only a patch file but also the affected-product decision, rollout status, customer mitigations and the date a corrective measure becomes available. Track region-specific delivery so the business knows when the same fix actually reached EU, UK, Singapore and Japanese fleets.
LOG: retain facts that support a reporting decision
The purpose is not unlimited collection. Define events needed for detection, investigation and recovery: authentication failures, configuration changes, update outcomes, integrity errors, anomalous communications, crashes, clock state and administrative actions. Specify timestamps, device identifiers, firmware version, collection path, retention, access controls and personal-data handling.
For intermittently connected products, test how customers or distributors can securely export diagnostic data and how support hands it to engineering. If the facts needed for a 24-hour warning are trapped inside a device with an untested retrieval procedure, compliance exists only on paper.
Build a control-and-evidence matrix that teams can operate
A simple cross-reference from ETSI clauses to destination clauses is not enough. Each row should carry a control objective, product scope, owner, evidence ID, repository, update trigger, test method and open delta. Destination columns should use statuses such as direct reuse, reuse with adaptation, separate assessment and likely not applicable rather than an unsupported pass/fail conclusion.
| Common control | Minimum evidence example | Product-owner question |
|---|---|---|
| Unique authentication | Credential design, reset test, factory check | Are service accounts included? |
| Vulnerability disclosure | Public URL, intake SLA, case records | Who monitors holidays and languages? |
| Security updates | Support period, signature test, rollout log | Can every regional SKU receive the fix? |
| Secret protection | Key design, storage test, injection record | Is ODM responsibility separated? |
| Secure communication | Protocol inventory, certificate-failure test | Does it work behind factory proxies? |
| Attack-surface reduction | Port list, disabled services, debug lock | Can test features reach production? |
| Integrity and recovery | Boot checks, rollback and recovery test | Does failure lead to a safe state? |
| Telemetry and logs | Event schema, retention, export and access logs | Can facts be used within 24 hours? |
Keep one authoritative evidence object
Do not create independent files named UK_password_test, JP_password_test and EU_password_test. Assign common product, control, evidence and version identifiers. Market submissions can then reference, translate or reformat the authoritative object. When it changes, impact analysis can identify every downstream submission.
Evidence is broader than a long report. It may include Git tags, signature-verification logs from CI, tickets, public support pages, vulnerability cases, deployment telemetry and factory inspection records. A broken link or evidence stored under one engineer’s private account is effectively unavailable. Create periodic audit exports in a controlled repository.
Map one baseline to four destinations without overclaiming
EU CRA: add lifecycle obligations and a reporting operation
The CRA addresses products with digital elements across design, development, manufacturing and post-market handling. ETSI controls can be valuable inputs, but CRA scope, product categorisation, operator roles, conformity route, technical documentation and reporting must be assessed independently.
For the reporting duty effective on 11 September 2026, connect vulnerability intake to legal triage. Establish a contact chain covering PSIRT, development, cloud operations, factory quality, regional sales and legal. Define who records awareness time, what information supports “actively exploited” or “severe incident” analysis, and who operates the Single Reporting Platform. An early warning is not a final root-cause report; use one case record that can evolve consistently into the 72-hour notification and later final report.
UK PSTI: make the three baseline requirements and supply-chain roles explicit
The UK consumer connectable product security regime took effect on 29 April 2024. Government guidance highlights three baseline requirements: no universal default or easily guessable passwords, published information on how to report security issues, and published information on the minimum security-update period. These align with key ETSI topics, but statutory duties and the statement of compliance remain market-specific.
When a Thailand OEM/ODM supplies a UK brand, the contract should identify the technical evidence supplied by the factory and the declarations handled by the brand owner or importer. A support period on a brand website has little value if the engineering team cannot build and sign fixes. Budget for component end-of-life monitoring, OSS vulnerability analysis, signing keys, update infrastructure and post-sale support.
Singapore CLS: use the ETSI base but separate Level from assessment Tier
CSA’s manufacturer information distinguishes the cybersecurity Level shown by the label from the sequential assessment Tier. Assessment Tier 1 and Tier 2 are based on the ETSI baseline, and the awarded CLS Level corresponds to the highest Tier completed. CSA describes ETSI EN 303 645 as 14 broad provisions. The common self-assessment and evidence register therefore provide a useful starting point, but applicants must follow current CLS product, Level, Tier, testing, application and label-use rules.
Regional teams can maintain English evidence centrally and extract the required package for Singapore. Do not promise that one laboratory report obtains every market approval unless an authority explicitly provides recognition. Confirm the standard edition, sample, firmware, test scope and retest triggers with the relevant assessment body.
Japan JC-STAR: alignment does not mean identity
IPA explains that JC-STAR criteria are developed with attention to alignment with international standards and guidance such as ETSI and NIST. That makes reuse practical, but JC-STAR is its own Japanese scheme. Applicants must meet its applicable level, evidence, assessment and application process before using the label.
For the scheme context, see our JC-STAR IoT security labelling guide. For preparation from a Thai operation, read JC-STAR preparation for Thailand sites. Add JC-STAR-specific assessment and submission fields to the common matrix rather than treating an ETSI report as automatic approval.
| Destination | How ETSI evidence helps | What needs separate confirmation |
|---|---|---|
| EU CRA | Baseline design, updates and vulnerability handling | Scope, category, conformity, technical file, reporting |
| UK PSTI | Passwords, reporting route and support period | Product scope, operator duty, statement and records |
| Singapore CLS | Foundation for assessment Tier 1/2 preparation | Desired Level, required Tier, tests, application and label conditions |
| Japan JC-STAR | Reuse of internationally aligned controls | Level criteria, application, assessment and display |
Generate reliable evidence on the Thailand production line
Engineering alone cannot complete the record. Factory configuration, keys, firmware and inspection results determine what ships. Connect MES, programming fixtures and inspection terminals to the product register while preserving OT availability and segmentation. Our industrial network construction guide explains the surrounding network principles.
Freeze approved hardware revision, firmware hash, configuration profile, key-injection procedure and inspection specification in the work order. After programming, read back the device and build identifiers; verify signature state, closed debug paths, initial authentication and update behaviour. Link results to serial number and destination. Define when rework may roll a unit back and how nonconforming units are quarantined.
Supplier requirements should cover SBOM delivery, vulnerability notice, remediation, end-of-support, secret handling and incident cooperation. Do not accept “ETSI-compliant component” without edition, scope and evidence. A module report does not cover product-specific cloud connections, app behaviour, configuration or user workflows.
Write an actionable IoT security procurement standard
| Procurement field | Example requirement | Acceptance method |
|---|---|---|
| Scope | Declare model, version and excluded provisions | Review applicability statement |
| Vulnerability handling | Publish route, SLA and notification method | Verify URL and run tabletop intake |
| Updates | State minimum period, signatures, recovery and EOL | Update and rollback test |
| SBOM | Agree format, versioning and notification | Reconcile a sample |
| Manufacturing | Record key injection, debug lock and version | Factory audit and log sample |
| Incident support | Supply facts needed for 24/72-hour triage | Contact drill and SLA measure |
A standard number by itself does not create an acceptance boundary. Requiring concrete deliverables makes suppliers comparable and turns the requirement into a test plan.
A 90-day SCOPE–EVIDENCE–DRILL implementation
Days 1–30: SCOPE
Choose one representative product family. Record model, version, intended use, users, destinations, brand, cloud, app, OEM/ODM relationship and update owner on one page. Separate legal-scope assumptions from confirmed decisions, with source, reviewer and review date.
Translate the 14 broad ETSI provisions into internal controls and assign each to DEVICE, FIRMWARE, UPDATE or LOG. Reuse relevant Secure SDLC, quality, ISO 27001 or IEC 62443 records, but do not confuse organisational procedures with product-level proof.
Days 31–60: EVIDENCE
Assign evidence IDs and test whether each object is current, covers the SKU and can be reproduced by another person. Useful scenarios include first setup from factory state, password reset, certificate failure, interrupted update, invalid signature, rollback, network loss, log export and data deletion.
Convert each gap into severity, owner, deadline and shipment decision. Record interim mitigation, customer communication, target release and risk acceptance. For each destination, mark whether reuse is direct, requires translation or format change, or needs additional testing.
Days 61–90: DRILL
Run a tabletop exercise using a fictional actively exploited vulnerability. Starting from intake time, identify affected builds through the SBOM, determine destinations, assess exploitation data, prepare mitigation, escalate to management and legal, and draft the 24-hour warning and 72-hour notification. Do not send fictional reports to an authority; test internal templates and approvals.
Measure information gaps and waiting time. If sold-region extraction takes eight hours and a module-version answer takes twelve, the 24-hour margin is already thin. Add integration and ownership fixes to the backlog, then repeat the drill with an absent owner or public holiday scenario.
Measure operating readiness, not only certificates
- Time from sold SKU to firmware build and SBOM
- Time from vulnerability intake to accountable product owner
- Time to estimate affected markets and installed base
- Time to build, approve and stage a security update
- Update success and recovery rate
- Percentage of evidence reused in destination submissions
- Number of expired, broken or ownerless evidence objects
- Time to approve a draft 24-hour warning and 72-hour notification
These indicators do not prove legal conformity, but they reveal whether a paper checklist can support a real event. Report gaps to management in terms of shipment impact, lifecycle cost and response-time risk.
Common failure modes
First, quality owns the spreadsheet while engineering, factory, cloud and support do not update it. Assign an owner and update trigger to every row.
Second, the assessed sample differs from production after component substitution, configuration change or cloud API revision. Add a mandatory security-evidence and market-submission impact check to engineering change control.
Third, marketing publishes a support period without funding engineering, keys, deployment infrastructure and intake operations. Price lifecycle support into the product plan.
Fourth, the vulnerability mailbox exists but nobody tests holidays, attachments, escalation or supplier coordination. Run intake and response drills.
Fifth, teams call laws, self-declarations, third-party assessments, labels and recognition arrangements “certification.” Review external claims jointly across legal, quality and engineering.
Frequently asked questions
What is ETSI EN 303 645?
It is an outcome-focused European cybersecurity baseline for consumer IoT, with the current edition V3.1.3 (2024-09). It is useful as a common evidence vocabulary, but it is not a law or universal multi-market certificate.
Does ETSI EN 303 645 automatically satisfy the EU CRA?
No. ETSI-aligned controls and test evidence can support CRA preparation, but scope, categorisation, conformity assessment, technical documentation, vulnerability handling and reporting must be evaluated separately. Obtain specialist advice for uncertain legal interpretations.
What do the CRA 24-hour and 72-hour deadlines mean?
The Commission describes an early warning within 24 hours after awareness and a full notification within 72 hours for actively exploited vulnerabilities and severe security incidents affecting a product with digital elements. Not every bug is reportable; teams need a documented trigger analysis and factual case record.
Can one IoT security certification be used in every market?
Not automatically. Tests and evidence may be reusable, but scope, levels, applicants, declarations and label conditions differ. Treat official recognition only as broadly as the authorities state it; otherwise describe the benefit as preparation efficiency.
How are JC-STAR and ETSI EN 303 645 related?
IPA says JC-STAR is developed with alignment to international standards and guidance such as ETSI and NIST. Common evidence can therefore help, but ETSI assessment alone does not grant a JC-STAR label.
What should an IoT device security procurement standard contain?
Specify product and version scope, applicability, password design, vulnerability route, minimum support period, signed updates, SBOM, manufacturing key controls, logs, incident cooperation, acceptance tests and evidence format. Assign an owner and acceptance criterion to each item.
Where should a Thailand factory start?
Select one product, collect DEVICE, FIRMWARE, UPDATE and LOG evidence, then run a 90-day scope, evidence and incident-drill cycle. Improve the template before rolling it out across the portfolio.
Conclusion
ETSI EN 303 645 gives Thailand and ASEAN IoT manufacturers a practical common baseline for multi-market preparation. A controlled matrix across DEVICE, FIRMWARE, UPDATE and LOG makes deltas for the EU CRA, UK PSTI, Singapore CLS and Japan JC-STAR visible. The standard does not replace legal scope analysis, application, assessment or marking. With CRA reporting obligations now active, the real test is whether the organisation can move reliable facts through a 24-hour warning and a 72-hour notification workflow.
TOMAS TECH can help at an early planning stage—from reviewing product, firmware, update and log evidence to defining a shared matrix, procurement clauses and a 90-day drill for a Thailand operation. Contact us with the product family and planned markets.
References
- ETSI, ETSI EN 303 645 V3.1.3 release: https://www.etsi.org/newsroom/press-releases/2457-etsi-releases-new-guidelines-to-enhance-cyber-security-for-consumer-iot-devices/
- IPA, JC-STAR details: https://www.ipa.go.jp/security/jc-star/detail.html
- European Commission, CRA implementation: https://digital-strategy.ec.europa.eu/en/factpages/cyber-resilience-act-implementation
- European Commission, CRA reporting: https://digital-strategy.ec.europa.eu/en/policies/cra-reporting
- European Commission, CRA legal summary: https://digital-strategy.ec.europa.eu/en/policies/cra-summary
- UK Government, consumer connectable product security: https://www.gov.uk/guidance/regulations-consumer-connectable-product-security
- Cyber Security Agency of Singapore, CLS for manufacturers: https://www.csa.gov.sg/our-programmes/certification-and-labelling-schemes/cybersecurity-labelling-scheme/for-manufacturers/
- EUR-Lex, Regulation (EU) 2024/2847: https://eur-lex.europa.eu/eli/reg/2024/2847/2024-11-20/eng
This article provides general product-security information, not legal advice or a certification result. Confirm scope and conformity methods for the specific product, use, distribution model, operator role and current official texts.
