Regulation (EU) 2024/2847 – Cyber Resilience Act (CRA)

Regulation (EU) 2024/2847 – the Cyber Resilience Act (CRA) – is a new EU regulation introducing horizontal cybersecurity requirements for “products with digital elements”. It was adopted in October 2024 and, after transitional periods, will apply directly in all EU countries from the end of 2027. If you are a manager in an industrial environment—whether responsible for maintenance, procurement, or compliance—it is worth understanding now which products fall under this regulation, what new obligations it places on manufacturers, importers, and distributors, and how to prepare your organisation for the upcoming changes. Below, we set out the key information in practical terms, without legal jargon but with technical accuracy—so you can more easily take the right preparatory steps.

Scope: which products are covered by the Cyber Resilience Act?

Regulation (EU) 2024/2847 applies to all “products with digital elements” made available on the EU market whose intended use involves connecting to another device or a network (directly or indirectly, physically or logically). In other words, most devices or software that can communicate with other systems will be subject to the new requirements. In practice, this includes, among others, IoT devices and consumer electronics (e.g., smartwatches, mobile phones, smart home appliances/consumer electronics, baby monitors), wearables (e.g., fitness bands), industrial equipment with networking capabilities (sensors and industrial machines connected to a network), as well as a wide range of software (operating systems, mobile and desktop applications, business software, etc.). Importantly, standalone software sold separately (as a product) is also covered by the CRA, as are remote data processing services that form an integral part of a product—for example, a cloud service that controls a smart home device will be treated as part of the product and must meet the security requirements.

The Regulation has a very broad scope, but it also provides exemptions for certain categories of products that are already governed by their own sector-specific rules. The CRA does not cover, among others: medical devices (covered by the MDR Regulations 2017/745 and 2017/746), vehicles and their equipment (covered, among others, by Regulation 2019/2144 on vehicle type-approval), aircraft (Regulation 2018/1139 on aviation), or marine equipment (Directive 2014/90/EU). These products are subject to separate regulations, often already including requirements tailored to the specific industry, and therefore have been excluded from the scope of the CRA. In addition, the new rules do not apply to hardware and software that is exclusively military or intended for national security (as well as the processing of classified information). Also excluded are spare parts supplied as replacements for identical components—if the original product was lawfully placed on the market, the identical part does not have to meet the CRA separately.

It is worth noting that so-called free and open-source software (open source) will not be covered by the CRA, provided it is not made available as part of a commercial activity. So if a given piece of software is developed and published free of charge, outside market circulation, its creators (e.g., the open-source community) are not treated as “manufacturers” within the meaning of the regulation, and the obligations described below do not apply to them. However, if a company were to use an open-source component in its commercial product, then responsibility for meeting the security requirements falls on the manufacturer of the final product. In summary, the CRA is primarily aimed at professionally developed and sold digital products that reach end users on the EU internal market.

Why was the CRA introduced? Emerging threats, a regulatory gap, and the supply chain

The European Union has recognised an urgent need to strengthen the cyber resilience of digital products in the face of growing threats. In recent years, the number and variety of internet-connected devices has surged—ranging from industrial IoT systems in factories to smart home appliances. Unfortunately, the level of cybersecurity in these products is often low, as evidenced by widespread vulnerabilities and inadequate, inconsistent delivery of security updates. Many manufacturers have not, to date, made security a priority throughout the product lifecycle, and users often lack the awareness or information needed to know which devices are secure, how long they will receive update support, and how to use them safely. This combination of factors leads to an increased risk of cyberattacks.

The Cyber Resilience Act is intended to close a regulatory gap – until now, there have been no uniform, mandatory requirements for the digital security of products at EU level. While initiatives such as ICT security certifications (under the Cybersecurity Act 2019/881) or the requirements of the NIS2 Directive for critical sectors did exist, no legislation directly imposed a “cybersecurity by design” obligation for all devices and software placed on the market. The CRA establishes precisely such a universal framework – requiring that hardware and software be designed, manufactured, and maintained with robust protective measures throughout their entire life cycle. The aim is for products to reach the market with fewer vulnerabilities, and for manufacturers to ensure rapid remediation of new threats (e.g., through security patches), rather than leaving users with insecure, vulnerable devices.

