The movement towards connected-product security has transformed voluntary guidance into a legal requirement for market access. An IoT manufacturer may now need to document secure-by-design decisions, eliminate default passwords, provide the channel for reporting vulnerabilities, pledge security support, maintain the list of software materials used, provide secure updates as well as report all vulnerabilities.

The dates are not interchangeable. The European Union's Cyber Resilience Act (CRA) begins applying its reporting duties on 11 September 2026, but most CRA obligations apply from 11 December 2027. Australia's smart-device standards already apply to most in-scope products manufactured on or after 4 March 2026.

The regulations in the United Kingdom have been in effect since 2024. In the United States, the U.S. Cyber Trust Mark has remained optional, with federal procurement procedures alongside connected medical device regulations being independent and enforceable in their respective situations.

This tracker explains those differences. It is written for IoT product companies, embedded engineering teams, importers, distributors, compliance managers and technology buyers. It is an informational research resource, not legal advice.

Product scope, exemptions and national implementing rules should always be confirmed for the actual device, software, supply chain and target market.

The six dates IoT teams should put on the calendar

Date Jurisdiction What changes Why it matters
2 February 2026 United States FDA's Quality Management System Regulation became effective. Connected medical-device makers must operate under the revised quality-system framework, alongside the cyber-device requirements in section 524B of the FD&C Act.
4 March 2026 Australia Mandatory security standards commenced for most consumer-grade smart devices manufactured on or after this date. Manufacturers and suppliers need compliant password controls, a vulnerability-reporting route, a published support period and a statement of compliance.
1 July 2026 China The China Cybersecurity Label management measures took effect. Participation is voluntary, but connected-product makers can use a regulated one-, two- or three-star label; the first catalogue covers consumer connected cameras.
11 September 2026 European Union CRA reporting obligations begin. Manufacturers must report actively exploited vulnerabilities and severe product-security incidents through the CRA Single Reporting Platform. The duty also reaches products already made available in the EU.
11 December 2027 European Union The CRA's main obligations become applicable. In-scope hardware, software and connected components need lifecycle security, conformity assessment, technical documentation, vulnerability handling and CE-related compliance.
11 June 2028 European Union Certain pre-existing EU type-examination certificates and approval decisions concerning cybersecurity cease to remain valid, unless they expire earlier. Manufacturers relying on transitional approvals should plan their reassessment route before this date.

How to read this tracker

The word mandatory means the measure creates a binding legal or market-access obligation for the stated scope. Voluntary label means participation is optional, although retailers, public buyers or enterprise customers may prefer labelled products.

Procurement rule applies when a government or other covered buyer purchases or uses a device.

Operator rule regulates an organisation or service rather than imposing a general product-design law. Proposal means the text can still change and should not be treated as enacted law.

This distinction matters. A smart camera sold to a European consumer, an industrial sensor installed by an essential-service operator and an internet-connected medical device can all be called “IoT,” but their compliance routes may be completely different.

Global IoT cybersecurity regulation tracker

