I. Abstract

In recent years, the European Union has continued to advance digital transformation and cybersecurity policies. Following the General Data Protection Regulation (GDPR), the Cyber Resilience Act (CRA) is regarded as one of the cybersecurity regulations with the most far-reaching impact on the manufacturing sector. The CRA applies to “products with digital elements” (PDEs), covering any hardware or software product that can be connected directly or indirectly to a device or network, as well as its remote data processing solutions. It requires companies to establish product lifecycle management covering design, development, maintenance, vulnerability management, security updates, and incident reporting.

For Taiwan’s machine tool industry, as Industry 4.0 and smart manufacturing continue to progress, modern machine tools have become highly digitalized and connected. They now serve as core hubs in industrial automation control systems, integrating digital products such as CNC controllers, PLCs, industrial computers, industrial networks, edge computing, and cloud services. As such, they also fall within the CRA’s scope of “products with digital elements,” making compliance a critical requirement for entering the European market.

This article introduces the core concepts and key provisions of the CRA and analyzes its relationship with IEC 62443 and the EN 40000 series, helping companies plan cybersecurity compliance strategies for the European market in advance.

 

II. What Is the CRA?

The EU Cyber Resilience Act, or CRA, formally Regulation (EU) 2024/2847, aims to establish minimum cybersecurity requirements for “products with digital elements” (PDEs) placed on the EU market. Under the regulation, a product with digital elements refers to any software or hardware product, together with its remote data processing solutions, whose intended or reasonably foreseeable use includes a direct or indirect logical or physical connection to a device or network.

The scope of products with digital elements (PDEs) is very broad and includes:

• Hardware and software: including hardware and software components placed on the market independently, such as microprocessors and embedded software, as well as various end devices, including smart home appliances, routers, wearable devices, mobile applications, operating systems, and others.
• Remote data processing solutions: if a product must rely on a cloud backend developed by the manufacturer to perform its core functions, that remote backend is also considered part of the PDE.

The level of regulatory scrutiny is determined by the degree of cybersecurity risk, privileged functions, and the potential impact on broader systems if the product is compromised. The CRA divides products into three main levels: Default, Important products (further divided by risk into Class I and Class II), and Critical products.

 

Figure 1. CRA Four-Level Product Risk Framework

 

The following provides a detailed introduction and description of each category:

Default Category

• Category description: This is the most basic category and covers approximately 90% of digital products on the market. Products that are not listed as “important products” under Annex III or “critical products” under Annex IV of the CRA, and that do not have high system sensitivity or core network management functions, are automatically classified in this category.
• Product examples: ordinary smart light bulbs, smart thermostats, home appliances without connectivity, personal wearable wristbands that are not medical devices, Bluetooth headsets, and similar products.
• Compliance requirements: Because the cybersecurity risk is relatively low, manufacturers may demonstrate compliance through self-assessment, with no mandatory involvement of a third-party assessment body.

 

Important Products

These products are listed in Annex III of the Act. They perform functions closely related to cybersecurity, network infrastructure, or personal privacy, and therefore carry a higher level of risk. Depending on the level of risk and the scope of impact if compromised, they are further divided into two classes:

1. Important Class I

• Category description: These products carry higher cybersecurity risks and usually perform key functions such as authentication, security protection, and access control. If compromised, they may cause localized but substantive security harm to users.
• Product examples: standalone and embedded web browsers, virtual private networks (VPNs), antivirus software, routers and switches, and smart home products with cybersecurity functions, such as smart door locks and surveillance cameras.
• Compliance requirements: These products are subject to conditional self-assessment. If the manufacturer fully applies and complies with the harmonized standards officially published by the EU, self-assessment may be used for conformity. Otherwise, review by a third-party body is mandatory.

2. Important Class II

