CRA for machine manufacturers after the Commission guidelines of 27 July 2026. What really needs to be implemented?

For years, machine cybersecurity could be summed up in three steps: a branded controller, a VPN “because that’s how it’s done,” and the classic “the customer will secure the network.” If someone also added a firewall in the cabinet, the issue was often treated as closed — at least until someone tried to check what would happen in a real attack rather than in a presentation.

Except cybersecurity does not flow over PROFINET. Components may come with certificates, declarations, and “secure by design” in the marketing brochure, but the machine as a whole can still be predictable in a way that has nothing to do with safety. Just as a safety relay does not make a system safe if the control logic allows it to be bypassed, a “secure” HMI does not solve problems with architecture, integration, permissions, updates, or what happens when someone stops asking for permission.

CRA (Cyber Resilience Act, Regulation (EU) 2024/2847 of the European Parliament and of the Council) is not an add-on for IT. It is a product regulation that enters the machine lifecycle whether the automation department likes it or not. It covers control system design, risk analysis, the supply chain, configuration, updates, and product maintenance long after FAT has been signed off and the machine has left the shop floor. And no, “we don’t expose it to the internet” does not settle the matter. In practice, a service laptop, a USB drive, temporary remote diagnostics, or integration with a plant system is enough for the line between isolation and exposure to disappear.

The Commission guidance of 27 July 2026 did not change the regulation itself, but it effectively narrowed the room for interpretation that had previously allowed cybersecurity to be treated as an optional layer. It clarified, among other things, the product boundary, the role of remote data processing, responsibility for changes made after delivery, and the fact that “it’s not our problem after FAT” is no longer a safe assumption.

The most important change, however, is more fundamental: a cyberattack is no longer just an IT event; it becomes a scenario that affects the machine’s functional safety. If an unauthorized program change can cause axis movement, bypass an interlock, alter process parameters, or disable a safety function, then this is no longer just a “network incident.” It is potentially uncontrolled machine behavior — regardless of whether the source was a configuration error, a software vulnerability, or deliberate interference.

In this context, a one-off pentest before FAT stops being evidence of compliance and becomes only a snapshot of the system at a specific moment. CRA requires a continuous approach: from design, through production and commissioning, to updates, vulnerability management, incident response, and maintenance throughout the declared support period.

In practice, this means moving away from “done = secure” toward “maintained = controlled.” Without the illusion that a firewall in the cabinet, a VPN, and a component certificate close the issue. And without assuming that cybersecurity ends when the acceptance protocol is signed.

In this article, we break down what the CRA guidance actually changes for machine manufacturers, integrators, and retrofit providers — without reducing the whole issue to “let’s change the password and add a cybersecurity checkbox.”

1. For a machine to fall outside CRA, it would have to be built almost entirely from contactors

In many projects, the CRA scope is checked with a single question:

Will the machine be connected to the internet?

No.

So the issue is closed.

The schematic shows a PLC, HMI, several drives, distributed inputs and outputs, a valve island, a safety scanner, and a port for downloading the program. The controller communicates with the panel over PROFINET, exchanges control and status words with the drives, and the sensors send data via IO-Link.

But there is no router with a SIM card.

As everyone knows, data only becomes data once it leaves the production hall.

Except CRA does not ask whether the machine has internet access.

It asks whether its intended purpose or reasonably foreseeable use includes a direct or indirect, logical or physical data connection to a device or network. This does not have to be a connection to the cloud, the manufacturer’s server, or the public internet. It may run over a cable, by radio waves, through a software interface, or as part of a larger system.

And now the key question: in a typical machine, what actually transmits data?

Does the HMI read statuses from the PLC and write setpoints?

Does the PLC send a control word to the drive and receive speed, status, and an error code in return?

Does the I/O island transmit the process image?

Does the IO-Link sensor send a measured value, device identifier, and diagnostic data?

Does the safety PLC communicate with modules via PROFIsafe?

Are the program, hardware configuration, or firmware loaded from a service laptop?

Can recipes, reports, or updates be transferred via USB?

If the answer is “yes” even once, then there is probably a data connection.

And that does not change the fact that:

• the machine operates on a local network,
• it has no public IP address,
• the Ethernet port is used only during commissioning,
• only service personnel connect a laptop,
• communication takes place only within the control system,
• the customer promised never to connect the machine to the internet.

