A manufacturer selling one connected product into the UK, the EU, the US and Singapore can end up running five separate compliance projects against requirements that overlap by more than half, because nobody mapped them to each other at the requirement level. ETSI EN 303 645, the NIST IR 8259 family, IEC 62443-4-2, the EU Cyber Resilience Act (CRA) essential requirements, the UK PSTI regime, the US Cyber Trust Mark and Singapore's Cybersecurity Labelling Scheme (CLS) all ask for the same core capabilities in different words, at different depths and with different evidence. This guide is the engineering crosswalk: it lines the instruments up requirement by requirement, shows where one design satisfies all of them and where they genuinely diverge, and sets out how to build one control set and one evidence pack that you can certify many times. It is for product security leads, firmware architects, PSIRT managers and compliance engineers. Legal scope, dates and penalties are in the Product Security Laws Map and are not repeated here.
Status checked 14 November 2026 against EUR-Lex, legislation.gov.uk, ETSI, IEC, NIST, the FCC and the Cyber Security Agency of Singapore. CRA reporting obligations under Article 14 apply from 11 September 2026 and the main obligations from 11 December 2027.
Key takeaways
- Three different kinds of document are being compared. ETSI EN 303 645, NIST IR 8259A/8259B and IEC 62443-4-2 are technical standards or baselines; the CRA and UK PSTI are law; the US Cyber Trust Mark and Singapore CLS are voluntary labels that point back at the standards.
- The shared core is small and well defined. Unique credentials, a published vulnerability reporting route, a declared support period, authenticated updates and protected stored secrets appear in every instrument, so build those once and to the strictest wording.
- The CRA is the superset for most consumer products. Annex I adds requirements the consumer baselines leave as recommendations or omit: no known exploitable vulnerabilities at release, automatic security updates by default, logging, an SBOM, free updates and 24-hour exploited vulnerability reporting.
- IEC 62443-4-2 is the deepest on identity and access. Its component requirements on authenticator management, PKI certificates and authorisation enforcement go well beyond the consumer baselines, so an industrial or enterprise line should design to it and then map down.
- Evidence reuse is where the savings are. One conformance statement, one threat model and one disclosure policy can feed PSTI, CLS, the Cyber Trust Mark and the CRA technical file.
What is being compared
| Instrument | Kind | Unit assessed | Wording style |
|---|---|---|---|
| ETSI EN 303 645 V3.1.3 (2024-09) | European Standard, voluntary unless cited | Consumer IoT device plus associated services and apps | Numbered provisions, "shall" and "should"; 13 provision groups (5.1 to 5.13) plus data protection (clause 6) |
| NIST IR 8259 Rev. 1, IR 8259A, IR 8259B, IR 8425 | US guidance, voluntary | The IoT product: device plus backends, apps and gateways | Outcome statements: six product capabilities and four non-technical developer activities |
| IEC 62443-4-2:2019 Ed. 1.0 | International standard for industrial automation and control system components | One component version: software application, embedded device, host device or network device | Component requirements (CRs) and enhancements under seven foundational requirements; capability security level SL-C 1 to 4 |
| EU CRA, Regulation (EU) 2024/2847, Annex I | Law | Products with digital elements, hardware and software | Essential requirements stated as outcomes, Part I product properties (13 items) and Part II vulnerability handling (8 items) |
| UK PSTI, SI 2023/1007 Schedule 1 | Law | Relevant connectable products made available in the UK | Three requirements: passwords, reporting security issues, minimum security update period |
| US Cyber Trust Mark (FCC 24-26, 47 CFR Part 8) | Voluntary label | Wireless consumer IoT product | Criteria based on the NISTIR 8425 consumer profile outcomes |
| Singapore CLS(IoT) | Voluntary label, four levels | Consumer smart device | Level 1 baseline and Level 2 full mandatory set from ETSI EN 303 645; Level 3 lifecycle and binary analysis; Level 4 penetration testing |
For each instrument on its own, see the ETSI EN 303 645 Consumer IoT Guide, the NIST IR 8259 IoT Device Cybersecurity Baseline Guide, the IEC 62443-4-1 and 4-2 Product Security Guide, the EU Cyber Resilience Act Guide, the UK PSTI Act Guide, the US Cyber Trust Mark Guide and the Singapore Cybersecurity Labelling Scheme Guide.
Threat model and design intent of each instrument
Treating these as alternatives is the first mistake: a manufacturer needs a standard to design against, a law per market and, optionally, a label. The differences make sense once you see which attacker each was written against.
ETSI EN 303 645: mass compromise of home devices
Threat model: automated, internet-scale attacks on cheap devices: credential guessing against shared defaults, exploitation of unpatched firmware and extraction of secrets from firmware images. Architecture: device, app and cloud service assessed together. Typical failure: a team treats "should" provisions such as secure boot (5.7-1) as optional and forgets that provision 5.0-1 requires a recorded justification for every recommendation not implemented. Decision criterion: use it as the design baseline for any consumer product sold in Europe, the UK or Singapore.
NIST IR 8259 family: securability for the customer
Threat model: broad and customer-centred. Architecture: any component can deliver a capability, so a backend can log for a constrained sensor. Typical failure: reading IR 8259A as a checklist, when it is a starting point to be tailored through a profile such as IR 8425 or SP 800-213. Decision criterion: use it to structure capability decisions and documentation, and as the route to the US label.
IEC 62443-4-2: a determined attacker inside an industrial zone
Threat model: graded by security level, from casual violation (SL 1) to sophisticated, well-resourced attackers with IACS-specific skills (SL 4). Typical failure: claiming a capability level without the IEC 62443-4-1 development process behind it, or shipping a capable component at insecure default settings. Decision criterion: design to it for products sold into industrial, utility, building automation or enterprise operational environments.
EU CRA: the whole lifecycle, backed by market surveillance
Threat model: stated in law as "an appropriate level of cybersecurity based on the risks". Architecture: the product, its remote data processing and the manufacturer's vulnerability handling. Typical failure: mapping a product to EN 303 645 and assuming CRA conformity. Decision criterion: mandatory for the EU market; plan for it as the superset.
UK PSTI: three non-negotiable basics
Threat model: the same mass compromise problem as EN 303 645, reduced to the three failures with the widest impact. Typical failure: publishing a support period and then shortening it, which Schedule 1 paragraph 3 treats as non-compliance, or forgetting that cryptographic keys and API keys are excluded from the password rule and therefore need a separate control under your own standard. Decision criterion: mandatory for UK consumer products; meet it through the named ETSI provisions.
US Cyber Trust Mark and Singapore CLS: signalling to buyers
Threat model: inherited from NISTIR 8425 and ETSI EN 303 645 respectively. Typical failure: treating the label as a one-off test when both carry continuing obligations: the Cyber Trust Mark ties continued vulnerability fixing to the support period end date disclosed in the registry, and a CLS label lasts only as long as the declared support period. Decision criterion: pursue a label where retailers, buyers or tenders ask for one, and pick the CLS level that matches the evidence you already hold.
Requirement-by-requirement crosswalk
One engineering requirement per row. Clause numbers are given where they exist, outcome names where the instrument uses outcomes.
| Requirement | ETSI EN 303 645 | NIST IR 8425 / 8259A | IEC 62443-4-2 | EU CRA Annex I | UK PSTI Schedule 1 | Singapore CLS |
|---|---|---|---|---|---|---|
| No universal default passwords | 5.1-1, 5.1-2 (shall) | Interface Access Control; Product Configuration | CR 1.5 authenticator management (change of default authenticators) | Part I (2)(b) secure by default; (d) protection from unauthorised access | Para 1: unique per product or user-defined, not counters or serial numbers | Level 1 |
| Authentication strength and brute force | 5.1-3, 5.1-5 | Interface Access Control | CR 1.7 password strength; CR 1.11 unsuccessful login attempts | Part I (2)(d) | Not covered beyond para 1 | Level 2 |
| Unique device identity and machine credentials | 5.4-2 tamper-resistant identity; 5.4-4 unique per-device credentials; 5.1-2A keys over passwords for machines | Asset Identification | CR 1.2 device identification and authentication; CR 1.8 PKI certificates; CR 1.9 public key authentication | Part I (2)(d), (e) | Excluded: keys, API keys and non-IP pairing PINs are not passwords | Level 2 |
| No hard-coded secrets, secure storage | 5.4-1, 5.4-3 | Data Protection | CR 1.5; CR 4.1 information confidentiality | Part I (2)(e) | Not covered | Level 2 |
| Vulnerability reporting route | 5.2-1 published disclosure policy with contact and timelines | Information and Query Reception | Process requirement in IEC 62443-4-1 (DM practice) | Part II (5) CVD policy; (6) contact address | Para 2: contact point, when acknowledgement and status updates will arrive | Level 1 |
| Fixing vulnerabilities | 5.2-2, 5.2-3 (should) | Information Dissemination | IEC 62443-4-1 DM and SUM practices | Part I (2)(a) no known exploitable vulnerabilities at release; Part II (2) fix without delay; (4) disclose fixed vulnerabilities | Not covered | Level 2 onwards |
| Published support period | 5.3-13 (shall) | Information Dissemination (end of support notices) | Not specified in 4-2 | Support period set by the manufacturer, at least five years unless the product's expected use is shorter | Para 3: publish, never shorten | Level 1; label validity tied to it |
| Secure update mechanism | 5.3-2, 5.3-7, 5.3-10 (shall); 5.3-9 (should) | Software Update | CR 3.10 support for updates, with its enhancement for update authenticity and integrity | Part I (2)(c) automatic updates on by default with opt-out; Part II (7), (8) secure, timely, free | Not covered | Level 2 |
| Software integrity and secure boot | 5.7-1, 5.7-2 (should) | Software Update; Cybersecurity State Awareness | CR 3.4 software and information integrity; EDR 3.14 integrity of the boot process | Part I (2)(f) integrity of programs and configuration, report corruption | Not covered | Assessed at Levels 3 and 4 |
| Secure communication | 5.5-1, 5.5-5, 5.5-7, 5.5-8 | Data Protection | CR 3.1 communication integrity; CR 4.3 use of cryptography | Part I (2)(e), (f) | Not covered | Level 2 |
| Minimal attack surface | 5.6-1, 5.6-2, 5.6-4A (shall) | Interface Access Control | CR 7.7 least functionality; EDR 2.13 use of physical diagnostic and test interfaces | Part I (2)(j) minimise attack surfaces; (k) exploitation mitigation | Not covered | Level 2; tested at Level 4 |
| Logging and state awareness | 5.10 (should) | Cybersecurity State Awareness | CR 2.8 auditable events; CR 6.1 audit log accessibility | Part I (2)(l) record and monitor security-relevant activity, with user opt-out | Not covered | Not in Level 1 or 2 mandatory set |
| Resilience and availability | 5.9 (should) | Not a core capability | CR 7.1 denial of service protection; CR 7.2 resource management | Part I (2)(h) essential functions available; (i) do not degrade other networks | Not covered | Not in Level 1 or 2 mandatory set |
| Data minimisation and deletion | 5.11-1 (shall); clause 6 | Data Protection (customer can delete data) | CR 4.2 information persistence | Part I (2)(g) data minimisation; (m) secure erasure and data transfer | Not covered | Level 2 |
| Input validation | 5.13-1A, 5.13-1B (shall) | Interface Access Control (validate data shared between components) | CR 3.5 input validation | Covered through (2)(d), (f) and (k) by risk assessment | Not covered | Level 2 |
| SBOM | Not required | Documentation (component sources) | Not in 4-2; third-party component management in 4-1 | Part II (1) machine-readable SBOM covering at least top-level dependencies | Not covered | Not required |
| Secure development lifecycle | 5.6-9 (should) | IR 8259 Rev. 1 activities; Documentation | Prerequisite: IEC 62443-4-1 eight practices | Part II (3) regular security testing and review; Annex VII technical documentation | Not covered | Level 3 (IMDA IoT Cyber Security Guide) plus binary analysis |
| Exploited vulnerability and incident reporting to authorities | Not covered | Not covered | Not covered | Article 14: early warning within 24 hours via ENISA's single reporting platform | Not covered | Not covered |
The US Cyber Trust Mark follows the IR 8425 outcomes in the NIST column, plus registry disclosures such as the support period end date.
Where the instruments genuinely diverge
- Machine credentials: PSTI explicitly excludes cryptographic keys and API keys from its password rule, while EN 303 645 5.4-4 and IEC 62443-4-2 CR 1.2 make per-device machine credentials central. A product can be PSTI compliant with one fleet-wide API key and still fail EN 303 645 and the CRA. See the Device and IoT Identity Guide.
- Automatic updates: EN 303 645 asks for updates that are simple to apply; the CRA requires automatic security updates enabled by default with a clear opt-out and the ability to postpone.
- Release state: only the CRA states that a product must be placed on the market without known exploitable vulnerabilities. That makes pre-release scanning a release gate.
- Levels: IEC 62443-4-2 grades control strength per foundational requirement (SL-C 1 to 4); CLS levels grade depth of assurance; the rest are pass or fail.
Build once, certify many: implementation plan
- Fix the target markets and product classes. Check the CRA product class, because important and critical products may need third-party assessment. See the EU CRA Product Classes Guide.
- Write one product threat model and risk assessment. The CRA, IR 8259 Rev. 1 activity 2, the IEC 62443-4-1 SR practice and ETSI justifications under 5.0-1 all need it.
- Adopt the strictest wording per row of the crosswalk. For consumer products this is usually CRA Annex I plus the EN 303 645 "shall" provisions; for industrial products, 62443-4-2 at the target SL-C plus CRA Annex I.
- Close the shared core first. Unique credentials, the disclosure policy and contact, the published support period, signed and verified updates, and no hard-coded secrets. These unlock PSTI and CLS Level 1.
- Build one conformance statement. Use the ETSI EN 303 645 Annex B pro forma and ETSI TS 103 701 test structure as the master record, add columns for IR 8425 outcomes, CRA Annex I items and, where relevant, 62443-4-2 CRs. Each row points to the same test evidence.
- Test in rings. Run internal tests against the master statement, then a pre-assessment with a lab on one product before committing a portfolio. Treat a failed row as a design defect, not a document fix.
- Certify in an order that reuses results. PSTI deemed compliance needs only ETSI 5.1-1, 5.1-2, 5.2-1 and 5.3-13; a CLS label at any level also counts towards PSTI deemed compliance since 4 December 2025; then the Cyber Trust Mark where sold in the US; then the CRA technical file, which absorbs the earlier evidence.
- Plan rollback and change control. Keep device-side rollback for failed updates, and re-run affected crosswalk rows on every release touching authentication, update or interface code, because declarations follow the product version.
Decision guidance
| Your situation | Design anchor | Map to |
|---|---|---|
| Consumer device, Europe and UK first | EN 303 645 plus CRA Annex I | PSTI, CLS, Cyber Trust Mark |
| Consumer device, US first | IR 8425 outcomes, specified with EN 303 645 provisions | Cyber Trust Mark, then PSTI and CRA |
| Industrial or building automation component | IEC 62443-4-1 and 62443-4-2 at the target SL-C | CRA Annex I |
| Enterprise IoT sold to US federal buyers | IR 8259A and 8259B with SP 800-213A | 62443-4-2 if deployed in OT zones |
| Small manufacturer, one product line | EN 303 645 "shall" provisions | PSTI and CLS Level 1 or 2 |
Small versus large manufacturers: a small firm should keep one spreadsheet crosswalk and one lab relationship, and buy rather than build PKI for device identity. A large portfolio should certify one shared secure boot, update and credential provisioning stack at component level and reuse it across products.
Worked scenario: one camera, four markets
A manufacturer ships a Wi-Fi security camera with a mobile app and cloud recording, sold in the UK, the EU, the US and Singapore. Its first design used one API key in every firmware image, a user-set app password and manual updates.
- PSTI: the user-defined password, a published contact with acknowledgement timings and a five-year support period satisfy Schedule 1; the shared API key does not breach it because API keys are excluded.
- EN 303 645 and CLS Level 2: the shared key fails 5.4-3 and 5.4-4. Fix: per-device key pairs generated in a secure element, with certificates from a manufacturing CA.
- CRA: manual updates fail Part I (2)(c). Fix: automatic security updates on by default with an opt-out and postponement. The team also adds a known-vulnerability release gate, an SBOM and an Article 14 runbook.
- Cyber Trust Mark: the IR 8425 outcomes are already met by the fixes above; the remaining work is CyberLAB testing and the registry entry with the support period end date.
Detection and measurement
- Crosswalk coverage: percentage of internal requirement IDs with passing test evidence, per product version. Target 100% of "shall" and CRA rows before release.
- Shared-secret count: number of credentials present in more than one device image or unit, found by firmware scanning. Target zero.
- Disclosure response time: median days from report to acknowledgement, against the timelines your PSTI and ETSI policy publishes.
- Fix time for exploited vulnerabilities: days from awareness to available update, tracked against the CRA expectation to fix without delay.
- Update adoption: percentage of active devices on the latest security release 30 days after publication.
Common failure patterns
- Hard-coded credentials that pass the narrowest rule: a fleet-wide login or key can survive a PSTI review but fails EN 303 645 5.4-3, IEC 62443-4-2 CR 1.5 and CRA Annex I. The HPE Aruba Instant On hard-coded credentials case shows the result: one built-in administrator login shared by every unit that owners could not change.
- Treating a label as CRA conformity: no label or standard confers presumption of conformity with the CRA until a harmonised standard is cited or a scheme is specified. See the EU Cyber Resilience Act Harmonised Standards Guide.
- Support period mismatch: a period declared for PSTI that is shorter than the CRA expects, or different from the date in the Cyber Trust Mark registry.
- Signing keys treated as build artefacts: update authenticity requirements in every instrument depend on the private signing key, which needs custody controls like any privileged non-human identity. See the IoT Secure Firmware Update Guide.
Framework mapping for the manufacturer's own programme
| Programme element | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | ISO/IEC 27001:2022 Annex A |
|---|---|---|---|
| Legal and market requirements register | GV.OC-03 | SR-3 | A.5.31 |
| Vulnerability disclosure and handling | ID.RA-08 | RA-5, SI-2 | A.8.8 |
| Secure development lifecycle | PR.PS-06 | SA-8, SA-11, SA-15 | A.8.25, A.8.29 |
| Device and update integrity | PR.PS-02 | SI-7 | A.8.27 |
| Device credentials and signing keys | PR.AA-01 | IA-5 | A.8.24 |
| Component inventory and SBOM | ID.AM-02 | SR-3 | A.5.21 |
Practitioner checklist
- Write one versioned product threat model and risk assessment that every scheme reuses.
- Build an internal requirement catalogue using the strictest wording per crosswalk row, mapped to every instrument.
- Remove every shared or hard-coded credential, including API keys that PSTI does not treat as passwords.
- Publish one vulnerability disclosure policy that satisfies ETSI 5.2-1, PSTI paragraph 2 and CRA Part II (5) and (6).
- Set one support period that meets the CRA expectation and use the same date in every declaration and registry.
- Turn on automatic security updates by default for EU products, with opt-out and postponement.
- Generate a machine-readable SBOM for every release and gate releases on known exploitable vulnerabilities.
- Prepare an Article 14 reporting runbook with a named owner before shipping into the EU.
Standards and references
- EUR-Lex: Regulation (EU) 2024/2847 (Cyber Resilience Act)
- ETSI: EN 303 645 V3.1.3 Cyber Security for Consumer Internet of Things: Baseline Requirements
- IEC: IEC 62443-4-2:2019 Technical security requirements for IACS components
- legislation.gov.uk: PSTI (Security Requirements for Relevant Connectable Products) Regulations 2023, Schedule 1
- legislation.gov.uk: PSTI Regulations 2023, Schedule 2 (deemed compliance)
- NIST: IR 8259 Rev. 1 Foundational Cybersecurity Activities for IoT Product Manufacturers
- NIST: IR 8425 Profile of the IoT Core Baseline for Consumer IoT Products
- Cyber Security Agency of Singapore: Cybersecurity Labelling Scheme for Manufacturers
Related NHI Mgmt Group resources: Product Security Laws Map, IoT Product Security Maturity Model, Device and IoT Identity Guide, EU Cyber Resilience Act Harmonised Standards Guide. This guide summarises standards and laws for engineering planning and is not legal advice.