Jurisdiction Instrument or programme Status as of 25 Aug 2026 Main scope Key date or current position Immediate action for product teams
European Union Cyber Resilience Act, Regulation (EU) 2024/2847 Mandatory product law Hardware and software products with a direct or indirect data connection, including separately marketed components and relevant remote data-processing functions; defined exclusions apply Reporting: 11 Sep 2026. Main obligations: 11 Dec 2027. Transitional certificates: 11 Jun 2028 Establish CRA ownership, register reporting users, map every EU SKU, determine product class, build the technical file and prove vulnerability handling across the support period.
European Union Radio Equipment Directive cybersecurity requirements under Delegated Regulation (EU) 2022/30 Mandatory for covered radio equipment Specified internet-connected radio equipment, wearables, toys and childcare radio equipment Applicable since 1 Aug 2025; the delegated act is scheduled to be repealed from 11 Dec 2027 as the CRA takes over the horizontal product-security role Confirm the conformity route and applicable harmonised standards for radio products placed on the market before the CRA transition. Do not assume RED work alone proves full CRA compliance.
European Union NIS2 Directive Mandatory operator law through national legislation Essential and important entities in sectors such as energy, transport, health, digital infrastructure and manufacturing of certain critical products Member State transposition deadline was 17 Oct 2024. A 2026 EU proposal would amend and simplify parts of NIS2, but it is not the current final law If the IoT system operates an essential or important service, map organisational risk-management and incident-reporting duties separately from product obligations under the CRA.
United Kingdom Product Security and Telecommunications Infrastructure Act 2022 and Product Security Regulations 2023 Mandatory product law Manufacturers, importers and distributors of relevant consumer connectable products; exemptions apply In force since 29 Apr 2024 Use unique or user-defined passwords, publish security-issue reporting information and response times, disclose the minimum security-update period and ensure a statement of compliance accompanies the product.
United Kingdom Cyber Security and Resilience (Network and Information Systems) Bill Proposal, not final law Essential services, digital services, relevant managed service providers and designated critical suppliers Introduced to Parliament on 12 Nov 2025; government factsheets were updated in 2026 Track the parliamentary text if supplying managed services, operational technology or systems used by UK critical services. Do not describe the Bill as enacted.
Australia Cyber Security Act 2024 and Cyber Security (Security Standards for Smart Devices) Rules 2025 Mandatory product law Most smart devices manufactured on or after 4 March 2026 and intended for personal, domestic or household use; listed devices such as desktops, laptops, smartphones and tablets are excluded Rules commenced 4 Mar 2026 Remove universal default passwords, publish a vulnerability-reporting mechanism and support end date, prepare the statement of compliance and control supplier records.
United States U.S. Cyber Trust Mark Voluntary federal label Eligible wireless consumer IoT products Rules have been effective since 2024, but programme implementation changed. ioXt became Lead Administrator on 13 Apr 2026, and the FCC opened a Cybersecurity Label Administrator filing window on 11 Aug 2026 Monitor the FCC programme page for the point at which product applications are accepted. Do not market a product as certified before approval.
United States IoT Cybersecurity Improvement Act of 2020 and NIST SP 800-213 Federal procurement requirement IoT devices procured or used by US federal agencies, subject to statutory rules and waivers Current; NIST published an initial public draft of SP 800-213 Rev. 1 in June 2026 If targeting federal buyers, translate NIST device and manufacturer capabilities into contract evidence. Consumer-market compliance alone is not enough.
United States FD&C Act section 524B and FDA cybersecurity guidance for cyber devices Mandatory sector-specific law Internet-connected medical devices containing software and technological characteristics vulnerable to cyber threats Section 524B submission requirements have applied since 29 Mar 2023; revised FDA QMSR effective 2 Feb 2026 Maintain a post-market vulnerability plan, secure-development and patch processes, and an SBOM for commercial, open-source and off-the-shelf components.
China Cybersecurity Law, as amended Mandatory horizontal law Network construction, operation, maintenance and use in China; product-specific and sector rules can apply in addition Amended law effective 1 Jan 2026 Obtain local legal review for network, data, incident and product obligations. Do not treat a foreign product certificate as a substitute for Chinese requirements.
China China Cybersecurity Label management measures Voluntary regulated label Internet-connected products listed in product catalogues; the first catalogue covers consumer connected cameras and excludes public-security cameras Measures effective 1 Jul 2026; participation is expressly voluntary. Camera labels are valid for three years under the first implementation rules Decide whether the market benefit justifies testing and filing. Preserve chip, firmware, communication-module and security-configuration evidence because changes can trigger re-testing.
Japan Japan Cyber STAR, or JC-STAR Voluntary national label IoT products evaluated against defined conformance requirements; assurance rises by level STAR-1 applications accepted since 25 Mar 2025; programme documents and higher-level processes continued to develop in 2026 Determine the required STAR level and reuse eligible evidence for mutual-recognition routes where available. A label indicates baseline conformity, not perfect security.
Singapore Cybersecurity Labelling Scheme for IoT, or CLS(IoT) Mostly voluntary label; mandatory for Wi-Fi routers at Level 1 Consumer smart devices, with four assurance levels; Wi-Fi routers sold for local use require Level 1 Mutual recognition with the UK took effect 1 Jan 2026 and with Japan 1 Jun 2026; arrangements also exist with Germany and South Korea Use the mutual-recognition path when eligible to reduce duplicated evaluation. Check device-category and assurance-level conditions rather than assuming one label automatically transfers.
India MTCTE/ComSec and Indian Telecom Security Assurance Requirements Mandatory for notified telecom equipment Notified telecom equipment, including specified IP routers, Wi-Fi CPE and optical network terminals IP router and Wi-Fi CPE security certification has been mandatory since 1 Oct 2024. ONT security certification became mandatory 1 Jan 2026. A two-year Pro Tem route is available under stated conditions Identify the exact notified product category and current ITSAR. Budget for an Indian testing/certification path and do not generalise a telecom certificate to every IoT device.
India CERT-In Directions of 28 April 2022 Mandatory incident and operational rule for covered entities Service providers, intermediaries, data centres, body corporates and government organisations within the directions' scope Covered cyber incidents generally must be reported to CERT-In within six hours of noticing them or being informed of them Make the six-hour clock part of the incident plan, preserve required logs and decide in advance who has authority to submit a report.
Brazil Anatel cybersecurity requirements, including Acts No. 77/2021 and No. 2,436/2023 Mandatory telecom product conformity requirements Telecommunications products; Act 2,436 adds minimum requirements for consumer CPE such as cable/xDSL modems, ONUs/ONTs, FWA or satellite broadband routers and wireless routers/access points Current Build evidence for password security, unnecessary ports and protocols, software/update support and other applicable Anatel requirements as part of product homologation.
Saudi Arabia Communications, Space and Technology Commission IoT Regulations and Cybersecurity Regulatory Framework Mandatory within stated regulatory scopes IoT service provision and CST-regulated ICT service providers; applicability depends on the business model and service Updated IoT Regulations were issued in 2024 and stated to apply 60 days after publication Confirm whether the company is providing a regulated IoT service, merely supplying a device, or both. Map CST, national cybersecurity, cloud, data and type-approval obligations accordingly.
United Arab Emirates TDRA Type Approval Regime for Telecommunications Equipment Mandatory equipment market-access regime Telecommunications equipment imported, supplied or used in the UAE, with assessment depth based on risk and product category Current Type Approval policy includes security aspects and cybersecurity-standard compliance where applicable Obtain type approval before sale, classify the device correctly and assess whether firmware or operating-system changes require new testing or notification.