CRA covers not only the use described in the manual as intended use, but also reasonably foreseeable use. So a service port does not stop transmitting data just because the drawing labels it “SERVICE ONLY”.

However, the Commission guidelines of 27 July 2026 introduce an important distinction.

Not every wire and not every electrical signal is a data connection.

If a signal is used solely to switch a specific function on, switch it off, or power it, and it does not transmit digitally encoded information, the mere presence of two electrical states is still not enough to treat it as a data connection.

A pushbutton that applies voltage to a contactor coil does not become a digital interface just because its state can be described as zero or one.

Likewise, a conventional limit switch wired into a relay-contactor circuit may do nothing more than open or close the circuit. It does not transmit a device number, process value, diagnostic code, firmware version, or a telegram carrying several pieces of information.

But when that same state reaches an intelligent device, is encoded, transmitted over a bus, linked to diagnostics, and interpreted by the receiver as information, the situation is different.

So the line is not between an “online” machine and an “offline” one.

It is between an ordinary control signal and the exchange of digitally encoded information.

That is why, in practice, a machine that would remain outside the scope of CRA solely because it has no data connection would need to look much more like a classic arrangement of pushbuttons, limit switches, relays, and contactors than a modern design opened in TIA Portal.

This is not, of course, a statutory exclusion for contactors.

You can build a simple machine with a PLC that, after a detailed analysis, does not meet the scope criterion. You can also add a digital controller, service interface, or communication module to a contactor-based system and end up exactly on the other side of the line.

The component name does not decide the issue.

What matters is what the product actually does and what it exchanges data with.

So before answering whether a given machine falls under CRA, you need to determine:

• where the boundary of the assessed product lies,
• which devices and software elements are part of it,
• which physical and logical interfaces it has,
• what information is transmitted through them,
• which connections are direct and which take place through a larger system,
• which of them occur during normal operation, commissioning, diagnostics, updates, or service,
• which modes of use are reasonably foreseeable, even if the manufacturer would prefer not to foresee them.

Until these questions are answered, we do not know whether the machine remains outside the scope of CRA.

At most, we have a convenient statement:

“The machine is not connected to the internet.”

But that answers a question CRA is not asking.

PROFINET is not the internet. For CRA purposes, it does not have to be.

2. Cybersecurity does not spread over PROFINET

In many projects, the issue of machine compliance starts as early as the purchasing stage.

PLC from a reputable manufacturer.
HMI with up-to-date firmware.
Managed switch.
Industrial router with VPN.
Drives with safety functions.
Safety PLC with the appropriate certificate.

For each device, a declaration of conformity, a manual, and several documents featuring words like “secure”, “encrypted”, and “defence in depth”.

On the schematic, everything looks professional.

But it still does not tell you whether the complete machine is cybersecure.

Because cybersecurity does not “carry over” via PROFINET.

It is a bit like a door lock:
you can have a very good lock on every room, certified, tested, with beautiful documentation and a “secure” hologram, but that still does not guarantee security if someone left the front door wide open “because it was quicker during commissioning”.

And it is exactly the same here: the components may be exemplary, and the system can still be… creatively open.

The PLC does not “pass on” security to the HMI.
A firewall does not “fix” the application logic.
A switch does not “organise” user access.
And the fact that every element has a certificate still does not mean the whole machine is not one large, politely documented vulnerability.

PROFINET transmits data.

It does not transmit responsibility.
And unfortunately, it does not transmit common sense either.

CRA covers both complete products and components placed on the market separately. This means that a controller, operator panel, or communication module may be assessed separately. But the machine manufacturer must still demonstrate that the whole system operates securely in the customer’s real configuration — that is, in the version where someone “definitely did not change anything afterwards… right?”.

And this is where the most common mistake appears.

It is exactly the same mechanism we have known for years from machinery safety.

The light curtain is PL e.
The safety PLC is SIL 3.
The drive has STO.

Does that automatically mean the entire machine is at that level?

Just as the fact that every scaffold component meets safety standards does not by itself guarantee that the whole structure will be stable.

No.

Because you still need to verify how it all works together — in other words, that unpopular stage called “systems thinking”, which unfortunately does not come with an “auto-certify” button.

It is exactly the same in cybersecurity.

