Comparative Analysis of National and Regional Product Cybersecurity Frameworks

4.2 Exclusion of Baseline Security Requirements

Evaluating the differences between specific security requirements across jurisdictions would offer those implementing the frameworks some clarity on how they differ or align with one another. Secure-by-design is a key theme throughout these regimes, as nearly all of the documents aim to ensure that products are designed, developed, and produced with an appropriate level of cybersecurity. Several countries, particularly those in Europe, use ETSI EN 303 645 as the base standard for secure-by-design requirements. The standard includes 13 key cybersecurity provisions, such as prohibiting universal default passwords, requiring a VDP, and mandating software updates within a specific timeframe. However, this paper does not attempt to compare discrete controls and requirements as, in most cases, these requirements are either still in development or not directly comparable due to the differences in product scope. It is difficult, for example, to compare identity and access management controls on microprocessors in the CRA, which are currently under refinement, to those in the Singapore Cybersecurity Labelling Scheme, which are finalized. 

4.3 Scope of Covered Products and Systems

A central point of divergence across the frameworks is product scope. Many recent regulatory initiatives explicitly extend beyond consumer IoT to cover enterprise software, cloud-connected services, and industrial or operational technology systems. In contrast, voluntary schemes tend to focus narrowly on consumer-facing products, prioritizing transparency and consumer awareness.

On one end of the regulatory spectrum, the EU’s Cyber Resilience Act expanded from only focusing on IoT devices to instead covering all products with digital elements. Product security, by this definition, encompasses “a software or hardware product and its remote data processing solutions, including software or hardware components being placed on the market separately.” The EU CRA’s unique scope— the broadest of all product security regulations currently in the ecosystem—not only targets the component level, but also includes consumer, enterprise, and industrial/OT requirements. Other regulations, in comparison, either focus on consumer IoT (UK, U.S. Cyber Trust Mark, Japan, Singapore, Australia) or on enterprise software (FAR requirements in the United States). South Korea, meanwhile, intends to target both consumer and enterprise software, and Canada is looking toward enterprise software and industrial/OT.

For regulators, this raises important questions about boundary definitions, particularly where products transition across consumer, enterprise, and critical infrastructure contexts. International standards organizations have established definitions for each of these categories of products, but policymakers will need to consider which set of users they intend to impact before pursuing new regulations or expanding the scope of current requirements.

None of the regulations included in this evaluation cover medical devices or automotive devices. In most cases, this is because there are preexisting regulatory requirements in place to cover such devices, though it should be noted that aftermarket parts, non-type-approved components, software, and charging infrastructure may be subject to regulations like the CRA.

4.4 Incident Reporting and Vulnerability Disclosure Obligations

Vulnerability disclosure obligations and incident reporting policies are frequently treated as core regulatory expectations. Determining their prioritization across the policy ecosystem can therefore highlight potential harmonization opportunities. 

Vulnerability reporting is a relatively nascent regulatory push; currently, only the CRA requires the reporting of actively exploited vulnerabilities. However, other regimes address vulnerabilities as a part of product security regulations. Regulations in the EU, UK, Japan, and Singapore explicitly require those subject to their requirements to publish a coordinated vulnerability disclosure (CVD) policy. Though not yet to the point of explicit requirements, South Korea has indicated it is moving in this direction and Australia currently requires that “manufacturers publish a means to report security issues,” though not necessarily in a formal CVD policy. 

Outside of vulnerability disclosure obligations, several of the product security regulations require cybersecurity incidents be reported to a designated national authority. The EU, FAR cases in the United States, and Canada require incident reporting, though they diverge on their reporting timeline. The EU and Canada require an initial report within 24 hours of an incident being discovered, with a more detailed report required in 72 hours. The United States, on the other hand, is set to require initial reporting within 8 hours, followed by the same 72-hour more detailed report. These differences in reporting timelines will complicate cross-border incident management and suggest an opportunity for greater alignment around common reporting principles.

Notably, some regulations require incident reporting even if the incident occurs on the product owner’s network, but the impact to the product is still unknown. The CRA, for example, requires reporting if an incident “negatively affects or is capable of negatively affecting the ability of a product with digital elements to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions.” This could trigger a reporting requirement, even if the incident occurred on a corporate business network, rather than in a production environment. Similarly, the U.S. FAR Council draft rule requires Federal contractors to report incidents impacting their networks, regardless of whether the incident in question directly impacts a product sold to the government. 