European Union: why 11 September 2026 is not a rehearsal date

The CRA is the most consequential horizontal product-cybersecurity law in this tracker because it covers a broad range of hardware and software made available on the EU market.

A “product with digital elements” can include a finished IoT device, separately marketed software or hardware components and a remote data-processing solution without which the product could not perform one of its functions

What begins on 11 September 2026

From 11 September 2026, manufacturers must notify actively exploited vulnerabilities and severe incidents affecting the security of products with digital elements. The European Commission describes the reporting sequence as:

  • An early warning within 24 hours of awareness;
  • A fuller notification within 72 hours;
  • For an actively exploited vulnerability, a final report no later than 14 days after a corrective or mitigating measure becomes available; and
  • For a severe incident, a final report within one month after the 72-hour notification.

Reports go through ENISA's CRA Single Reporting Platform. The reporting duties are important for legacy portfolios: the Commission states that they apply to products with digital elements already made available on the EU market, including products placed there before 11 December 2027.

That means a manufacturer cannot safely postpone its incident workflow until the full CRA date. By September 2026 it should already know which entity is the manufacturer, where its main EU establishment is, which teams can decide that a vulnerability is actively exploited, and who can submit the 24-hour warning when the available facts are incomplete.

What becomes applicable on 11 December 2027

According to the principal CRA regulations, the producers are expected to carry out a cybersecurity risk assessment that will be employed throughout the product's planning, design, development, production, transportation, and maintenance phases. The technical documentation has to describe both the assessment and the adequacy of the essential cybersecurity requirements.

It is important for the product to adopt the correct compliance assessment process, provide the necessary compliance evidence and include the end of the support life.

As far as the engineering implications are concerned, we need to take on board secure-by-design and secure-by-default configuration protocols, ensuring confidentiality, integrity and availability, minimizing the potential attack surfaces, applying secure update processes, ensuring that vulnerabilities are resolved and maintaining the practice of acknowledging third-party solutions.

Important class II and critical products require third-party assessment; class I products can also require it when the prescribed self-assessment conditions are not met.