Cyber resilience also has a supply-chain and cross-border dimension. In an era where everything is connected to everything else, an incident in one seemingly insignificant device can become an attack vector against an entire organisation or its business partners. A single infected IoT sensor on a production floor can open a back door into the plant network; a vulnerability in a widely used application can be exploited globally within minutes. As highlighted in the regulation’s justification, a cyber incident in one product can spread through the supply chain beyond a single country’s borders within a few minutes. The costs of such attacks are borne not only by manufacturers and users, but by society as a whole—disruptions to critical infrastructure, financial losses, and breaches of public safety. Common, mandatory rules across the EU are intended to raise the overall level of protection and prevent a situation where the weakest link (a non-resilient product) puts everyone at risk.

An additional driver is building trust in digital products and leveling the competitive playing field. Today, manufacturers that invest in security by design often lose on price to those that ignore these issues. The CRA is intended to make cybersecurity a quality baseline—everyone will have to meet minimum requirements, which will level the playing field and reduce the social costs of attacks (which are currently shifted onto victims). As a result, it is expected to increase the resilience of the entire EU market and strengthen customer trust in modern devices with digital elements. The Act also fits into the EU’s broader strategy (alongside GDPR, NIS2, DORA, etc.) aimed at strengthening the cybersecurity of services and products as a foundation of the digital economy.

Regulation (EU) 2024/2847: Key obligations for manufacturers, importers and distributors

The new regulation introduces a number of specific obligations for economic operators involved in the supply chain for products with digital elements. The scope of responsibility depends on the role—manufacturers face the most extensive requirements, but importers and distributors also have important duties. Below, we summarise the key obligations from the perspective of a manager responsible for ensuring the company’s products comply with the regulations.

Manufacturers’ obligations

The manufacturer (as well as any entity that places a product on the market under its own brand or modifies it—such an entity is also treated as the manufacturer) bears primary responsibility for meeting the CRA requirements. Its key tasks include:

• Ensuring the product complies with the essential requirements for cybersecurity set out in Annex I to the Regulation. In practice, this means that already at the design and engineering stage, the product must incorporate features that guarantee an appropriate level of digital security, commensurate with the risk associated with the given product. The Regulation lists a number of specific technical requirements—including, among others, no known vulnerabilities at the time of placing on the market, the use of secure default configurations (e.g., avoiding default passwords), encryption where appropriate, safeguards against unauthorised access, protection of the user’s personal data, resilience to attacks that disrupt functions (e.g., DoS attacks), and the ability to perform a factory reset. The product should be designed to minimise its “attack surface” as much as possible—for example, by not having unnecessary open ports or services that increase exposure to cyber threats. These essential requirements (Part I of Annex I CRA) serve as a checklist of security features that every digital product must meet.
• Establishing a vulnerability and incident handling process – the manufacturer must actively maintain the product’s security after it has been sold, throughout the declared support period. Part II of Annex I sets out requirements for the vulnerability handling process: regular testing and monitoring for new vulnerabilities, accepting vulnerability reports (e.g., from researchers or users), and rapid remediation/patching of identified vulnerabilities by providing security updates. The manufacturer must maintain a coordinated vulnerability disclosure policy (coordinated disclosure) – i.e., designate a contact point where issues can be reported and have procedures for how to respond to such reports. It is important that updates address vulnerabilities without delay and are distributed securely (e.g., digitally signed). Crucially, the manufacturer is required to provide support and security updates for a period corresponding to the product’s expected lifecycle, at least 5 years (unless the nature of the product justifies a shorter period). In other words, if our equipment is typically expected to serve customers for ~5+ years, we cannot stop issuing patches after a year or two – several years of post-sale support will be required so the user is not left with a vulnerable device.
• Conducting a cybersecurity risk assessment – before placing a product with digital elements on the market, the manufacturer must carry out a systematic analysis of risks related to cyber threats to that product. The risk assessment should be part of the design process (security by design) and take into account, among other things, the intended use of the product, potential foreseeable misuse, and the conditions of use (IT environment, network, type of data processed by the device). Based on this analysis, appropriate protective measures must be planned and incorporated into the design. Documentation from the cybersecurity risk assessment becomes part of the product’s technical documentation and must be updated if new threats emerge. The manufacturer is required to retain the documentation for at least 10 years from the date the product is placed on the market (and if the declared support period is longer than 10 years, then for the corresponding longer period). The risk assessment is not a one-off exercise—it should be reviewed and updated as needed, especially when new vulnerabilities are identified or the context of the product’s use changes.
• Oversight of external components – the manufacturer must exercise due diligence when using third-party components, including open source libraries. It is necessary to ensure that external components (software and hardware) do not compromise the cybersecurity of the product as a whole. In practice, this means having to control the versions and updates of the libraries used, monitor known vulnerabilities (e.g., those published in CVE) in those components, and update/replace them when vulnerabilities emerge. If open source software is used in the product and a vulnerability is discovered in it, the manufacturer is obliged to inform the entity responsible for maintaining that open source (e.g., the open source project) about the issue, and if they remediate the vulnerability on their own – provide the community with information about the implemented fix. The purpose is to involve manufacturers in the ecosystem of coordinated vulnerability patching, including in open source components.
• Formal conformity assessment and documentation – before a product is placed on the market, the manufacturer must carry out a conformity assessment procedure against the CRA requirements and prepare documentation confirming that the requirements have been met. For most “ordinary” products (not classified as higher-risk), a self-check (internal assessment) will be sufficient, along with technical documentation including, among other things, a product description, the results of a risk analysis, a list of the safety measures applied, testing and update procedures, etc. The manufacturer then issues an EU declaration of conformity, stating that the product meets all applicable CRA requirements, and affixes the CE marking to the product. Note: if a given product is classified as “important” or “critical” from a cybersecurity perspective (Annex III and IV CRA), it may be subject to more stringent conformity assessment procedures. For important products (important) Class II and for critical products, third-party certification will be required, i.e., testing and a certificate issued by a notified body (e.g., an accredited laboratory). For important Class I products, self-certification is permitted only if appropriate harmonised standards exist and the manufacturer uses them—otherwise, third-party involvement is also required. The manager should therefore determine which category the company’s product falls into and whether external certification will need to be planned (which may affect the timeline for bringing the product to market).
• Post-market security monitoring and reporting – a new requirement introduced by the CRA is the obligation to report serious security issues to the competent authorities. The manufacturer must notify the designated national CSIRT (incident response team) acting as coordinator, as well as ENISA, of every actively exploited vulnerability in its product and every serious incident affecting the product’s security. The reporting deadline is very short – 24 hours from detection of the vulnerability/event (similar to the strict requirements under the GDPR or NIS2). Reports will be submitted via a single EU-wide platform operated by ENISA. The reporting obligation will take effect earlier than the rest of the requirements (September 2026 – see the deadlines below) and will apply to all products on the market from that point onward. Therefore, the manufacturer must have internal procedures capable of detecting an incident/vulnerability and providing the information required by the regulation within 24 hours. The aim is to give supervisory authorities visibility into emerging threats and to coordinate the response (e.g., warning other users when a given product has a critical vulnerability).

These obligations often require significant organizational changes—from implementing Secure SDLC in the R&D department, through new product maintenance and support policies, to additional documentation and staff training. In return, the company gains greater confidence that its product will not become the source of a serious cyber incident, as well as compliance with upcoming legislation, which will allow it to continue selling on the EU market.

Regulation (EU) 2024/2847: Obligations of importers and distributors

Entities that bring products with digital elements into the EU from outside the EU (importers) or resell them on the EU market (distributors) must also ensure that these products comply with the CRA. Their role is mainly to verify compliance and respond to any potential non-compliance.