• Category description: These products present greater cybersecurity risks and a broader impact than Class I products. If compromised, they may cause extensive and serious negative effects on other systems, services, or large numbers of users. They are typically deployed in enterprise-level or industrial control environments.
• Product examples: firewalls, intrusion detection and prevention systems (IDS/IPS), hypervisors, and programmable logic controllers (PLCs).
• Compliance requirements: These products must undergo EU-type examination or full quality assurance assessment by an authorized third-party notified body.

3. Critical Products

• Category description: Listed in Annex IV of the Act, these products represent the highest CRA risk category. If attacked, they may directly disrupt critical infrastructure such as energy, water, transportation, or finance, potentially leading to catastrophic consequences.
• Product examples: smart meter gateways deployed in infrastructure, hardware security modules (HSMs), smart cards, and underlying secure elements.
• Compliance requirements: These products follow the highest level of mandatory compliance pathway. In addition to third-party review, they may in the future be required to obtain official security certification under a European cybersecurity certification scheme, such as EUCC, at least at the “Substantial” level before entering the EU market.

 

It is therefore clear that the CRA is not aimed at any specific industry. As long as a product has digital functions and can connect directly or indirectly to other devices or networks, it may fall within the scope of the CRA.

In terms of specific compliance requirements, the CRA focuses on fundamentally shifting responsibility for product cybersecurity from general consumers or users to manufacturers and operators within the supply chain. It requires products to implement the principles of “Secure by Default” and “Secure by Design” from the design and development stages, and to ensure continuous security updates throughout the entire product lifecycle. Key areas include:

• Security by Design: Manufacturers must conduct comprehensive cybersecurity risk assessments from the early stages of product planning, design, and development. During design, they must minimize the attack surface as much as possible, such as by limiting unnecessary external connection interfaces, and adopt secure coding practices and protective architectures to reduce the risk of cyberattacks and data leakage from the source.
• Security by Default: Products must be automatically configured at the highest level of security when shipped or delivered to users, without requiring additional manual setup by the user. The CRA requires products to be free from known exploitable vulnerabilities and to implement the principle of least privilege, such as disabling unnecessary network ports and remote access interfaces, while strictly prohibiting the use of weak default passwords. In addition, products must include a tamper-resistant reset function so that users can easily and securely restore the system to its initial secure default state when the device is under threat or its configuration becomes disordered.
• Vulnerability Management: Manufacturers are required to establish a dynamic and continuous vulnerability management mechanism. Companies must create a machine-readable software bill of materials (SBOM) for their products to comprehensively track potential weaknesses in third-party and open-source components. Manufacturers must also carry out regular testing and establish a coordinated vulnerability disclosure (CVD) policy, providing a dedicated reporting channel for external researchers to report issues. When a significant actively exploited vulnerability is identified, companies must strictly comply with the mandatory reporting timeline: an early warning within 24 hours, a detailed notification within 72 hours, and a final remediation report within 14 days.
• Secure Updates: To promptly remediate security vulnerabilities, products must be equipped with a secure and reliable update mechanism. The CRA requires security updates to be distributed separately from general functional upgrades where technically feasible, and to be provided to users free of charge. Products should enable “automatic security updates” by default while retaining the user’s ability to easily disable or postpone them. In addition, update files must be distributed with strict digital signature and encryption protections to prevent attackers from implanting malware through forged upgrade packages, thereby ensuring the integrity of update transmission and installation.
• Product Lifecycle Security: Cybersecurity must be embedded throughout the entire product lifecycle. The CRA requires manufacturers to clearly declare a “security maintenance period” when placing a product on the market, generally no shorter than five years, and to continue providing vulnerability monitoring and security patch support during that period. When the maintenance period is approaching its end, manufacturers must fulfill their exit obligations by notifying users in advance that security support for the product will be discontinued, and by providing guidance on secure data deletion and migration. In addition, relevant security compliance and technical documentation must be properly retained for at least ten years after the product is placed on the market, so that competent authorities may inspect it at any time.
•  

Figure 2. CRA Timeline

 

III. IEC 62443: The Most Practical CRA Pathway for Machine Tool Manufacturers

