Cyber Resilience Act in mechanical engineering: why your customer portal is now mandatory infrastructure

In mechanical engineering, the Cyber Resilience Act is not a topic for your development department. It is a sales topic, and has been since 11 September 2026. On that day, the regulation’s reporting obligation took effect. Anyone who learns of an actively exploited vulnerability in their product reports it to the authorities and informs the affected users. The question behind it sounds trivial: through which channel do you reach every customer who operates one of your connected machines?

If the honest answer is “an Excel list in the service department, a CRM with gaps and wishful thinking”, you have a problem, and the Data Act adds a second obligation on top. Customers have a right to the data from their machines, and for products placed on the market after 12 September 2026, this access must be built in from the factory. Two regulations, one common denominator: you need a digital place where customer and machine are unambiguously linked. That place is the customer portal.

Cyber Resilience Act and Data Act deadlines for machine builders

As of October 2026; all dates are taken from the texts of the regulations. The CRA entered into force on 10 December 2024, as confirmed by the European Commission’s overview page, and its obligations apply in stages under Article 71 CRA. The Data Act (Regulation (EU) 2023/2854) has applied since 12 September 2025; its phasing is set out in Article 50 Data Act.

This text is not a substitute for legal advice; whether and how your specific product is covered is something to clarify with a law firm or your industry association.

The CRA defines its “product with digital elements” as a software or hardware product together with its remote data processing solutions (Article 3 CRA). This covers anything you have developed yourself or under your responsibility and without which the machine could not perform one of its functions. A machine tool with a controller, its own remote maintenance module and its own cloud dashboard is therefore not one product but a bundle, and the bundle falls within the scope.

CRA reporting obligation: 24 hours, 72 hours and your customers

Article 14 is the part of the CRA that already applies to you as a manufacturer today, and towards the authorities it has three stages. As soon as you become aware of an actively exploited vulnerability, an early warning goes to the competent CSIRT and to ENISA within 24 hours, via the single reporting platform.

The actual notification follows within 72 hours, with the nature of the exploitation and initial mitigating measures, and the final report no later than 14 days after a fix has been made available (Article 14 CRA). The same rhythm applies to severe security incidents, with the final report then due within one month.

That is the authorities’ side. The customer side is in paragraph 8 of the same article, and for you it is the one that really costs money. As soon as you are aware, you inform the affected users about the vulnerability and about the measures they can take themselves, where necessary in a structured, machine-readable format. Here, the law sets no deadline in hours. But if you don’t inform them in time, the CSIRT can inform your customers itself if it considers this necessary.

Your key account then learns about the vulnerability in its plant from an authority. By the next supplier evaluation at the latest, its purchasing department is likely to ask about it.

The reporting obligation does not only apply to machines delivered from December 2027 onwards. Article 69(3) CRA explicitly extends Article 14 to all covered products placed on the market before 11 December 2027. So your installed base is included, right down to the 2019 plant with the remote maintenance router whose current operator nobody knows any more.

For machines placed on the market from 11 December 2027, Article 13 also applies. It requires a support period of at least five years, security updates that remain available for at least ten years after release, and a single point of contact through which users can report vulnerabilities to you (Article 13 CRA). Existing machines are only affected in the event of a substantial modification. In practice, both come down to a lasting, addressable relationship with every operator. An email address in the ERP is not a relationship.

Data Act in mechanical engineering: data access becomes a design obligation

The Data Act turns the perspective around. Under the CRA you owe information; under the Data Act you owe data. A “connected product” there is any item that generates data about its use or environment and is able to transmit it (Article 2 Data Act); in its explanation of the Data Act, the European Commission explicitly names industrial machinery as an example. The user is whoever owns, rents or leases the machine, in other words your customer.

Take, as a fictitious example, an operator who calls the service team. He wants the operating hours, error codes and energy consumption of his three machines over the last twelve months because he is preparing an energy audit. Today, someone pulls a CSV from the controller supplier’s dashboard, provided the login still works, and sends it by email.

The Data Act turns this favour into an entitlement, and in two ways. The three machines are already in the field. If the operator cannot access the data himself, you as the data holder have, since 12 September 2025, been obliged to make readily available data available without undue delay, free of charge, in a machine-readable format and, where technically feasible, continuously and in real time (Article 4 Data Act). In a service manager’s day-to-day work, “readily available” means the data the controller logs anyway.