Importer before placing a product on the EU market must verify that the manufacturer has fulfilled its obligations—in other words, that the product bears the required CE marking and has an EU declaration of conformity, that instructions and safety information are included, and that the manufacturer has prepared the required technical documentation. The importer does not have to test the product’s cybersecurity themselves, but if they have justified doubts about the product’s compliance with the requirements (e.g., no CE marking, no information on the support period, etc.), they should not make such a product available on the market until they are satisfied that the non-compliance has been remedied. If it is found that the product does not meet CRA requirements, the importer is required to inform the market surveillance authorities and take corrective action—ensure the product is brought into compliance, and if that is not possible, withdraw it from circulation or from the market. Importers, like manufacturers, must keep a copy of the declaration of conformity and ensure that the technical documentation is available to the authorities upon request. They should also place their contact details on the product (or its packaging) and ensure that the product is properly marked. In practice, the importer’s role comes down to a safety gate—preventing the distribution in the EU of products that lack the “paperwork” demonstrating compliance with the CRA.

Distributors (domestic wholesalers, retailers, etc.) are in a similar position to importers, with the difference that they verify compliance with requirements both by the manufacturer and, where applicable, the importer if the product comes from outside the EU. Before reselling, the distributor should therefore check that the goods bear the CE marking, that the declaration or instructions required by law are included, and that no public notices have been issued stating that the given model does not meet safety requirements. If there are any doubts, they are also obliged to suspend sales until the matter is clarified. If they conclude (or are informed) that the product poses a serious risk or does not meet CRA requirements, they should notify the manufacturer or importer as well as the supervisory authorities, and cooperate in corrective actions (e.g., market withdrawal campaigns).

From a procurement manager’s perspective, these regulations mean the need for greater vigilance when selecting equipment/software suppliers. You must ensure that non-EU contractors deliver products that are already CRA-compliant, because otherwise our company (as the importer) will be liable for any shortcomings. For a distributor (e.g., a company trading in automation), there is also an obligation to monitor whether the various brands’ products in its portfolio have up-to-date declarations of conformity and meet the requirements—in practice, this will require close cooperation with manufacturers and a rapid response to any security alerts relating to the devices being sold.

Worth noting: if an importer or distributor places a product on the market under its own logo/brand or modifies the product (e.g., changes its functionality, software, or configuration in a way that is significant for cybersecurity), then under the regulation it becomes the manufacturer of that product. In that case, it must assume all manufacturer obligations (carry out the conformity assessment, issue its own declaration, etc.). This situation applies, for example, to system integrators that sell OEM devices under their own brand—they need to be very careful, because formally they are responsible for compliance to the same extent as the original manufacturer.

Effective dates and transitional periods

Regulation (EU) 2024/2847 was published in the Official Journal on 20 November 2024. It entered into force on 10 December 2024 (20 days after publication); however, the main obligations will not apply until 36 months from that date. The legislator provided for a long transitional period to give the industry time to adapt. Here are the key dates:

• 11 September 2026 – from this date, the obligations to report vulnerabilities and incidents will apply. The manufacturer of any product with digital elements placed on the EU market will be required to notify the competent authorities of any actively exploited vulnerabilities and any serious security incidents affecting its product. This date falls 21 months after the CRA enters into force and means that, as early as 2026, companies must have procedures in place for security monitoring and for reporting issues. This is not dependent on when the product was placed on the market – it also applies to products sold before 2026 that are still in use. In other words, even if a device was placed on the market, for example, in 2025 (before the regulation applies), and a critical vulnerability is disclosed in it in September 2026, the manufacturer is obliged to report it and remedy it.
• 11 June 2026 – from this date, the provisions on notified bodies and conformity assessment bodies are to apply. By mid-2026, Member States will prepare a system for designating and notifying bodies that will be authorised to certify products (important and critical) for compliance with CRA requirements. For manufacturers, it is important that, in the second half of 2026, the infrastructure for carrying out the required testing and certification is already available.
• 11 December 2027 – full application of the CRA Regulation. From that date, no product with digital elements that does not meet the CRA requirements may be legally placed on the market in the EU. This deadline (3 years from entry into force) is the cut-off date for bringing products and processes into compliance. After 11.12.2027, all new devices and software sold in the EU must be designed, manufactured, and maintained in accordance with the CRA—otherwise, the company exposes itself to serious penalties. It is worth noting that the rules provide some relief for products already on the market: if a given product (a specific unit) was already made available on the market before 11 December 2027, it may continue to be traded without meeting the CRA. However, this applies only to individual units—the type of product designed before the CRA does not automatically receive an exemption. Each new batch, each new unit placed on sale after that date must comply with the CRA, unless it was already physically in circulation earlier (which in practice means, for example, stock held by a distributor who purchased the goods before the deadline). The rules therefore cannot be bypassed by producing “in advance” and selling after 2027—each product is subject to the requirements in force at the moment it is placed on the market. An additional exception concerns still-valid EU type-examination certificates issued before that date under other regulations—they will remain valid until June 2028, unless a shorter period was specified.

