Things You Need to Know about IEC 62443 and the Cyber Resilience Act (CRA)

Yes, the transition periods for the Cyber Resilience Act have been clearly defined. 
The regulation outlines two key transition milestones:

• September 11, 2026 – This is the date when reporting obligations begin. From this point, manufacturers must report any actively exploited vulnerabilities or incidents related to their digital products to ENISA within 24 hours.
• December 11, 2027 – This marks the date of full application. From then on, all products with digital elements placed on the EU market must fully comply with the CRA’s cybersecurity requirements, including conformity assessments, documentation, and CE marking.

The CRA applies to non-European manufacturers if they sell or offer products with digital elements in the EU market. Any company, regardless of where it is based, must comply with CRA requirements if its products are sold, distributed, or made available to EU customers.

The CRA applies to products placed on the EU market after its enforcement date (December 11, 2027). However, products already installed on sites are generally not retroactively subject to the CRA, unless they undergo a substantial modification that impacts their cybersecurity or intended purpose, or if they are sold again after the enforcement date.

CRA introduces legally binding cybersecurity requirements that align in many ways with the security controls, secure development practices, and lifecycle approaches defined in IEC 62443. CRA covers a broader product scope, but its principles (secure-by-design, vulnerability handling, documentation) map well to IEC 62443 practices.

Yes — at this moment adopting IEC 62443: 

• Prepares you ahead of CRA mandates, reducing the risk of non-compliance once CRA is enforced. 
• Strengthens overall cybersecurity posture in line with international best practices.
• Gives a competitive edge, as customers and partners increasingly require proven security credentials.
• Minimizes future adaptation costs, since many CRA requirements can be addressed through IEC 62443-aligned processes.

In short, investing in IEC 62443 now is a strategic move — it positions your organization for smoother CRA compliance while improving security and market trust.

Advantech was certified for IEC 62443-4-1 with Maturity Level 2 in September 2020. This allows us to continue pursuing IEC 62443-4-2 for components. Please refer to the Cybersecurity Guidebook for more.

According to requirements defined in the IEC 62443-4-1 SM-1 development process, a general product development/maintenance/support process is documented and enforced that is consistent and integrated with commonly accepted product development processes. Advantech established the Secure Software Development Life Cycle (SSDLC) with V-model.

For upcoming CRA requirements, SBOM and vulnerabilities scans are critically important. Advantech established an SBOM management mechanism to create/refine/review/remediate/monitor and update third-party software components with security patches. 

Advantech delivers pre-compliance reports and documentation verified by Bureau Veritas (BV). This minimizes the effort needed for official CB or VoC certification, accelerating market readiness for standards like SEMI-E187, IEC 80001, and TC65 or even CRA and RED-DA. With Advantech’s BV-reviewed reports and pre-compliance documentation, customers have credible evidence ready for submission to global certification bodies, streamlining approvals across regions.

Advantech’s platform integrates hardware (TPM 2.0, secure BIOS), OS security (Bitlocker, Secure Boot), and software controls (Trellix, Acronis) out of the box, eliminating the need for customers to build and validate these controls from scratch.

The CRA generally applies to hardware and software products with digital elements that are made available on the EU market, including final products and components placed separately on the market. It can also cover remote data processing solutions when they are necessary for a product to perform one of its functions. Certain product categories governed by specific EU legislation are excluded or treated separately.

Products placed on the EU market before 11 December 2027 are generally not subject to the full CRA requirements unless they undergo a substantial modification from that date onward. However, the CRA reporting obligations apply to products with digital elements that have already been made available on the EU market once those reporting obligations become applicable.

No. Compliance of an individual component or platform does not automatically make the final product compliant. The final manufacturer remains responsible for evaluating the complete product, including its software, configuration, interfaces, integrations, and cybersecurity risks. However, compliant or CRA-ready components can provide reusable security evidence and significantly reduce the final manufacturer's compliance effort.

The CRA requires manufacturers to identify and document vulnerabilities and components of products with digital elements as part of their vulnerability handling obligations. Manufacturers must also draw up an SBOM in a commonly used, machine-readable format covering at least the product's top-level dependencies. The CRA does not generally require the full SBOM to be publicly disclosed to customers, although relevant SBOM information may be provided depending on the product, contractual needs, and applicable standards.

Manufacturers must establish vulnerability handling processes throughout the support period. Depending on the vulnerability and its impact, customer communication can include security advisories, patches, mitigation instructions, product notifications, or other defined support channels. The objective is to provide affected users with sufficient information and corrective measures to securely address relevant vulnerabilities.

Manufacturers must define a support period during which vulnerabilities are handled and security updates are provided. The duration should reflect factors such as the product's expected lifetime, intended use, reasonable user expectations, and the availability of the product's operating environment. The end date of the support period, including at least the month and year, must be clearly communicated to users.

It depends on how the software is provided. Free and open-source software that is developed or supplied outside the course of a commercial activity is generally outside the CRA's manufacturer obligations. If free and open-source software is placed on the market as part of a commercial activity, the manufacturer obligations can apply. The CRA also introduces the role of an open-source software steward, which is subject to a lighter, tailored set of obligations.

No. CRA reporting obligations do not apply to every CVE. Mandatory reporting primarily concerns actively exploited vulnerabilities and severe incidents having an impact on the security of products with digital elements. The reporting process starts with an early warning within 24 hours of becoming aware, followed by a more detailed notification within 72 hours. Other vulnerabilities still need to be assessed, managed, and remediated, but they are not automatically subject to the 24-hour reporting obligation.

It depends on whether the change constitutes a substantial modification. Minor changes may allow much of the original conformity evidence to remain applicable. However, a modification that materially affects the product's cybersecurity or intended purpose may require additional risk assessment, testing, or a new conformity assessment. Customers should therefore evaluate how their customization affects the original product's security assumptions and conformity scope.

A vulnerability originating from an upstream or third-party component does not automatically remove the downstream manufacturer's reporting responsibility. Each manufacturer integrating the affected component must determine whether the vulnerability affects its own product and whether the CRA reporting criteria are met. Where applicable, the manufacturer of the affected product with digital elements remains responsible for submitting the required notification, even when the root cause originates in a third-party component.