The key CRA transition nuance is this: a pre-11 December 2027 product generally comes under the main product requirements after that date if it undergoes a “substantial modification,” while the reporting duties apply more broadly to products already made available. Product lifecycle, maintenance releases and end-of-support decisions therefore need legal as well as engineering review.

On 27 July 2026, the Commission published practical, non-binding CRA guidance addressing questions such as remote data-processing solutions, substantial modification, support periods, reporting and risk assessments.

ENISA also maintains live guidance and FAQs for the Single Reporting Platform. Teams should use those current implementation resources together with the binding legal text

United Kingdom and Australia: similar baseline, separate evidence

The UK and Australian regimes share a recognisable baseline derived from international consumer-IoT practice:

  • No universal default passwords;
  • A published way for people to report security issues; and
  • Transparent information about the minimum security-update or support period.

The similarity is useful, but a single generic declaration should not be used without checking each law.

Manufacturers, importers, and distributors have been assigned specified supply-chain responsibilities under the UK PSTI regime. In order for a PSTI compliance declaration to be valid, it must also submit a product statement.

Moreover, manufacturers must publish information related to vulnerability-reporting, which details acknowledgment timelines, status updates, and the minimum security-update duration with an endpoint.

Australia's rules apply to most in-scope smart devices manufactured on or after 4 March 2026 for personal, domestic or household use. They also require a statement of compliance, and suppliers must not supply a product that is required to comply but does not.

Manufacturing products that were made prior to the commencement date is handled in a special way, which increases the importance of the manufacturing records and SKU traceability.An efficient solution for one international product is a shared control system that provides different declarations, retention periods and legal entities responsible in different jurisdictions.

United States: do not confuse a voluntary label with federal procurement or FDA law

There is no single US law equivalent to the EU CRA for every consumer IoT product. Instead, several layers apply.

The U.S. Cyber Trust Mark is a voluntary labelling programme for wireless consumer IoT products. Its administration changed during 2026: the FCC selected ioXt Alliance as the new Lead Administrator in April and opened a filing window for Cybersecurity Label Administrators on 11 August. Manufacturers should follow the FCC's live programme page rather than relying on older launch announcements.

The IoT Cybersecurity Improvement Act of 2020 matters to federal sales. Federal procurement rules can prohibit acquisition or use of IoT devices that prevent compliance with NIST SP 800-213, subject to the statutory framework and waivers.

NIST's guidance focuses on the device capabilities and manufacturer support needed to satisfy system security controls. NIST also released a draft revision of SP 800-213 in 2026, so federal suppliers should monitor the finalisation process.

For connected medical products, section 524B of the FD&C Act is not voluntary.

To qualify for a premarket submission, a cyber device must present plans for monitoring, identifying, and resolving vulnerabilities and exploits occurring after the device is on the market, processes ensuring a high level of cybersecurity of the device and systems connected, post-market updates and patches, and an SBOM covering commercial, open-source, and off-the-shelf components.

The FDA's QMSR became effective on 2 February 2026 and incorporates ISO 13485:2016 by reference into the device quality-system framework

China, Japan and Singapore: cybersecurity labels are becoming trade infrastructure

The revised Cybersecurity Law in China came into force on 1 January 2026, which is a general network safety law instead of just an IoT law. It can exist together with regulations regarding data, vulnerability, incident, sector, and product.

The distinct Cybersecurity Label regulations in China became effective on 1 July 2026. These regulations state that participation is voluntary and describe three levels of cybersecurity represented by one, two and three stars.

The first product catalogue covers consumer connected cameras. Its implementation rules examine hardware, firmware, communication modules, network exposure, authentication, access control, encryption, data protection and security assurance.

A camera label is valid for three years, but material technical changes can require fresh testing and filing.

Japan's JC-STAR also uses levels. STAR-1 began accepting applications in March 2025, while the scheme continued to publish operational and assessment material in 2026. Japan's regulator cautions that the label confirms conformance with the relevant baseline; it does not guarantee complete security.

There are four levels in Singapore's CLS(IoT). While for most devices this standard is voluntary, it is compulsory at Level 1 for Wi-Fi routers that are marketed for use in the country. Singapore has developed mutual recognition procedures with various other schemes.

Its arrangement with the UK took effect on 1 January 2026, and its arrangement with Japan took effect on 1 June 2026. Recognition is conditional: manufacturers must check the product category, label level and applicable application process.