You can have “secure” components, but in practice:

• the operator can see and change more data than they actually need, because “it was more convenient that way”,
• one service password works on all machines, because “the service team knows what it’s doing anyway”,
• the service port is left accessible “just in case”, which really means for any case,
• remote access covers the entire network, because someone once said “it’s only for diagnostics”,
• updates can be installed without control, because “nothing has ever gone wrong”,
• devices “trust each other” without limits, because trust is cheaper than segmentation,
• and the integration assumes that no one will ever make a mistake, which — as history shows — is the most optimistic assumption in engineering.

Each component on its own may be correct.

But the system as a whole can turn those correct components into something that works… just not necessarily the way it was intended to.

And this is the key point: risk does not sit in the devices themselves, but in how they are connected, configured, and in that legendary access left “temporarily” in place.

CRA requires more from the machine manufacturer than collecting declarations like trophies. It requires checking whether what has been assembled from components is still secure as a whole — not just that it “looks good in the compliance table”.

In practice, that means straightforward business questions:

• does each user have only the access they genuinely need, rather than access granted “just in case it might be useful one day”,
• is remote access limited to the minimum, or to the maximum level of convenience,
• does the service team have “full rights everywhere” because someone decided it made life easier,
• is the network one shared flat space because segmentation “complicates the project”,
• are updates controlled, or is it more a case of “push them and pray”,
• can you quickly identify which machines are exposed, or is it more “we’ll check after the incident”,
• does failure of one component open up the whole system because “that’s how the integration turned out”.

These are not technical questions “for engineers who deal with the difficult stuff”.

They are questions about business risk: downtime, cost, liability, and that small detail that production still has to run.

That is why it is not enough to say:

“all components are compliant”

Because that still does not answer the question:

is the whole machine safe in real use, or only in the PowerPoint from the design review?

The supplier’s declaration matters.

But it applies only to one component — the one that happened to be tested under laboratory conditions, not in an environment “somewhere on the shop floor, with VPN, USB, and time pressure”.

It does not cover how it was used.
It does not cover the configuration.
It does not cover the integration.
It does not cover decisions made “quickly during commissioning because the customer was waiting”.
It does not cover what happens after years of operation, when no one remembers why something was “temporarily left open”.

That is why the assessment cannot stop at a list of devices.

You have to look at the system as a whole:

• who has access and why (not simply “because they always had it”),
• what is genuinely needed and what was merely “left in place because it was not causing problems”,
• where data can leak beyond control because someone decided that “it’s only diagnostics”,
• what happens when someone uses legitimate access in an illegitimate way (which is exactly how attacks work),
• how quickly you can respond when a problem appears, rather than “after the quarterly review”.

Until those questions are answered, all you have is a set of very solid components.

You do not yet have a secure machine.

Component compliance does not automatically create system compliance. Machine compliance has to be designed, verified and — hardest of all — maintained despite the temptation to “leave it alone because it works”.

3. Do not add cyberattack to the hazard list. Connect the two analyses at the right point

In the machinery market, a formal cybersecurity risk assessment is still more the exception than a standard part of the project.

Usually there is an industrial router.

There is a VPN.

There is a password on the PLC.

Sometimes there is a managed switch that nobody manages afterwards.

In the more ambitious version, the manufacturer gets a supplier presentation on “defence in depth” and concludes that the cybersecurity risk assessment for the entire machine is now complete.

It is not.

They bought a few technical measures.

That is not yet an assessment.

So there is no point describing the problem as if every project produced two professional assessments — one according to ISO 12100, the other on cybersecurity — which simply happened not to be connected to each other.

Most often, only one is created.

Machine risk assessment.

And no product cybersecurity analysis is created at all.

A machine risk assessment under ISO 12100 does not consist of entering the following in a table:

sensor failure → unexpected movement → crushing.

That may be part of a specific scenario, but it is not the starting point.

First, the machine’s limits must be defined.

What is its intended use?

What are the life-cycle phases?

Who will use it?

What tasks will be carried out during transport, assembly, commissioning, production, adjustment, cleaning, jam clearing, maintenance, diagnostics, and dismantling?

In what operating modes can the machine run?

Where is the person located during each of these operations?

Which parts of the machine remain energized, pressurized, loaded, or in motion at that time?