For companies, the practical takeaway is that the real deadline is the end of 2027. From 2028, we will not be able to sell in the EU devices that do not meet the CRA requirements. However, you need to be ready for the new incident-reporting obligations as early as 2026. The time remaining should be used to analyze products and bring them into compliance. Although 3 years may seem like a lot, the changes could prove far-reaching—so it is better to start work in advance. Below we present a checklist of actions a manager should consider when preparing their organization to meet the requirements of the Cyber Resilience Act.

Regulation (EU) 2024/2847: How to prepare for 2026/2027 – a manager’s checklist

• Identify products covered by the CRA – Prepare a list of the company’s items that qualify as “products with digital elements” (hardware or software that connects to a network/other devices). For each one, determine whether it could be considered important or critical under the regulation (Annex III/IV) – e.g., whether it performs key safety functions, or whether its compromise could cause widespread harm. This classification determines, among other things, the required conformity assessment procedure (including whether third-party involvement will be needed).
• Familiarise yourself with the requirements and standards – Review the essential cybersecurity requirements in Annex I of the CRA and map them to your products. Check whether relevant harmonised standards or industry standards already exist that can help you meet the requirements (e.g., standards from the IEC 62443 family for securing industrial automation systems may be useful when designing machine security measures). Stay up to date with standardisation work—guidance may emerge that makes it easier to implement CRA requirements in your field.
• Carry out a gap analysis – Compare the current state of your products and processes with the new requirements. Assess how well your existing security level meets the requirements (e.g., whether devices have authentication mechanisms, encryption, secure updates, etc.). Review your company’s software development process—are secure coding practices being applied, are penetration tests being performed, and how quickly do you respond to reported vulnerabilities. Identify gaps and areas for improvement in both organization (procedures) and technology (security features).
• Adjust product design and development – If the gap analysis reveals shortcomings, plan the implementation of the missing mechanisms and practices. This may include changes to the product architecture (e.g., adding an encryption module, securing communication interfaces), enhancing the SDLC (Software Development Life Cycle) process with threat modeling, security-focused code review, fuzz testing, etc., as well as establishing new product security policies. Make sure the R&D team treats cybersecurity as a design requirement on par with functionality – the regulation mandates a “security by design/default” approach.
• Plan an update and support program – Assess whether your company is prepared to support products for an appropriate length of time. You may need to set up a schedule and allocate resources to deliver regular firmware software updates for several years after sale. Verify whether the products have the technical capability to be updated (remotely or locally) – if not, that is a serious issue, because the CRA requires the ability to remediate vulnerabilities after sale. Define a realistic support period (minimum 5 years) and communicate it to users. Also prepare a plan for handling technical support and security reports from customers.
• Prepare the required documentation – Make sure that, for each product, a complete technical documentation set is created from a cybersecurity perspective. It should include, among other things, a risk assessment report, a description of the security architecture, a list of the measures applied (e.g., encryption, authorization), security test results, update procedures, a vulnerability disclosure policy, etc. This documentation will be the basis for demonstrating compliance in the event of an inspection (and, if applicable, for submission to a certification body). Also put in place a process to archive it for the required period (10 years or more). In addition, prepare templates for EU declarations of conformity for your products—remembering that they must include new wording confirming that all requirements of the regulation have been met.
• Take care of your supply chain – Contact your component suppliers (especially for software, IoT modules, etc.) to discuss CRA compliance. Update supplier contracts by adding clauses on the required level of cybersecurity for components and the obligation to report identified vulnerabilities. Make sure you have access to information on the origin and versions of components (maintain an SBOM – Software Bill of Materials for products, which will make it easier to track vulnerabilities in dependent libraries). If you use external cloud services connected to the product, verify their security measures and compliance with NIS2 (because SaaS may fall under NIS2 rather than CRA). Product cybersecurity also means the security of every building block it is made of—suppliers need to be aligned and working toward the same goal.
• Train staff and raise customer awareness – The new obligations mean that different departments across the company need a basic understanding of the CRA. Provide training for the design, quality, IT, and service teams on the regulation’s requirements and internal procedures (e.g., how to respond to a vulnerability report, how to document changes for compliance purposes). It is also worth informing the procurement and sales teams so they are aware of the new markings and declarations (e.g., the need to verify whether a supplier from outside the EU has provided a declaration of conformity). Consider preparing customer-facing information on your products’ security policy—transparency in this area can become a commercial advantage (users will start paying attention to whether a given product meets cyber requirements and has guaranteed updates).
• Monitor guidelines and deadlines – Follow announcements from the European Commission and national authorities regarding the CRA. Delegated or implementing acts may appear that clarify certain issues (e.g., sectoral exclusions – the Commission may decide to exclude from the CRA products that are covered by equivalent sector-specific requirements). Also track the process for publishing harmonised standards – applying a standard will be the simplest route to a presumption of conformity. Make sure you meet the deadlines mentioned: September 2026 (readiness to report incidents) and December 2027 (full compliance for all new products). Ideally, set internal milestones much earlier – for example, completing the initial risk analysis by mid-2025, aligning the development process by the end of 2025, compliance testing and pre-certifications in 2026, etc. – so that you enter 2027 with the requirements almost fully met. Leaving it to the last minute can result in sales being halted, so a proactive approach is essential.

