Machine builders preparing for the EU Cyber Resilience Act should first have qualified counsel determine which supplied hardware, software, components, and remote data services are products with digital elements, and which company is the legal manufacturer or another economic operator. For products in scope, build product-level cybersecurity risk, technical-documentation, component, support-period, vulnerability-handling, reporting, conformity, and user-instruction workflows.
Two dates require different preparations. Article 14 reporting obligations apply from 11 September 2026. The Regulation’s main obligations apply from 11 December 2027. This guide is current as of 15 July 2026, is a practical planning resource, and is not legal advice, a conformity assessment, or a statement that any machine or product complies.
What is the Cyber Resilience Act?
Regulation (EU) 2024/2847, known as the Cyber Resilience Act or CRA, establishes horizontal cybersecurity requirements for products with digital elements made available on the EU market. The European Commission’s legislative summary describes a product with digital elements as a software or hardware product and its remote data processing solutions, including components placed on the market separately.
That broad description does not answer whether a particular industrial machine, controller program, HMI application, edge component, remote service, spare part, or later modification is in scope. Definitions, exclusions, intended and reasonably foreseeable use, how a product is supplied, other EU legislation, and the roles of manufacturer, importer, and distributor all matter. Use the official Regulation and current guidance with qualified legal and conformity-assessment advisers.
Why does the CRA matter to machine builders?
A machine builder may combine its own software with PLCs, HMIs, industrial PCs, edge systems, libraries, operating systems, drives, and other third-party components. It may also offer updates or remote functions over a support period. CRA preparation can therefore cross engineering, software, purchasing, product management, service, quality, legal, and incident-response teams.
The practical challenge is traceability. When a component vulnerability appears, the builder needs to know which product versions include it, which machines or customers received those versions, what support period applies, who evaluates the impact, what corrective action is possible, and whether a legal reporting duty has been triggered. A remote connection alone cannot answer those questions.
What are the key CRA dates for a machine builder?
| Date | Official transition point | Planning implication |
|---|---|---|
| 10 December 2024 | The CRA entered into force | Portfolio classification and implementation planning should already be underway. |
| 11 June 2026 | Provisions on notification of conformity-assessment bodies began applying | Confirm current assessment routes and notified-body availability with a qualified adviser. |
| 11 September 2026 | Article 14 reporting obligations apply | Have intake, escalation, legal assessment, decision, evidence, and Single Reporting Platform procedures ready. |
| 11 December 2027 | The Regulation’s main obligations apply | Product, technical-documentation, conformity, support, vulnerability-handling, and user-information processes need to meet the applicable requirements. |
The Commission CRA overview confirms the reporting and main-application dates. Article 71 in the legal text controls; monitor official publications because implementation guidance and standards continue to develop.
The Commission’s summary also explains transitional treatment for products placed on the market before 11 December 2027 and notes that Article 14 reporting reaches products with digital elements in scope that were already made available before that date. Do not reduce that rule to a general slogan for legacy machines. Legal teams should apply the exact provisions to the product and event.
How should a machine builder assess product scope?
Create a product-scope worksheet for each commercial offering, not only for the overall machine family.
| Question | Evidence to collect | Decision owner |
|---|---|---|
| What is supplied under the builder’s name or trademark? | Quotes, declarations, labels, manuals, architecture, and software bill of materials (SBOM) | Product, legal and conformity teams |
| Which hardware, software, or remote data processing is part of the offering? | Product boundaries, data flows, hosting and service dependencies | Product and engineering |
| How is it connected in intended or reasonably foreseeable use? | Network diagrams, instructions, supported configurations | Engineering and cybersecurity |
| Is it first made available or later substantially modified? | Release, delivery, modification and change records | Legal, product and service |
| Is another specific EU regime or exclusion relevant? | Legal analysis and conformity strategy | Qualified counsel |
| Which economic-operator role applies to each company? | Contracts, branding, supply-chain and importer records | Legal and commercial leadership |
Do not assume that calling a function a “service” or a component “third party” removes it from the analysis. Conversely, do not declare every connected machine automatically in scope. Record the facts, sources, decision, owner, and review trigger.
What evidence system should be built?
The Commission summary describes manufacturer duties including a cybersecurity risk assessment, technical documentation, conformity assessment, product identification, user information, a defined support period, component due diligence, and vulnerability handling. Translate that legal work into linked engineering records.
At minimum, maintain:
- a stable product, model, and version identity
- the hardware and software architecture and supported configurations
- a component inventory with suppliers, versions, licenses, and dependency relationships
- the cybersecurity risk assessment and design decisions derived from it
- security requirements, test plans, results, exceptions, and correction records
- production and release evidence showing which version was delivered
- user instructions for secure installation, operation, maintenance, and update
- the support period and its communicated end date
- vulnerability intake, triage, remediation, disclosure, and reporting records
- technical documentation and conformity-assessment evidence owned by the responsible function
An installed base management model can link delivered serial numbers, customer sites, configurations, and service owners. It is not itself the full CRA technical file or vulnerability-management system. Use stable identifiers to connect records without copying uncontrolled versions into every tool.
What should a vulnerability-handling workflow include?
Define the workflow before the first urgent case. It should accept reports from researchers, customers, suppliers, service engineers, automated sources, and internal testing. Publish a monitored contact route and assign a primary and backup owner.
A practical flow is:
- Receive and preserve. Record the original report, time of awareness, reporter contact, affected claim, and evidence without altering it.
- Triage safely. Confirm the potential product and version, protect sensitive details, and avoid testing on a live customer machine without authorization.
- Map exposure. Identify affected components, product variants, delivered configurations, support periods, customers, and mitigations.
- Assess. Technical, legal, product-safety, and incident functions determine severity, exploitation, incident impact, reporting, and coordination needs.
- Decide and act. Develop, test, approve, and distribute the appropriate correction, mitigation, instructions, or other response.
- Report and communicate. Make required notifications and coordinate customer, supplier, authority, and public communications under the applicable procedure.
- Close and learn. Preserve the decision evidence, update risks and components, and improve design and support processes.
Do not make one engineer the unreviewed legal reporting gate. Establish an on-call path that works during holidays and outside business hours, because the reporting clock may begin when the manufacturer becomes aware.
What changes on 11 September 2026?
The Commission’s CRA reporting page states that manufacturers must report actively exploited vulnerabilities and severe incidents affecting the security of products with digital elements. It describes an early warning within 24 hours, a fuller notification within 72 hours, and the applicable final-report timing through the CRA Single Reporting Platform.
Those terms have legal definitions and conditions. A support ticket, software defect, safety event, suspected compromise, actively exploited vulnerability, and severe incident are not interchangeable labels. Build a qualified assessment route that can preserve the awareness time, facts, rationale, submissions, follow-ups, and corrective measures.
Before the date, run a tabletop exercise:
- A service engineer receives a customer message suggesting exploitation.
- The intake owner timestamps and protects the evidence.
- Product identity and affected versions are resolved from current records.
- Technical and legal owners determine the required classification and notification path.
- Executives and communications teams know their roles without delaying statutory work.
- The team drafts the initial submission from available facts and records later updates.
- Customer safety, containment, correction, and service actions proceed through owned procedures.
How should remote service fit the CRA preparation program?
Remote service can help an authorized engineer reach a defined diagnostic resource or collect selected machine context. It can also add components, software, dependencies, accounts, data flows, support commitments, and update responsibilities that need to be understood in the product and operational analysis.
For each remote-service design, document:
- whether it is part of the product, a separate product, or an operational service under the legal analysis
- the exact customer-site resources and data involved
- component and software versions and who maintains them
- identity, authorization, revocation, and customer coordination
- update, vulnerability, outage, retirement, and local-recovery processes
- which evidence the platform produces and which evidence must live elsewhere
Keep remote monitoring, resource access, and control separate. Remote reachability does not shift PLC, machinery-safety, production approval, or change-control authority away from the customer site. The standard remote-service guide provides a reusable operational model, while the legal scope and evidence remain product specific.
Where can Orenda fit, and where can it not?
Orenda can be one edge-data and resource-access layer in a machine builder’s support design. Named organization users can open approved project resources through Orenda Connect. A target-scoped vendor bearer link can be revoked and can optionally expire. Because bearer use does not establish the identity of every human recipient, organizations requiring per-person evidence need their own identity, authorization, and evidence controls and should assess whether that access method is suitable.
Each Orenda Box is onboarded and configured for its customer-site context. Protocol, controller, data, network, cabinet, power, environment, and application compatibility must be validated. Orenda does not provide centralized fleet health, reusable configuration templates, or bulk update administration across an OEM’s installed base.
Most importantly, Orenda does not provide CRA compliance, legal advice, conformity assessment, CE marking, a complete component inventory, product risk assessment, vulnerability-management case workflow, regulatory reporting, customer approval, machinery safety, or comprehensive per-human audit evidence. Use the machine builders solution to understand its narrower remote-service role.
What should machine builders do next?
Use this preparation sequence with qualified advisers:
- Assign accountable legal, product, engineering, cybersecurity, quality, service, and incident owners.
- Classify the product portfolio, boundaries, economic-operator roles, transition rules, and assessment routes.
- Link product versions and components to the machines and customers that received them.
- Perform and maintain product-specific cybersecurity risk work and technical evidence.
- Define support periods, secure-use instructions, update responsibilities, and end-of-support handling.
- Make vulnerability intake, assessment, correction, disclosure, and Article 14 reporting operational.
- Run reporting and product-correction tabletop exercises before deadlines.
- Review official EU guidance, implementing acts, standards, and legal advice as they evolve.
What is the final takeaway?
The CRA is not a remote-access feature checklist. For a machine builder, preparation is a product-lifecycle system connecting scope, design, components, delivered versions, risk decisions, tests, instructions, support periods, vulnerabilities, reporting, correction, and conformity evidence.
Start with portfolio and role classification, then make the evidence and response workflows executable. Use connectivity only for the narrow machine-data and support tasks it actually performs. Keep legal decisions, product conformity, customer authorization, PLC control, and machinery safety with the responsible people and systems.