Although these schemes are not yet a universal “passport,” they reveal where the trade in IoT is heading in the future, common evidence, reuse of tests, and harmonization between regulators are increasingly becoming part of international trade in IoT.

India, Brazil and the Gulf: classify the device before choosing a compliance route

The current Indian mandatory pathway for cybersecurity is especially noteworthy in terms of telecom equipment. The MTCTE and ComSec systems stipulate that devices cannot be supplied, used, or operated before their compliance is confirmed.

Security certification for IP routers and Wi-Fi CPE became mandatory on 1 October 2024, and ONT security certification became mandatory on 1 January 2026. The government has extended a Pro Tem certification mechanism, but it remains a defined compliance route rather than an exemption from security obligations.

Separately, the CERT-In Directions impose a fast cyber-incident clock on covered entities. Specified incidents generally must be reported within six hours. A multinational incident plan should therefore not use the CRA's 24-hour early-warning period as its fastest default; the Indian clock may expire first.

Brazil's Anatel framework associates cybersecurity requirements with compliance and homologation of telecommunications products. Under Act No. 2,436/2023, consumer CPE is included which encompasses many types of broadband modem, ONU/ONT, and router.

The Act addresses certain weaknesses, such as the presence of default factory passwords and unwarranted active services or communication ports. Phone applications and other telecom products will have unique requirements as well.

Saudi Arabia's CST regulates IoT services and separately maintains a cybersecurity framework for regulated ICT service providers. The UAE's TDRA uses a type-approval regime for telecommunications equipment that can require technical and security testing depending on product risk and category.

In both markets, teams should first determine whether they are supplying equipment, operating a regulated IoT/communications service, processing regulated data or doing more than one of those things.

The incident-reporting clock: one event, several deadlines

Regime Typical trigger in this tracker First external deadline Later stages
EU CRA Awareness of an actively exploited product vulnerability or a severe security incident Early warning within 24 hours Main notification within 72 hours; final report timing depends on whether it is a vulnerability or incident
EU NIS2 A significant incident affecting a covered essential or important entity Early warning within 24 hours Incident notification within 72 hours; final report generally within one month
India CERT-In Directions A specified cyber incident affecting a covered entity Generally within 6 hours of noticing it or being informed Preserve logs and provide additional information requested by CERT-In

These clocks measure different legal triggers. “We did not yet know the root cause” is not a safe reason to wait when an early warning is required. A defensible global plan uses staged notification, separates confirmed facts from preliminary indicators and records the time at which the organisation first became aware.

A control matrix that can support several markets

Reusable control EU CRA UK PSTI Australia US federal/label ecosystem China label Japan/Singapore labels
Unique credentials or user-defined passwords Yes Yes Yes Common baseline Basic-level theme Common baseline
Coordinated vulnerability disclosure channel Yes Yes Yes NIST/Federal requirement theme Yes Yes
Public support or update period Yes Yes Yes Common label/procurement evidence Support evidence relevant Common baseline
Secure, authenticated update mechanism Yes Indirectly relevant to support commitment Indirectly relevant to support commitment Common baseline Yes Yes
Product risk or threat assessment Yes Good supporting evidence Good supporting evidence NIST/FDA expectation depending on scope Higher assurance evidence Higher assurance evidence
SBOM and third-party component control CRA vulnerability-handling evidence Strong supporting evidence Strong supporting evidence Mandatory for FDA cyber devices; useful elsewhere Useful evidence Useful evidence
Incident/vulnerability reporting runbook Mandatory Needed for product response Needed for product response Sector and contract dependent Horizontal rules may apply Scheme and national rules dependent
Technical file, declaration or conformity record Yes Statement of compliance Statement of compliance Application/contract evidence Test report, declaration and filing Label application evidence

“Reusable” does not mean “identical.” A single secure-development lifecycle can generate evidence for several markets, while the legal declaration, responsible entity, language, test route and retention requirement remain jurisdiction-specific.

Practical 12-step compliance plan for an IoT manufacturer

1. Build a product and market register

Write down the details of all the commercial SKU, private label versions, revisions of hardware, branches of firmware, apps compatible with the device, cloud services it depends upon, radio device used, target users and market. Remember to write down the name of the legal producer, importer and distributor for every given market.