Finally, the EU CRA leaves some ambiguity around incident reporting frequency depending on the impacted organization’s level of awareness. Consider a scenario where a manufacturer reports an incident stemming from an exploited vulnerability in their product. That same vulnerability could trigger multiple incidents. In some cases, the product owner may not even be aware of the impacted entity, whether because the incident was identified and reported by an integrated device manufacturer or because it was identified and reported by another company in the supply chain. As a result, a single vulnerability could generate numerous incident reports filed by multiple supply chain actors, each reporting based on their own awareness of the incident. This dynamic will likely result in significant overreporting and will require ENISA to triage incoming reports to assess the full extent of the vulnerability or incident’s impact. More broadly, this example highlights the complexity of designing a regulatory regime that tracks incidents and vulnerabilities across a broad spectrum of product types.

4.5 Software Supply Chain Transparency and SBOM Expectations

Software supply chain risk management, including the use of software bills of materials, is an emerging area of regulatory convergence. While some frameworks impose explicit SBOM requirements (EU, U.S. Cyber Trust Mark, U.S. FAR Cases, and South Korea), others establish implicit expectations through broader risk management or documentation obligations (UK). Notably, other regimes did not include an SBOM expectation at all (Canada, Japan, Australia). Regulators therefore face the challenge of balancing transparency objectives with concerns around administrative burden, confidentiality, and the operationalization of SBOM data.

4.6 Product Lifecycle and End-of-Support Policies

Several product security frameworks include product lifecycle support. The CRA has a specified support window of 5 years that can be superseded by a manufacturer’s declared support window. This reliance on a public declaration of product support is echoed in Australia and the UK, while Singapore’s label is only valid while the product is under support. Other regimes do not include product lifecycle as a component of their regulations. 

One aspect of this product lifecycle requirement that warrants further study is what constitutes a change to the product significant enough to trigger a new product support window. Europe is currently evaluating this question as part of the CRA implementation process, while other governments have yet to address this versioning issue. This distinction matters, as it will likely impact how frequently a product is subject to regulatory evaluation, whether through third party assessment, self-attestation, or another mechanism. 

5. Penalties for Non-Compliance

The penalties for non-compliance vary across these regimes. Given that many of these schemes are voluntary in nature, non-compliance would simply mean a revocation or denial of the label or designation (U.S. Cyber Trust Mark, Singapore, Japan). Similarly, for those requirements that are mandatory in order to qualify for government procurement, non-compliance would mean either a failed tender or possible removal from government networks and ecosystems (U.S. FAR Cases). Several other frameworks include monetary penalties: the UK requires up to £10M or 4% turnover; the EU requires €15 million or 2.5% turnover; Australia’s is AUD$50 million, three times the benefit obtained, or 30% of adjusted turnover; and South Korea will implement fines up to 3 to 10% of sales for severe or repeated breaches, with possible criminal charges depending on the severity of the negligence.

Indeed, these product markets are inherently global. It remains to be seen whether manufacturers wind up being penalized in multiple jurisdictions for failures to meet cybersecurity requirements. In evaluating the efficacy of their frameworks, policymakers should consider whether the nature of the enforcement mechanism leads to materially different product cybersecurity outcomes when compared to other jurisdictions.

6. Implications for International Regulatory Harmonization

By categorizing the components that comprise product security regimes across a number of key geographies, this report provides a grounded framework for exploring the differences in national and regional approaches. This report provides policymakers with a primer for international dialogue on harmonization or reciprocity and mutual recognition in product security. If countries can articulate that their regulations will address, for example, product scope, incident and vulnerability reporting, vulnerability disclosure, product lifecycle, and regulatory incentivization, then determining the specific requirements, timelines, thresholds, penalties, etc. within these categories can be discussed as a matter of national prioritization. Without agreement on what issues need to be addressed, however, it will be very challenging to harmonize the specific requirements across regimes. 

8. Conclusion

As product cybersecurity regulation continues to expand, comparative analysis provides a critical foundation for informed international dialogue. By identifying both convergence and divergence across existing frameworks, stakeholders can better target harmonization efforts that enhance security outcomes while minimizing regulatory fragmentation and duplicative compliance activities.