Product Security Laws Map: CRA, PSTI, RED, US Cyber Trust Mark, Australia and Singapore Labels

A connected product sold in Europe, the UK, the US, Australia and Singapore now meets five different security regimes, two of them mandatory now, one mandatory from December 2027 and two voluntary labels, and they do not line up neatly. The EU Cyber Resilience Act (CRA) will cover almost every product with digital elements, the Radio Equipment Directive (RED) delegated act already applies to wireless devices, the UK PSTI regime and Australia's Cyber Security Act 2024 set mandatory baselines for consumer devices, and the US Cyber Trust Mark and Singapore's Cybersecurity Labelling Scheme reward manufacturers who go further. This map compares scope, obligations, dates, penalties and the shared baseline so a product security team can build one programme with regional overlays. It is for product security leads, PSIRT managers, compliance teams and hardware and software vendors that sell internationally, and extends the Global Cybersecurity Regulatory Map into product law.

Status checked 27 October 2026. CRA reporting obligations have applied since 11 September 2026 and its main obligations apply from 11 December 2027. RED cybersecurity requirements apply now. UK PSTI requirements have applied since 29 April 2024. Australia's smart device standards apply to products manufactured on or after 4 March 2026. The US Cyber Trust Mark is legally established but its labelling standards had not taken effect as of the FCC's August 2026 notice. This page is not legal advice.

Key takeaways

• Three basics appear everywhere: no universal default passwords, a published vulnerability reporting route and a stated security support period form the baseline in PSTI, Australia, the CRA, the US label and Singapore Level 1.
• The CRA is the widest regime: it covers hardware and software with digital elements, adds 24-hour reporting of actively exploited vulnerabilities from 11 September 2026 and CE marking from 11 December 2027.
• RED is the bridge in the EU: Delegated Regulation (EU) 2022/30 applies cybersecurity essential requirements to wireless products until the CRA takes over; EUR-Lex lists it as no longer in force from 10 December 2027.
• Labels are voluntary but binding once used: the US Cyber Trust Mark and Singapore CLS are opt-in, yet a manufacturer that uses them takes on continuing obligations.
• ETSI EN 303 645 is the common currency: it underpins PSTI deemed compliance and Singapore CLS, and mutual recognition lets one assessment count in several markets.

Regulations and frameworks at a glance

Scope: who and what is covered

For individual regimes in depth, see the UK PSTI Act Guide, the US Cyber Trust Mark Guide, the EU Radio Equipment Directive Cybersecurity Guide and the Singapore Cybersecurity Labelling Scheme Guide.

Key obligations

Harmonised standards and baselines

• RED: Implementing Decision (EU) 2025/138 of 28 January 2025 cited EN 18031-1:2024, EN 18031-2:2024 and EN 18031-3:2024, with restrictions. No presumption of conformity applies where users may skip setting a password (clauses 6.2.5.1 and 6.2.5.2), where parental access control is not ensured for Part 2, and for the secure update criteria in Part 3 clause 6.3.2.4. Products relying on a restricted clause need another route, typically a notified body.
• PSTI deemed compliance: meeting ETSI EN 303 645 provisions 5.1-1, 5.1-2, 5.2-1 and 5.3-13 counts; from 4 December 2025 Japan JC-STAR STAR-1 and Singapore CLS labels also count. See the ETSI EN 303 645 Consumer IoT Guide.
• US label: based on NISTIR 8425, six product capabilities and four developer activities. See the NIST IR 8259 IoT Device Cybersecurity Baseline Guide.
• Singapore CLS levels: Level 1 baseline from ETSI EN 303 645; Level 2 its mandatory provisions; Level 3 lifecycle requirements and binary analysis; Level 4 penetration testing.

Timeline and current status

Enforcement and penalties

What it means for AI agents and non-human identities

• Device credentials are the first test: every regime bans universal default passwords, and the stronger ones expect unique per-device credentials and no hard-coded secrets. ETSI EN 303 645 provision 5.4 bans hard-coded critical security parameters. See the IoT Device Identity with TPM and DICE Guide.
• Update signing keys are product-critical: secure update requirements in the CRA, RED Part 3 and CLS Level 2 depend on protected code signing keys and certificates. See the Code Signing Security Guide.
• Backend service identities are in scope: the US label and the CRA treat associated cloud services and apps as part of the product, so API keys and service accounts behind a device count.
• AI features do not escape: an AI assistant built into a product is a digital element under the CRA; its model endpoints, tokens and agent permissions belong in the risk assessment and SBOM.
• Exploited vulnerability reporting: a leaked fleet credential that is being abused is likely an actively exploited vulnerability or severe incident under the CRA, starting the 24-hour clock.