2. Decide what the “product” includes

In the context of the modern Internet of Things, the regulated product might go beyond just a hardware enclosure. Thus, one should consider the firmware of the device, the mobile application, the APIs, the identity services, the update server, and all necessary remote processing as the one security perimeter under regulations.

3. Classify the product in every jurisdiction

Do not start with a test laboratory. First establish whether the item is a consumer connectable product, radio equipment, telecom CPE, a medical cyber device, an industrial component, an important or critical CRA product, or an excluded product.

4. Create a requirements traceability matrix

Link each legal requirement to a design control, source-code or configuration location, test case, evidence owner and release gate. Record the legal version and verification date so a later rule change can be assessed efficiently.

5. Make identity secure at manufacturing time

Eliminate universal credentials. Use unique device identities and protected key injection where appropriate. Prevent predictable credentials derived from serial numbers. Define secure onboarding, credential rotation, account recovery and factory-reset behaviour.

6. Engineer a trustworthy update path

Updates need to be properly verified for their integrity and also the rollback prevention should take place where necessary. It is best to think of possible interruptions in the power supply or network connection. A test is to be conducted to examine the process of recovering from an unsuccessful update.

7. Control components and produce an SBOM

Maintain component names, suppliers, versions, licences, hashes or package identifiers and known-vulnerability status. Define how the organisation receives upstream advisories and how it handles abandoned components. Use VEX where appropriate to communicate whether a listed vulnerability is exploitable in the product context.

8. Operate a product-security response team

Publish a stable vulnerability-disclosure page and security.txt, acknowledge reports, protect good-faith researchers and define severity and remediation targets. The process should remain available for the full declared support period.

9. Build one global incident playbook with local branches

Take note of the length of awareness, different variants of affected products and whether the offense occurred, as well as its impact on the users and responses that were made for containment purposes. Prepare decision trees for the time periods of 6, 24 and 72 hours for the countries involved. Establish cooperation of the lawyers, engineers and PR experts on all levels.

10. Prove security, not merely state it

Retain threat models, architecture reviews, static and dynamic analysis, protocol fuzzing, penetration tests, cryptographic design records, manufacturing controls, update tests and remediation evidence. Tie every test to the actual production configuration.

11. Publish an honest support policy

State the security-support end date clearly. Align sales commitments, component availability, cloud cost, vulnerability monitoring and engineering staffing with that date. Define what happens to user data and critical functions when support ends.

12. Reassess every material change

A chipset replacement, operating-system upgrade, new cloud provider, added radio, changed authentication flow or major firmware update can alter the attack surface and the conformity position. Put regulatory impact review inside change control.

Compliance evidence checklist

A regulator, notified body, laboratory, enterprise buyer or security reviewer may ask for some or all of the following:

  • Product and version identification;
  • Intended use and reasonably foreseeable misuse;
  • Cybersecurity risk assessment and threat model;
  • System, trust-boundary and data-flow diagrams;
  • Secure-development lifecycle records;
  • Access-control and credential design;
  • Cryptographic design and key-management records;
  • Secure-boot and update design, including rollback and recovery;
  • SBOM, component-monitoring and supplier due-diligence records;
  • Vulnerability-disclosure policy and response metrics;
  • Penetration, fuzz, static-analysis and dynamic-analysis reports;
  • Security-support period and end-of-support plan;
  • Incident classification and regulatory-reporting procedure;
  • User security instructions;
  • Conformity assessment, declarations, labels and certificates; and
  • Post-market monitoring, corrective-action and recall procedures.

Frequently asked questions

When do the EU Cyber Resilience Act requirements apply?

From September 11, 2026, the CRA reporting obligations come into effect. Most other duties start from December 11, 2027. Provisions relating to the notifications of conformity assessment body entered into force on June 11, 2026, whereas some earlier certificates related to cyber examination and approvals remain valid until June 11, 2028, unless they get expired earlier.

Does the CRA apply only to new products launched after December 2027?

No. The reporting duties also apply to products already made available on the EU market. For the main product obligations, products placed on the market before 11 December 2027 are generally affected if they undergo a substantial modification after that date. The precise facts and the Commission's current guidance should be checked.

Are UK PSTI compliance and Australian compliance the same?