Doing this “homework” in advance will help you avoid a frantic rush in 2027 and the risks that come with it. Rather than treating the CRA solely as an obligation, it is worth seeing it as an opportunity to raise the overall level of product security—protecting both the company and its customers from costly incidents.

CRA vs. the Machinery Regulation (EU) 2023/1230 – what falls under which?

Many industrial-sector managers are wondering how the new cyber resilience rules relate to the already familiar Machinery Regulation (EU) 2023/1230 (which will replace the Machinery Directive). Is there an overlap in requirements, or do these regulations complement each other? The key is to understand which aspects of the product are governed by each legal act.

Regulation (EU) 2023/1230 on machinery covers machine safety in the traditional sense—it focuses on protecting the health and safety of machine users. It sets out the so-called Essential Health and Safety Requirements (EHSR), which address, among other things, mechanical and electrical aspects, ergonomics, noise, EMC, etc. The new machinery regulation has also introduced a requirement to take into account hazards related to internet access and cyberattacks as a potential threat to safety. This means that, during the risk assessment, the machine manufacturer must consider scenarios in which, for example, remote interference with the machine’s control system could cause an accident. The manufacturer must therefore design measures to prevent such situations (e.g., network safeguards that prevent an unauthorised person from taking control of the machine). However, the machinery regulation addresses cybersecurity only to the extent that it affects the physical safety of people operating machines. It is one of many components of the machine’s conformity assessment, but it does not go into detailed IT-type requirements—you will not find a list of cryptographic mechanisms there, nor an obligation to update the machine’s software after it has been sold. Put simply, the Machinery Regulation ensures that a machine does not pose a risk to life/health (including as a result of a cyber incident), whereas the CRA ensures the product’s overall cybersecurity (including data confidentiality, service resilience, and the entire lifecycle).

The Cyber Resilience Act covers a much broader range of IT topics than the Machinery Regulation. Even for industrial machinery, the CRA imposes, for example, requirements for vulnerability reporting, providing updates for X years, and protection against data loss—issues not directly tied to the machine user’s safety, but to cybersecurity as such. In practice, this means that a machine that is a product with digital elements will be subject simultaneously to the provisions of both regulations. The manufacturer of such a machine must meet the requirements of both legal acts—both those related to a design that is safe in terms of, for example, mechanics (Machinery Regulation) and those related to securing software, networks, and data (CRA). Meeting the requirements of one regulation does not automatically mean compliance with the other, because the assessment criteria are different.