What use is contrary to the instructions, yet still reasonably foreseeable?

Only then, for a specific task or operation, do you identify, among other things:

• the hazard source,
• the type of hazard,
• the hazard zone,
• the exposed person,
• the hazardous situation,
• the hazardous event, if it occurs in the scenario,
• the possible consequences and the type of harm.

This is what machine risk analysis looks like.

You do not start with the component.

You start with the person performing a specific task on a machine in a specific state. ISO 12100 sets out exactly this methodology for hazard identification and for risk estimation and evaluation during the relevant phases of the machine life cycle.

Take a simple example.

An operator removes a jammed part from inside a palletizing cell.

So we have:

Task: clearing the jam.

Phase of use: operation, intervention after the process has stopped.

Operating mode: manual or service mode.

Exposed person: operator or maintenance technician.

Hazard zone: inside the cell, in particular the space between the gripper, the part, and the machine structure.

Hazard source: mechanical energy from the robot, linear axis, or pneumatic gripper.

Hazardous situation: a person is in the zone while movement is still possible.

Hazardous event: unexpected axis movement, gripper closure, or release of stored energy.

Possible consequence: impact, crushing, fracture, or amputation.

Only now can the risk be assessed and risk reduction measures defined.

A guard interlock may be needed.

Safe stop may be needed.

Prevention of unexpected start-up may be necessary.

It may be necessary to vent the pneumatic energy.

It may be that movement in manual mode can take place only with an enabling device and safely limited speed.

This is still a classic machine risk assessment.

Where does cybersecurity come in?

Not as a new entry alongside mechanical, electrical, and thermal hazards.

“Hacker” is not a source of mechanical hazard

Adding the following entry to an ISO 12100 table:

Hazard: cyberattack

adds very little.

A cyberattack is not a rotating shaft, a sharp edge, high temperature, or pneumatic energy.

Nor is it a separate hazard zone.

An operator is not crushed by a CVE vulnerability.

They are crushed by a machine element that moved while the person was in the wrong place.

A cyberattack can, however, change the state of the control system, the data, the program, the configuration, or the way a protective measure operates.

It can therefore become:

• the cause of a hazardous event,
• an additional path leading to a hazardous situation,
• the cause of a risk reduction measure losing effectiveness,
• or a way to bypass the assumptions adopted when designing the safety function.

And that is the real point of contact.

Not the list of hazards.

The machine’s behavior.

Cybersecurity analysis should be prepared separately

For a machine or automation system, a cybersecurity analysis will have a different structure from a risk assessment under ISO 12100.

For an industrial automation system, IEC 62443-3-2 provides the most natural framework.

The standard requires, among other things:

• defining the system under consideration, i.e. the SUC,
• dividing the system into zones and conduits,
• assessing risk for individual zones and conduits,
• defining target security levels SL-T,
• documenting the security requirements.

This is a completely different starting point from ISO 12100.

In IEC 62443, we ask, among other things:

What exactly belongs to the system being analyzed?

Which assets need to be protected?

What devices, applications, and interfaces are in the system?

Which elements should belong to the same zone?

How does communication flow between zones?

Who can gain access?

From where?

Using which interface?

Which vulnerabilities could be exploited?

Which data, functions, or components could be altered?

What path could an attacker take from the service router to the PLC, HMI, drive, or engineering workstation?

What would be the consequences of losing confidentiality, integrity, or availability?

What protections are needed?

For the secure product development process and the requirements that apply to the components themselves, other parts of the series also matter, in particular IEC 62443-4-1 and IEC 62443-4-2. IEC 62443-3-3, in turn, structures the technical security requirements at the system level.

CRA does not currently require a manufacturer to put “prepared in accordance with IEC 62443” on the cover of the analysis.

IEC 62443 also does not replace demonstrating compliance with CRA requirements.

For an industrial automation system, however, it is a far more logical reference point than trying to add a few hacker scenarios to an ISO 12100 table.

Because the two methodologies answer different questions.

ISO 12100:

During which task, where, from what source, and as a result of what event could a person be harmed?

IEC 62443:

Who, by what route, and by exploiting which vulnerability could affect the system, its data, or its functions?

Only then do you need to check whether the answer from the second analysis changes the scenario from the first.

The same scenario, two different analyses