If the same operator orders a fourth machine that is placed on the market after 12 September 2026, Article 3(1) applies. Product data and related service data must then be accessible by default: easily, securely, free of charge, in a structured, machine-readable format and, where technically feasible, directly (Article 3 Data Act).

You or your dealer must tell him which data the machine generates and how he can retrieve it before the contract is concluded. Trade secrets remain protected through agreed safeguards; you may refuse access only in narrowly defined cases.

Put simply: the Data Act requires an authenticated interface through which a specific customer pulls the data of a specific machine, as a download or via API. Technically, this is the same infrastructure as the channel for CRA security advisories: a login, a mapping of customer to serial number and a backend with access to machine data and documents.

One portal, two mandatory functions: security advisories and data access

That is why I argue not for two compliance projects but for one with two mandatory functions. The portal has a hard core and a soft shell.

The hard core comprises a machine record per serial number with operator, software version, declaration of conformity and support period; a notification function that sends security advisories specifically to the operators of affected model series and logs that they have been read; and data access with export and API token. On top of that comes a reporting route through which customers report anomalies to you, as one part of the single point of contact under Article 13, alongside phone and email.

You know the soft shell from B2B commerce, with spare parts, service requests, invoices and reorders. There is no reason to build the two separately. A self-service portal based on Shopware B2B comes with roles and approvals; the machine record and security advisories are added as separate modules. Where the standard isn’t enough, for example for real-time data from the controller, a dedicated service sits alongside.

The ERP holds serial numbers, order history and customer master data; that is where the truth about who bought which machine is created. That is why the integration with your ERP determines the value of the portal. Without this link, you build a second data world that quickly drifts away from the ERP.

Suppose a manufacturer of packaging machines (fictitious example) learns on Monday morning of an exploited vulnerability in the remote maintenance module of one model series, with 340 machines in the field. With a portal, the product manager filters the affected serial numbers, sends out the security advisory including a workaround, sees by Wednesday which operators have opened it and only phones the rest.

Without a portal, Monday starts with a hunt for current contacts across ERP, CRM, service tickets and the inboxes of the field sales reps, for 340 machines, some of which have since changed hands. On Thursday morning, the 72-hour notification to the authority is due, and nobody knows reliably which operators have received the advisory.

From mandatory channel to aftersales revenue

This is where the obligation becomes a business model. Every security advisory brings your customer into your portal, and so does every data export. This gives you regular contact with the operator that no salesperson has to force, and you know how old each machine is and which software version it runs.

Anyone who sees the update for their controller in the portal also sees, right next to it, the wear parts for this model series, the maintenance contract that is due and the retrofit offer. The machine record you need to meet Articles 13 and 14 in practice can also carry a spare parts shop with exploded-view drawings. And the export required by the Data Act is also the route through which you sell condition monitoring as a service. One example is an alert as soon as the bearing temperature of a spindle exceeds the threshold, together with a suggestion for the next maintenance window.

The next regulation can also build on this machine record. The digital product passport will gradually require a digital data record for each product group, per model, batch or individual item depending on the legal act, retrievable via a data carrier such as a QR code. If you set up clean serial number logic today, you already have a good part of it in place.

The Data Act does, however, have an uncomfortable side that you should price in. Your customer may pass the machine data on to third parties, such as independent maintenance providers, and the European Commission explicitly names more competition in services as a goal of the regulation. If an independent service provider sees the same operating data as you in future, the operator will decide on convenience. He will stay with the portal in which he finds the machine, its software version and the matching spare part the fastest.

What I would do now in your position

My recommendation is unspectacular and therefore achievable.

1. An inventory. Which of your products have software, connectivity or a cloud connection, which of them are where in the field, and whom can you reach there today? This list is the basis for every notification and every notice to users under Article 14. If it has so far only existed in the heads of the service team, it is the first task.
2. A minimum portal before the full build-out. Login, machine record per serial number, notification with read receipt, data export. With the ERP as the source of record, this should be achievable within a few months. You then build the spare parts shop, service contracts and real-time data on the same foundation.
3. Rehearse the internal reporting process before an emergency forces it on you. Decide who approves the early warning at weekends too, and run through the process once with a hypothetical vulnerability.

The Cyber Resilience Act and the Data Act are often described as bureaucracy, and part of them is. The bigger part is an answer to a question that mechanical engineering has long left open: who actually knows the operator of the machine once it has left the factory? Since 11 September 2026, you have had to be able to answer it, and from 11 December 2027 the CRA applies in full. Answer it thoroughly, and the channel belongs to you, not to the independent service provider who would otherwise take it over.