The answer is no. Though both of them share 3 common themes of governance they are separate jurisdictions with different regulators, exemptions and requirements in terms of records keeping and declarations.

Is the U.S. Cyber Trust Mark mandatory?

No. It is a voluntary FCC programme for eligible wireless consumer IoT products. That does not remove separate obligations under federal procurement rules, FDA law, state law, consumer-protection law or a contract.

Does a cybersecurity label prove a device is completely secure?

No. A label indicates that a product met defined requirements at an assurance level and point in time. It cannot guarantee the absence of future vulnerabilities. Continuous monitoring, patching and incident response remain necessary.

Do industrial IoT devices fall under consumer smart-device laws?

Not automatically. Some consumer regimes may exclude enterprise or industrial equipment, while the EU CRA can still cover commercially supplied hardware or software with digital elements. Operator rules such as NIS2 may apply to the organisation using the system, and sector rules can apply to medical, automotive, telecom or critical-infrastructure use.

What is the best first investment for global compliance?

Develop a product-security management system for product inventory that integrates secure software development, visibility of components, vulnerability management, signed software upgrades, governance of software support period, and an incident reporting clock. These functions create verifiable evidence applicable to the majority of jurisdictions.

Official sources and further reading

https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act

https://digital-strategy.ec.europa.eu/en/policies/cra-summary

https://digital-strategy.ec.europa.eu/en/policies/cra-reporting

https://digital-strategy.ec.europa.eu/en/factpages/cyber-resilience-act-implementation

https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng

https://www.gov.uk/government/publications/the-uk-product-security-and-telecommunications-infrastructure-product-security-regime

https://www.gov.uk/government/collections/cyber-security-and-resilience-bill

https://www.homeaffairs.gov.au/about-us/our-portfolios/cyber-security/security-standards-for-smart-devices

https://www.legislation.gov.au/C2024A00098/asmade/text

https://www.fcc.gov/CyberTrustMark

https://www.fcc.gov/document/pshsb-conditionally-approves-usctm-clas-and-opens-cla-filing-window

https://csrc.nist.gov/pubs/sp/800/213/final

https://csrc.nist.gov/pubs/sp/800/213/r1/ipd

https://www.fda.gov/medical-devices/digital-health-center-excellence/cybersecurity-medical-devices-frequently-asked-questions-faqs

https://www.fda.gov/medical-devices/postmarket-requirements-devices/quality-management-system-regulation-qmsr

https://www.cac.gov.cn/2025-12/29/c_1768735112911946.htm

https://www.cac.gov.cn/2026-04/10/c_1777558393316312.htm

https://www.cac.gov.cn/2026-06/18/c_1783525604615337.htm

https://www.ipa.go.jp/en/security/jc-star/index.html

https://www.csa.gov.sg/our-programmes/certification-and-labelling-schemes/cybersecurity-labelling-scheme/about/

https://www.csa.gov.sg/news-events/press-releases/singapore-signs-mou-with-the-united-kingdom-on-cooperation-on-mutual-recognition-of-consumer-internet-of-things-cyber-security-regimes/

https://www.csa.gov.sg/news-events/press-releases/singapore-signs-memorandum-of-cooperation-with-japan-on-mutual-recognition-of-internet-of-things-cybersecurity-schemes/

https://www.cert-in.org.in/Directions70B.jsp

https://mtcte.tec.gov.in/

https://www.pib.gov.in/PressReleasePage.aspx?PRID=2209569

https://www.gov.br/anatel/pt-br/assuntos/seguranca-cibernetica/requisitos-para-equipamentos

https://www.cst.gov.sa/en/regulations-and-licenses/regulations/Document-1602

https://www.cst.gov.sa/en/regulations-and-licenses/regulations/Document-413

https://tdra.gov.ae/-/media/About/Type-approval-PDF/Type-Approval-Policy-V4-EN.ashx

https://digital-strategy.ec.europa.eu/en/policies/nis2-directive

https://eur-lex.europa.eu/eli/reg_del/2022/30/oj/eng

https://eur-lex.europa.eu/eli/reg_del/2026/339/oj/eng

https://digital-strategy.ec.europa.eu/en/library/commission-publishes-new-guidance-support-timely-cyber-resilience-act-implementation

https://www.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/frequently-asked-questions