From a conformity assessment perspective, a product that falls under more than one EU regulation must comply with all applicable requirements before it can bear the CE marking. For example, a manufacturer placing on the market a collaborative industrial robot with a remote monitoring function will need to ensure that the robot meets the essential machinery safety requirements (Regulation 2023/1230) as well as the essential cybersecurity requirements (Regulation (EU) 2024/2847). The EU Declaration of Conformity for such a machine should list both legal acts. Likewise, a maintenance manager purchasing such equipment must verify compliance with both the “machinery CE” and the “cyber CE”. In practice, there is only one CE marking—but the documentation must demonstrate conformity with all applicable New Approach legislation that applies to the product.

It is worth highlighting a few examples of what falls under which regulation:

• Purely electronic IT devices (with no machine functions) – e.g., routers, smartphones, IP cameras – are not covered by the Machinery Regulation (because they are not machines), but they are covered by the CRA if they include digital elements and communicate over a network. In their case, the main focus is cybersecurity, and issues of the user’s physical safety are not relevant (aside from general OSH/EMC requirements).
• Traditional machines with no digital connectivity – e.g., a hydraulic press with purely analog controls – fall under the Machinery Regulation (you must meet requirements for design, guarding, safety circuits, etc.), but they do not fall directly under the CRA because they do not include digital components that communicate externally. Of course, if the machine contains control electronics, that electronics may in itself be considered digital equipment—but as long as there is no connectivity (e.g., no network ports, no remote access), it does not meet the definition of a “product with digital elements” within the meaning of the CRA.
• Modern machines with digital features – e.g., robots, IoT-enabled production lines, AGVs communicating with a management system – fall under both acts. Here, the Machinery Regulation will require, among other things, a traditional risk assessment (so that the machine does not create mechanical/electrical hazards) and a requirement that, for example, remote access to a robot cannot lead to a dangerous situation (i.e., taking cyber threats to safety into account). CRA, in turn, will additionally impose an obligation for that robot to have generally secured software (e.g., encrypted data transmissions, unique passwords), to be kept updated by the manufacturer, and, if a vulnerability is discovered, to be patched and reported to the authorities. The manufacturer of such equipment must therefore ensure resilience to cyberattacks both in the context of human safety and business continuity, data confidentiality, etc.

In summary, the Machinery Regulation and the CRA do not compete with each other; they complement one another. The former focuses on the functional safety of machinery (including minimum cyber requirements so that the machine is safe), while the latter addresses broader product cybersecurity across the entire lifecycle. For managers, this means the need for multi-dimensional compliance: an intelligent product must be both safe by design and cybersecure. This is why you need to track the requirements of both regulations. Fortunately, their application timelines are similar—the Machinery Regulation will also start being applied in practice from January 2027 (replacing the directive), and the CRA from the end of 2027. You can therefore combine preparations for both into a single, coherent compliance program. For example, when designing a new machine, build in both machinery safety requirements and IT security measures from the outset; during prototype testing, verify not only compliance with standards such as ISO 13849 (safety), but also, for instance, penetration testing of the control system. With this approach, the company can ensure comprehensive compliance and avoid a situation where it meets one law at the expense of ignoring the other.

Regulation (EU) 2024/2847 is undoubtedly a challenge for manufacturers and suppliers, but it is also a necessary response to today’s realities. Machines and equipment are becoming increasingly intelligent and connected—regulations must keep pace. Managers who take preparatory steps now will gain an advantage: their companies will not only move into the new legal framework smoothly, but will also increase the competitiveness and credibility of their products in the eyes of customers, for whom digital security is becoming just as important as price or functionality. With the right support from machine safety and IT security experts, implementing the CRA requirements can be treated as part of continuous improvement, rather than merely a regulatory obligation. As a result, the business, end users, and the entire digital ecosystem all benefit. Safer products mean a lower risk of downtime, attacks, and losses—and that is the goal shared by both lawmakers and responsible market participants.