For many machine tool manufacturers, the greatest challenge posed by the CRA is not understanding that “the EU requires products to have cybersecurity capabilities,” but rather translating regulatory language into development processes and technical specifications that engineering teams can actually implement.

Annex I of the CRA requires products to provide capabilities such as secure design, security by default, vulnerability handling, secure updates, data protection, access control, and incident monitoring. However, regulations usually describe only the “outcomes to be achieved” and do not specify in detail how companies should achieve them. This is precisely where IEC 62443 offers important value to the machine tool industry.

In short, the CRA is a regulatory requirement that defines “what products must achieve.” IEC 62443 is an engineering methodology that helps manufacturers answer “how to achieve it.” For example, the CRA Annex I requirements on Secure by Design, vulnerability management, access control, encrypted communications, and incident monitoring can all be practically mapped to IEC 62443-4-1 and IEC 62443-4-2.

IEC 62443 is currently one of the most important cybersecurity standards in the field of industrial automation and control systems. Compared with general IT cybersecurity standards, IEC 62443 is better aligned with the characteristics of the machine tool industry for the following reasons:

• Machine tools require a balance between availability and security. Factory operations cannot be disrupted by overly strict cybersecurity controls, nor should cybersecurity updates lead to unexpected machine downtime. IEC 62443 emphasizes security design based on risk levels, helping avoid both “overprotection” and “insufficient protection.”
• Machine tools have long lifecycles. While typical IT products may be replaced every three to five years, machine tools are often used for more than ten years. IEC 62443’s emphasis on product lifecycle, maintenance processes, and vulnerability management is highly consistent with the CRA’s requirements for support periods and security updates.
• Machine tools are typical system-integration products. A smart machine tool may include third-party controllers, operating systems, open-source software, sensors, and cloud platforms. IEC 62443’s concepts of Zones and Conduits, security levels, component security requirements, and secure development processes can help manufacturers manage complex architectures in a systematic way.

 

(1) IEC 62443-3-2: Conducting Risk Analysis Starting from Product Architecture

The core concepts of IEC 62443-3-2 are risk assessment and system segmentation, with common methods including Zones and Conduits. A “Zone” refers to a group of assets with the same security requirements, while a “Conduit” refers to the communication channel between different Zones.

Taking a smart machine tool as an example, the system can initially be divided into the following areas:

• Machine control zone: CNC, PLC, Motion Controller
• On-site operation zone: HMI, Operator Panel
• Edge computing zone: IPC, AI Box, Gateway
• Factory network zone: MES, SCADA, data acquisition systems
• Cloud service zone: remote monitoring, predictive maintenance, and data analytics platforms
• Remote maintenance zone: VPN, maintenance accounts, and OEM service portals

 

Through this segmentation approach, companies can further analyze:

• Which communication paths are most vulnerable to attack?
• Which components, if compromised, could cause downtime or safety risks?
• Which remote services require stronger identity authentication?
• Which data needs to be encrypted or subject to restricted access?
• Which zones require logging and monitoring?

 

This analytical method can directly support the Cybersecurity Risk Assessment required by the CRA and can also serve as important content for subsequent technical documentation.

The value of IEC 62443-3-2 lies in the fact that cybersecurity is no longer only the responsibility of software engineers; instead, it becomes a product design issue that can be discussed jointly by mechanical, electrical control, networking, cloud, and after-sales service teams.

 

(2) IEC 62443-4-1: Establishing a Secure Product Development Lifecycle

IEC 62443-4-1 focuses on the secure product development lifecycle. Its purpose is not merely to conduct a cybersecurity test after a product is completed, but to gradually incorporate security requirements throughout the product development process.

When applied to machine tool product development, this may include the following activities:

1. Define product cybersecurity requirements: At the early stage of developing a new model or new control system, define requirements for identity authentication, privilege management, communication encryption, secure updates, logging, and remote maintenance.
2. Threat modeling: Analyze possible attack scenarios for components such as CNCs, PLCs, IPCs, gateways, cloud APIs, and mobile apps. Examples include stolen remote maintenance accounts, tampered update files, malware implanted in gateways, and untrusted sources for AI model updates.
3. Secure design: Based on the results of threat analysis, design security control measures such as role-based privilege management, strong password policies, certificate-based device identity, TLS encryption, secure boot, and signed updates.
4. Secure implementation: Incorporate secure coding, third-party package management, open-source component inventory, and version control into software and firmware development.
5. Security verification: Conduct vulnerability scanning, communication testing, and penetration testing to confirm that the product does not contain known exploitable vulnerabilities before delivery.
6. Vulnerability handling and maintenance: After the product is placed on the market, establish processes for receiving, analyzing, remediating, disclosing vulnerabilities, and notifying customers.

The CRA requires that products contain no known exploitable vulnerabilities at the time of delivery, and that manufacturers handle vulnerabilities, provide security updates, and maintain technical documentation throughout the product lifecycle. The processes established under IEC 62443-4-1 can therefore serve as important evidence for CRA conformity assessment and customer audits.

 

(3) IEC 62443-4-2: Translating CRA Requirements into Product Security Functions

If IEC 62443-4-1 concerns the development process, then IEC 62443-4-2 concerns the security capabilities that the product itself should possess.

IEC 62443-4-2 sets out a series of technical security requirements for industrial control system components. Among the most frequently discussed are the seven Foundational Requirements (FRs):

• FR1: Identification and authentication control
• FR2: Use control
• FR3: System integrity
• FR4: Data confidentiality
• FR5: Restricted data flow
• FR6: Timely response to events
• FR7: Resource availability

These requirements closely correspond to many of the product cybersecurity requirements in CRA Annex I.

For example:

• The CRA requires products to prevent unauthorized access. Machine tools can establish user authentication, role-based privilege management, and maintenance access control through IEC 62443-4-2 FR1 and FR2.
• The CRA requires protection of data confidentiality and integrity. Machine tools can implement secure boot, firmware integrity checks, TLS-encrypted communications, and key protection through FR3 and FR4.
• The CRA requires products to reduce the impact of cybersecurity incidents. Machine tools can establish security logs, event alerts, and abnormal behavior records through FR6.
• The CRA requires products to provide availability and resilience. Machine tools can use FR7 to assess the risk of downtime caused by resource exhaustion, network interruption, abnormal updates, or cyberattacks.

 

The following table may serve as an initial reference for machine tool manufacturers when mapping CRA requirements to IEC 62443:

CRA Requirements	IEC 62443 Mapping	Machine Tool Practice Examples
Cybersecurity Risk Assessment	IEC 62443-3-2	Analyze risks across CNCs, gateways, and cloud services using Zones and Conduits
Secure by Design	IEC 62443-4-1	Integrate cybersecurity requirements and threat modeling into the development process for new machine models
No Known Exploitable Vulnerabilities	IEC 62443-4-1	Conduct vulnerability scanning, third-party package inspection, and remediation verification before market release
Identity Authentication	IEC 62443-4-2 FR1	Differentiate account levels for maintenance engineers, operators, and administrators
Access Control	IEC 62443-4-2 FR2	Restrict permissions for parameter changes, remote maintenance, and program upload/download
System Integrity	IEC 62443-4-2 FR3	Secure Boot, firmware signatures, and update file verification
Data Confidentiality	IEC 62443-4-2 FR4	TLS, VPN, and encrypted storage of sensitive parameters
Restricted Data Flow	IEC 62443-4-2 FR5	OT/IT network segmentation and gateway communication allowlists
Event Logging and Response	IEC 62443-4-2 FR6	Login records, remote operation logs, and abnormal event alerts
Availability	IEC 62443-4-2 FR7	Prevent machine downtime caused by resource exhaustion or abnormal traffic
Vulnerability Management	IEC 62443-4-1	PSIRT, vulnerability reporting channels, and remediation processes
Secure Updates	IEC 62443-4-1 / 4-2	OTA signatures and version management