Let us return to the operator clearing a jammed part.

The ISO 12100 analysis showed that the person enters a zone where they could be crushed by robot or gripper movement.

The risk reduction measure is an interlocked guard, a safe stop function, and a local reset located outside the hazard zone.

Now we carry out the system cybersecurity analysis.

We identify:

• the router used for remote service,
• the service account,
• the engineering laptop,
• the HMI,
• the standard PLC,
• the safety PLC,
• the drives,
• the programming interface,
• the PROFINET network and PROFIsafe communication,
• the mechanisms for uploading the program and configuration.

We consider the following scenario:

Compromise of the service account enables remote access to the standard PLC and the sending of a motion command while a person is inside the cell.

Does this scenario lead to a hazardous event?

You cannot answer that based on the PLC compromise alone.

You need to check the safety function architecture.

If guard opening is monitored by the safety PLC, the function safely removes drive torque, reset is local only, and the standard PLC cannot restore motion independently of the safety function state, then compromising the standard controller may stop production or disrupt the process.

But it should not cause motion with the guard open.

In that case, the cybersecurity analysis shows an attack.

The machine risk assessment under EN ISO 12100 shows a mechanical hazard.

A properly designed safety function, however, breaks the path between them.

Now consider the second variant.

Service mode is selected from a standard HMI.

The limited-speed value comes from the standard PLC.

The remote service technician can perform a reset.

The same engineering account allows changes to both the standard program and the safety configuration.

The backup copy of the safety program is not tied to a specific machine version.

No one checks the checksum after the intervention.

Drive parameters can be changed remotely.

In this architecture, compromising the account no longer means only loss of confidentiality or a short downtime.

It can change the conditions on which risk reduction relied.

It can lead to:

• selection of the wrong mode,
• changing a safe motion parameter,
• an unauthorized reset,
• uploading an unapproved configuration,
• or weakening the function intended to prevent unexpected start-up.

And then the cyber scenario must be linked to a specific machine safety scenario:

jam-clearing task → person in the hazard zone → unauthorized change to the control system or protective function → unexpected movement → crushing.

The hazard source has not changed.

It is still the machine’s mechanical energy.

The hazard zone has not changed.

It is still inside the cell.

The possible consequence has not changed.

It is still operator injury.

What has changed is the path leading to the hazardous event.

Not every vulnerability belongs in ISO 12100

This distinction is just as important.

Assume that a vulnerability in the HMI allows historical production data to be read.

That may be a significant issue from the perspective of CRA for industrial manufacturers.

It may breach data confidentiality.

It may require an update, an impact assessment, action toward users, and, in certain circumstances, reporting as well.

But if it does not affect machine behaviour, does not change a protective measure, and cannot lead to a hazardous situation, there is no point forcing it into a risk assessment under ISO 12100.

Likewise, an attack that only makes production reports unavailable may create a business issue and a CRA compliance issue.

It does not, however, necessarily create a risk to the operator.

On the other hand, what looks like a harmless ability to change a single setpoint may matter little for data confidentiality, but a great deal for physical safety.

For example, when that value defines:

• the maximum axis speed,
• the clamping force,
• the process temperature,
• the pressure,
• the stop position,
• the valve opening time,
• or the permissible limit during operation with the guard open.

So we do not classify a cyber threat by how technical it sounds.

We look at what it can actually do to the machine.

The Machinery Regulation forces this bridge

This connection is not just good engineering practice.

Point 1.2.1 of Annex III to the Machinery Regulation requires control systems to be designed and constructed so as to prevent hazardous situations from arising, including as a result of reasonably foreseeable malicious attempts by third parties.

CRA, in turn, indicates that its essential cybersecurity requirements may support demonstration of conformity with, among others, requirements 1.1.9 and 1.2.1 of the Machinery Regulation.

But this does not happen automatically.

The manufacturer must demonstrate that relationship on the basis of a risk assessment. Conformity assessment under CRA and conformity assessment under the Machinery Regulation remain separate processes.

In other words, it is not enough to prepare:

• an ISO 12100 risk assessment,
• an IEC 62443 analysis,
• two separate reports,
• and assume that similar standard numbers will create an audit trail between them.

A link between them is needed.

For each relevant cyber scenario, you need to determine:

1. which component or function can be taken over or altered,
2. what machine behaviour this may trigger,
3. whether that behaviour leads to a hazardous situation or hazardous event,
4. which task and which hazard zone it affects,
5. which possible consequence was identified in the ISO 12100 assessment,
6. which risk reduction measure should interrupt the development of the scenario,
7. whether that measure remains effective after the attacked component has been compromised.

This last point is the most important.

Because if both the attack and the safeguard depend on:

• the same controller,
• the same account,
• the same network,
• the same engineering workstation,
• or the same program,

then you may not have two independent layers of protection.

You may have one layer described in two documents.

So we do not need one huge table called:

“safety & cybersecurity risk assessment”.

We need two sound analyses, carried out using the appropriate methods, and a controlled interface between them.

ISO 12100 should describe the person, the task, the hazard source, the zone, the hazardous situation, the hazardous event, and the possible harm.

IEC 62443 should help describe the system, its zones, communication channels, assets, threats, vulnerabilities, attack paths, and required protections.

And the manufacturer must show whether a scenario from the second analysis can trigger a scenario from the first, or remove the effectiveness of the measure intended to stop it.

A cyberattack does not have to create a new hazard. It is enough that it opens a new path to an old accident.

4. A pentest before FAT is a snapshot. CRA requires a film

In many projects, cybersecurity appears two weeks before FAT.

A pentest is commissioned.

A report is produced.

Critical vulnerabilities are fixed, medium ones are accepted, and the document goes into the project folder.

The machine is cybersecure.

Until next Tuesday.

A pentest can be a very valuable part of verification. But it shows the state of a specific product version, in a specific configuration, using specific test scenarios.

It does not answer the question of what the manufacturer will do later.

And CRA applies to the entire product lifecycle. The cybersecurity risk assessment is meant to influence planning, design, development, production, delivery, and maintenance of the product. After the product is placed on the market, the manufacturer must handle vulnerabilities throughout the declared support period.

Let us go back to the vegetable packaging machine.

The machine passed FAT.

The pentest found no critical vulnerabilities.

Eight months later, the manufacturer of the service router publishes information about a vulnerability that allows the device to be taken over.

And now the real work starts.

Which delivered machines use that router model?

Which firmware version was installed on each unit?

Is remote access enabled?

Can the vulnerability be exploited in the actual configuration?

Does compromising the router provide access only to diagnostics, or also to the HMI, PLC, drives, and safety PLC?

Is only data reading possible, or also changing the program or parameters?

Can the attack affect a safety function?

Has the supplier provided a patch?

Will the router update change certificates, communication rules, or the way the tunnel is established?

After an update, do remote service, communications and some safety functions need to be checked again?

Which customers need to be notified?

And does the situation meet the criteria for reporting an actively exploited vulnerability or a serious incident?

A pentest report completed before FAT will not answer any of these questions.

It describes a machine that no longer exists.

Since the assessment, software versions, configurations, the user environment and knowledge of vulnerabilities have all changed.

That is why the manufacturer needs not just a test, but a process:

• identifying the hardware, firmware and software versions in each delivered unit,
• monitoring vulnerability information,
• assessing how those vulnerabilities can be exploited in the actual architecture,
• checking the possible effects on the process and the safety of the machine,
• preparing and testing updates,
• informing users,
• documenting the decisions taken,
• handling the required notifications.

From 11 September 2026, manufacturers will be required to report actively exploited vulnerabilities and serious incidents affecting the security of products with digital elements. An initial warning must be submitted within 24 hours, and the full report within 72 hours.

This means that once a problem is detected, there will be no time to start asking questions:

“Who actually made this router, and where is the list of machines we installed it in?”

IEC 62443-4-1 and CRA clearly show the difference between securing a product once and managing a secure development lifecycle. It covers not only design and verification, but also defect management, patches and end-of-life.

So FAT may close a project stage.

It does not close the product lifecycle.

It does not close the support period.

It does not end vulnerability monitoring.

And it does not mean the configuration accepted on the handover date is frozen for the next fifteen years.

The machine may spend years packaging vegetables for supermarkets.

But the manufacturer cannot package its cybersecurity with the manual, shrink-wrap it, and assume it has been delivered once and for all.

A pentest may close an item on the FAT checklist. CRA opens a process that lasts until the end of the product support period.