A wheel loader with a SIM card in its telematics box meets the EU’s legal definition of a “product with digital elements.” That one component is enough to pull a machine that never needed a license plate straight into the Cyber Resilience Act (CRA).
Most off-highway manufacturers have heard that cars and trucks are excluded from the CRA and assumed the same logic covers their equipment. It does not. Tractors carry type-approval under Regulation (EU) 167/2013, not under Regulation (EU) 2019/2144, so they do not qualify for the CRA’s vehicle exclusion either. Forklifts, cranes, excavators, forestry harvesters and port equipment never had any vehicle type-approval to lose in the first place, agricultural or otherwise. Here is what that actually means for the machines you build, not just the regulation text behind them.
Does the Cyber Resilience Act apply to forklifts, excavators and harvesters?
Short answer: yes, if the machine or any of its electronic components connects to a network, a device, or a diagnostic port.
The CRA excludes exactly one group: vehicles type-approved under Regulation (EU) 2019/2144, categories M, N and O, meaning cars, trucks, buses and trailers. That exclusion exists because those categories already carry cybersecurity type-approval under UN Regulation R155.
A forklift has no UN R155 obligation. Neither does a crane, an excavator, a forestry harvester, a forwarder, a port straddle carrier, or a tractor. There was never a vehicle-safety exclusion for these machines to inherit, so the only question that matters is the CRA’s own test: does the product carry a digital element and reach the EU market.
What actually counts as a “digital element” on a machine like this?
Not a laptop. Not a server. Any of the following, already standard on most equipment shipped in 2026:
- A controller (ECU) running embedded Linux or proprietary firmware
- A CAN bus, J1939 or ISOBUS network linking sensors, valves and actuators
- A telematics box reporting location, engine hours and fault codes over LTE
- A remote fleet-management dashboard or a service technician’s mobile app
- An over-the-air (OTA) path for firmware or configuration updates
Ten years ago, a wheel loader was a hydraulic machine with a diesel engine. Today it is a rolling network node with a SIM card, and the SIM card is the part that changes its legal status. Strip all of that out and you are left with a purely mechanical implement, the one category the CRA genuinely does not touch. Almost nothing shipped by a serious OEM still qualifies.
Does agricultural and earth-moving machinery get a standard of its own?
Short answer: yes, one is already in draft.
ISO/DIS 24882, drafted jointly by ISO/TC 23/SC 19 and CEN/TC 144, covers agricultural, tractor and earth-moving machinery with a programmable electronic system, and is expected to publish around mid-2027 (prEN ISO 24882). Its own Annex D maps the work directly onto ISO/SAE 21434, the automotive cybersecurity standard that Codelab’s own automotive-grade engineering practice already applies on client projects. Construction, mining and material-handling equipment are not named in that specific standard, but they answer to the same Machinery Regulation clauses, and CECE, the Brussels association representing over a thousand construction and mining equipment companies, is tracking the same file (CECE members).
Why do two separate 2027 deadlines actually test the same thing?
Short answer: because they were written to be read together, not chosen between.
11 September 2026: CRA reporting goes live. A manufacturer that discovers an actively exploited vulnerability has 24 hours to file an early warning with ENISA through the single reporting platform (Regulation (EU) 2024/2847).
20 January 2027: the Machinery Regulation (EU) 2023/1230 becomes mandatory. For the first time, cybersecurity is a safety essential requirement for machinery, not an optional extra (clauses 1.1.9 and 1.2.1) (EUR-Lex).
11 December 2027: full CRA compliance. Security-by-design, technical documentation, CE marking under the CRA.
The European Commission’s own guidance is direct about this: a machine that is both a product with digital elements and a machine under the Machinery Regulation “should comply with both” sets of requirements at once, not one or the other (CRA ORCWG official FAQ).
September 2026 tests whether you can report a vulnerability in 24 hours. December 2027 tests whether you can prove, on paper, that the engineering behind your machine was done right.
Does a machine already in the field need to comply too?
Short answer: existing machines need a documented risk assessment and a vulnerability disclosure policy either way. A substantial modification, any change that touches a cybersecurity safeguard, triggers full CRA compliance immediately, and the bar for what counts as “substantial” is lower than most engineering teams expect.
Sławomir Kukurenda, Lead Project Manager and Business Development at Codelab, sees this catch clients off guard on almost every project:
The scope of “substantial” tracks impact on cybersecurity, not size. Swapping a riveted enclosure for one that closes with screws can qualify, if the rivets were the tamper protection blocking physical access to a JTAG port.
Translate that into a machine builder’s calendar: retrofitting a wheel loader platform with a new telematics module, adding LTE to an older excavator line, or moving a forklift fleet from a legacy protocol to CAN. The same clause can trigger on something far smaller, like swapping an access-management library or turning on multi-factor authentication. Each of those is a normal product-roadmap decision. Each one can also reopen a compliance file that was closed a year earlier.
Where do the process gaps usually hide?
Short answer: not in the electronics. In the paper trail behind them.
Anna Michel-Makuch, Lead Quality Partner at Codelab, runs first-pass assessments across exactly this kind of equipment:
In practice, that looks like a firmware update process that works fine but has no documented risk assessment behind it, a component list for controllers and telematics modules with no version-linked SBOM (useful, not mandatory under the CRA, and sometimes overkill for a small, simple codebase), and a field service team patching machines with no formal vulnerability-disclosure channel on the other end.
Where should you start?
CRA penalties rarely target the vulnerability itself. They target the absence of a process, a procedure, or a systemic approach to cybersecurity behind it.
Short answer: with a written gap assessment, not new tooling.
The pattern behind both deadlines is the same: regulators want proof, not intent. A firmware-update process that works fine but has no documented risk assessment behind it is not a firmware problem, it is a paperwork problem. So is a controller and telematics parts list with no version-linked SBOM, though an SBOM is not itself mandatory under the CRA and can be overkill for a small, simple codebase, and a field-service patch process with no formal vulnerability-disclosure channel behind it. None of that requires new hardware. It requires a written trail connecting what the machine does to what the regulation asks for, plus clear communication channels with customers and users for reporting problems.
Building that trail with an internal team is possible. It usually means pulling engineering hours away from the product roadmap to document, from scratch, a compliance area most machinery teams have never had to formalize before. That is the part worth outsourcing: not the decision of what “secure” means for your product, but the mapping and paperwork that proves it to an market surveillance authority or to ENISA.
A CRA Compliance Check is a two-week, fixed-price gap assessment: it maps your products, processes and existing artefacts against CRA requirements and hands back an executive summary, detailed findings, and a 30/60/90-day roadmap. Teams that need deeper risk modelling extend it with a Cybersecurity Risk Assessment (CSRA) Workshop using STRIDE and attack-tree methods, the same logic ISO 24882 is built on.
The gap assessment above tells you what is missing. Closing it is a separate, more technical step. From there, most off-highway teams move in one of two directions. A CRA Secure Pipeline is a pre-integrated DevSecOps setup (GitLab, SonarQube, ScanOSS) that generates SBOM and audit-ready evidence on every build, running on both bare metal C/C++ and embedded Linux stack that powers most machinery controllers. A Secure Bootloader closes the gap specifically at the firmware layer, for OEMs whose real exposure is OTA and field firmware updates; exact protocol and channel support is scoped per project and platform.
None of these services replaces your engineering judgment. They replace the months of unpaid internal effort it takes to turn that judgment into something an market surveillance authority will accept as proof.
Key takeaway
The five things to remember
If your team can already show, on paper, a documented risk assessment, a version-linked SBOM and a working vulnerability-disclosure channel, you are already ahead of most of the sector. If any of those three is still in your engineers’ heads and not on paper, a CRA Compliance Check gives you a written answer in one week, at a fixed price, before a market surveillance authority or ENISA asks the same question.
Settle the exemption question
Is your machine really outside the Cyber Resilience Act?
“Bring one product: a forklift, excavator, tractor, harvester, crane or connected machine already in the field. In a 30-minute call, we will identify which digital elements put it in scope, what the upcoming CRA and Machinery Regulation deadlines mean for that product, and which evidence your team would need to show.”
Sławomir Kukurenda · Lead Project Manager / Business Development, Codelab
He wrote this article. He also takes the calls.
No obligation. If the machine is in scope, a CRA Compliance Check maps your products, processes and existing artefacts against the CRA. You receive an executive summary, detailed findings and a prioritised 30 / 60 / 90-day roadmap within one week.
Book a 30-minute CRA scope call →
Full CRA portfolio and FAQ: codelab.eu/cra