Compliance steps

1. Inventory products by market: list each product, its radio and connectivity, consumer or enterprise use and the markets it ships to.
2. Apply the shared baseline first: unique credentials, a published vulnerability disclosure policy and a stated support period satisfy the core of PSTI, Australia and CLS Level 1 and are prerequisites for the CRA and US label.
3. Stand up CRA reporting now: register in the ENISA Single Reporting Platform, name who decides an actively exploited vulnerability, and test 24-hour and 72-hour submissions.
4. Close RED gaps: assess wireless products against EN 18031 and identify any reliance on restricted clauses that needs a notified body.
5. Plan CRA conformity: classify products (default, important Class I or II, critical), choose the assessment route and build technical documentation including an SBOM. See the EU CRA Product Classes Guide and the SBOM Guide.
6. Decide on voluntary labels: use CLS mutual recognition and PSTI deemed compliance to reuse one assessment; track the FCC docket before planning a US label.
7. Keep statements of compliance: issue PSTI and Australian statements per product and retain them; Australia requires five years.
8. Review on change: re-run the matrix when a product, market or regime changes, and at least yearly.

Decision guidance

• Consumer device sold in all five markets: build to ETSI EN 303 645 plus the CRA essential requirements; this covers PSTI, Australia and CLS Level 2 and positions you for the US label.
• Enterprise or industrial product: PSTI, Australia and the labels do not apply; the CRA and RED do. See the Industrial IoT (IIoT) Security Guide.
• Pure software: only the CRA applies among these regimes. See the EU CRA Obligations for Software Developers and Open Source Stewards Guide.
• Small manufacturers: start with the baseline and reporting process; the CRA spares micro and small enterprises fines for missing the 24-hour early warning but not the other duties.

Measuring the programme

• Market coverage: products with a current compliance record for every market they ship to.
• Default credential elimination: share of product lines with unique per-device credentials.
• Support period publication: products with a published end date.
• Reporting readiness: drill time from exploited vulnerability awareness to SRP submission, against 24 hours.
• SBOM coverage: products with a current SBOM in technical documentation.

Framework mapping

Common failure patterns

• Treating labels as the law: a CLS or US label does not meet the CRA, and PSTI deemed compliance does not meet RED.
• Relying on restricted EN 18031 clauses: an optional password setting removes the presumption of conformity.
• No owner for exploited vulnerability decisions: the CRA 24-hour clock runs from awareness, including weekends.
• Support periods nobody can honour: a published end date commits engineering capacity for years.
• Shared fleet credentials: one default password or hard-coded key across a product line turns a single discovery into a fleet compromise; default credentials were what Mirai exploited. See the Mirai and IoT Botnet Families Guide.

Practitioner checklist

• Build a product by market matrix covering the six regimes.
• Remove universal default passwords and hard-coded secrets from every product line.
• Publish a vulnerability disclosure policy and a support period per product.
• Register in the ENISA SRP and rehearse 24-hour CRA reporting.
• Assess wireless products against EN 18031 and note restricted clauses.
• Classify products under the CRA and plan conformity routes before December 2027.
• Keep statements of compliance and technical documentation, including SBOMs.
• Track FCC Docket 23-239 before committing to the US label.

Standards and references

• European Commission: Cyber Resilience Act
• European Commission: CRA reporting obligations
• EUR-Lex: Delegated Regulation (EU) 2022/30 (RED cybersecurity)
• legislation.gov.uk: PSTI Security Requirements Regulations 2023
• Federal Register of Legislation: Cyber Security Act 2024 (Australia)
• eCFR: 47 CFR Part 8 Subpart B (IoT labelling)
• Cyber Security Agency of Singapore: Cybersecurity Labelling Scheme for manufacturers
• ETSI: EN 303 645 V3.1.3

Related NHI Mgmt Group resources: Global Cybersecurity Regulatory Map · EU Cyber Resilience Act Guide · IoT Security Guide · Device and IoT Identity Guide. This guide summarises product security laws and labelling schemes in the EU, UK, US, Australia and Singapore and is not legal advice.