Are Industrial Robots and Cobots Important Products under the CRA?
Summary
This guide follows one fictional cobot release from classification through the product boundary, risk assessment, SBOM, release sign-off, vulnerability reporting and economic-operator handoff. The same structure transfers to a 6-axis arm, a collaborative cell or a robot controller sold with optional vision and fleet-cloud services.
- Standard route is the planning assumption. Industrial robots and cobots are not named in the CRA Important or Critical product lists today. Treat firewall, network-management or tamper-resistant controller offers as separate classification calls when those functions dominate what is being sold.
- Start with the boundary memo. Name the exact variant: arm hardware, controller cabinet, pendant, fieldbus options, programming runtime, fleet or cloud connector, intended use, supplied digital elements, support period and route rationale.
- Cyber and safety meet from 2027. ISO 10218-1:2025 adds cybersecurity requirements where they affect robot safety, and the Machinery Regulation applies from 20 January 2027. The CRA file and the safety case share evidence at those points.
- Support needs a credible end date. The support period is at least five years unless the expected use time is shorter. Robots often run much longer in factories, so the file should name a support window the maker can deliver and disclose the end date before purchase.
- Vulnerability handling is an operating model. The release file should name who receives vulnerability warnings, who approves maintenance windows, who can roll back an update and how residual advisories stay visible.
- Handover is evidence. The maker holds the product file; the integrator holds the finished-cell file when it ships under the integrator's name; the operator runs the cell. Each transfer is documented, not pushed informally to the customer.
How do you classify an industrial robot or cobot release?
Start with the offer, not the arm hardware. A 6-axis arm sold to a system integrator and the same arm sold as a complete cobot cell to a small workshop are different CRA products. The route depends on what the buyer is paying for, which controller and pendant ship with it, and whether the maker also supplies the fleet cloud, the safety configuration and the OTA update path.
The figure above carries the route choice. The matrix below carries the boundary memo: once a variant is picked, these are the evidence rows the maker should be able to fill in for that specific variant.
Component sale; the integrator builds the cell.
Arm, controller, pendant, programming runtime, fieldbus options, signed updates, vulnerability-handling process and integrator-facing manual.
Engineering-station write authority, recovery slot, fieldbus stack exposure, supplier-component advisory watch, decommissioning credential rotation.
Force-limited collaborative arm, ready-to-run safety configuration, vision option, fleet cloud.
Arm, controller, pendant, safety configuration, vision sensor, programming runtime, fleet cloud connector and OTA service.
Collaborative operation mode (speed-and-separation monitoring or power-and-force limiting), shared-workspace operator role, fleet-cloud authority, pendant accounts, signed safety-firmware path.
Resold under the integrator's CE mark inside a packaging line or process machine.
Robot maker keeps the arm, controller, pendant and shipped software in its own file. The finished machine has its own file under the integrator's CE mark.
Component-supplier advisories (RT OS, fieldbus stack, vision module), supplier conformity-claim alignment, integration-time service exposure, support-window match with the machine maker.
Use the routing aid before writing the boundary memo, not as a substitute. The memo still needs the exact arm model, payload and reach, the controller cabinet, the pendant, the programming environment, the safety configuration scope, the fleet cloud, the OTA service and the intended use. For a complete cobot cell, name the collaborative operation mode the buyer relies on: speed-and-separation monitoring, power-and-force limiting, hand guiding or safety-rated monitored stop.
Then check whether another listed function is doing the real work. The CRA treats a product as Important when its core functionality matches a listed category; embedding a controller does not by itself move a robot into an Important category. If the offer is mainly a firewall gateway, a VPN appliance, a network-management system, an SIEM connector or a hardened controller built around a tamper-resistant chip, classify that core function first and treat the arm as a peripheral.
For component sales, do not force the complete-cell category. A robot arm sold to a system integrator is still a product with digital elements and still needs secure-by-design evidence, an update path, a vulnerability-handling process, a support-period statement and integrator-facing documentation. The route stays standard; the responsibilities split with the integrator.
The classification memo should answer four questions:
- Is the release sold as a robot arm, a complete cobot cell, or a robot integrated inside another machine?
- Is robot motion the product's core function, or is another listed function (firewall, VPN, network management, security-related microcontroller) doing the real work?
- Which digital elements are supplied for the intended function: arm firmware, safety configuration, pendant, programming environment, OTA service, fleet cloud and vulnerability-handling process?
- Which systems are outside the maker's offer: customer cell logic, customer safety PLC, plant network, third-party vision software, customer MES or SCADA?
What belongs inside the robot product boundary?
For a robot maker, the compliance boundary is rarely just the arm. It should follow the product placed on the market and the digital elements needed for the intended motion and safety function.
Treat these as normally inside the robot maker's boundary: arm firmware, joint controller firmware, controller cabinet operating environment, safety controller firmware, pendant, programming environment, OTA service and vulnerability-handling process.
Treat these as normally outside unless the maker sells them as part of the offer: the customer cell logic, customer-written safety configuration, plant network, third-party end-effector, third-party vision software, customer MES or SCADA and the customer safety PLC.
None when these elements come from the integrator or end user. If the robot maker also sells the cell controller, the safety PLC or the MES connector as part of its offer, each may be a separate product with its own boundary file.
Product file · EU Declaration of Conformity · CE marking · Support-period statement · User instructions · Conformity-assessment record
Held by the robot maker for ten years after the robot is placed on the market, or for the support period, whichever is longer. Functional-safety evidence (ISO 10218-1:2025 and ISO 10218-2, ISO 13849, IEC 61508) stays in the same file so the safety case and the cyber-resilience case can be reviewed together.
Cyber-resilience design file · Component inventory · Vulnerability-handling process · Disclosure policy · Secure update mechanism
Include the published single point of contact, secure-defaults test evidence, signed-update verification, downgrade-rejection result and the rationale for the support period.
Component due-diligence record · Supplier conformity claim · Vendor security advisories
The robot maker remains accountable for the joint-drive chip choice. Where a controller chip, safety microcontroller or secure element is itself a product with digital elements, the supplier's conformity claim and advisories support the maker's due diligence rather than replacing it.
The component inventory is monitored against new vulnerabilities; the vulnerability process triages findings; free security updates roll out fixes with advisories, packaged so a plant can validate them inside a maintenance window without breaking machine timing or the safety case.
Actively exploited vulnerabilities require readiness for a 24-hour early warning, a 72-hour vulnerability notification and a final report within 14 days after a corrective or mitigating measure is available. Severe security incidents follow a similar 24-hour and 72-hour track, with a final incident report within one month. The reporting clock starts on 11 September 2026, ahead of the 11 December 2027 general applicability date.
After becoming aware of either, inform impacted integrators and end users, and where appropriate all users, of the vulnerability or incident. Include mitigation or corrective measures users can deploy where necessary, with a clear statement of which steps need a maintenance window.
Which conformity-assessment route applies?
Industrial robots and cobots are not named in the CRA Important or Critical product lists today, so the standard route is the planning assumption. The manufacturer can choose internal control, EU-type examination plus production conformity, full quality assurance, or an applicable European cybersecurity certification scheme. The choice is unconditional; there is no harmonised-standards precondition for default products.
The "standards fully applied" condition belongs to the Important-product fallback, not to the default route. If a future update added a robot or cobot sub-product to that list, and the available standards or schemes did not cover the relevant essential requirements, the manufacturer would need a third-party assessment route for the missing area. The list does not include robots today, so this fallback is the contingency plan, not the planning route.
The Machinery Regulation 2023/1230 applies from 20 January 2027 and includes safety requirements that overlap with cyber evidence, especially protection against corruption and the reliability of control systems. Treat the cyber-resilience file and the machinery safety file as two threads of the same product folder, not two separate compliance projects. The CE mark on the machine refers to both regulations.
Which architecture checkpoints belong in the robot file?
The robot release file should follow the actual machine, not a generic OT checklist. A standalone arm sold to an integrator, a force-limited cobot cell sold to an SME, a robot embedded in a packaging line and a cleanroom robot with vision can share a class discussion while needing different engineering records.
- Motion authority path. Identify every path that can change motion, parameters or safety configuration: pendant, engineering station, vendor cloud, vendor service tunnel, USB transfer, fieldbus from the cell controller and any remote-assist channel.
- Local exposure. After commissioning and after each update, scan the controller for reachable services. The release file should show which services are reachable, which require authentication, and which are off by default.
- Customer systems. Treat the customer cell logic, customer safety PLC, plant network, third-party vision software and MES or SCADA as outside the robot maker's product unless the maker sells that layer.
- Update authority. Treat update authority as a two-way exchange: the controller checks or receives update metadata, and the update service returns a signed firmware bundle for that exact controller variant and safety firmware revision. Keep signed-update, downgrade-rejection, machine-impact, recovery and rollback records with the release.
- Supplier inputs. Give the servo MCU, encoder, safety MCU, fieldbus stack, vision module, RT operating system and programming runtime a named owner, version, advisory watch and release decision.
- Support access. Service tunnels, diagnostics and remote-assist sessions should not become a second motion-authority path. Keep tunnel-disablement, redaction and audit-sample records.
- Post-market loop. Vulnerability reports, severe incidents, supplier advisories and field failures should update the threat list, residual-risk record, release file and next release gate.
The cell diagram below is deliberately broader than the worked example. Use it as a product-family boundary check before narrowing the file to the exact shipped variant: a 6-axis arm, a cobot, a cleanroom variant, a palletising variant, and a robot sold together with an end-effector each need a different evidence set.
Real OEM controllers that fit this layout include ABB OmniCore, KUKA KR C5 (KSS) and KUKA controllers running iiQKA.OS, FANUC R-30iB Plus, Yaskawa YRC1000 and Universal Robots PolyScope X. The partition above is shared across all of them: the maker's product file holds the arm, controller and on-device software boundary; the customer cell logic, plant LAN and customer-owned tooling stay outside unless the maker also sells that layer.
How do you build the robot risk assessment?
Use this example to understand the expected depth, not as text to paste into a release file. A robot maker still needs to run the assessment against its own arm, joint drives, controller, safety controller, pendant, programming runtime, fleet cloud, suppliers, sales claims, support period and release process.
What product are we assessing?
Illustrative example product, not a real device: ExampleCo CR-12, a 12 kg payload, 1300 mm reach 6-axis articulated industrial robot arm with an optional force-limited collaborative mode. It ships with the arm, a controller cabinet, a teach pendant, an optional 2D vision sensor, a programming environment, signed OTA updates and a maker fleet cloud connector. It is sold to small and medium manufacturers as a complete cell, and to system integrators as a component for larger machines.
The product boundary for this example includes the arm, joint drives, controller cabinet, safety controller, pendant, programming runtime, OTA service, vendor cloud connector, vulnerability-reporting contact and end-of-support disclosure. It does not include the customer cell logic, customer safety PLC, plant network, third-party MES or SCADA, third-party end-effector, fence and light curtain installation, or any AGV or AMR base.
The product is intended for indoor industrial use by trained operators and integrators. It is not intended for medical or surgical robotics, service robotics, educational robotics or any consumer use.
Before writing the threat table, test the three paths that usually drive the robot risk assessment: program-load and pendant authority, the safety-versus-cyber boundary, and the integrator handover. These diagrams turn the worked example into engineering questions instead of a generic threat list.
Ownership is a separate check from program load. A controller can have signed updates and still fail if a service tunnel stays open after maintenance, or if an old engineering station keeps writing to it after a customer transfer.
How does a fenced industrial robot's attack surface differ from a cobot's?
The page treats both under the same CRA category because they are: an industrial robot under the cyber-resilience layer, not a smart-home product. The risk profile is different though, and the threat list should reflect that.
| Attack surface | Fenced industrial robot | Force-limited cobot |
|---|---|---|
| Human proximity | Excluded by light curtain, fence, scanner or interlock | Continuous; force-limited motion, speed-and-separation monitoring, hand guiding and safety-rated monitored stop are the safety case |
| Pendant access | Locked cell access; pendant is used by maintenance staff inside the fenced zone | Shared workspace; pendant is used by operators next to the robot, usually with a per-operator role and a quicker logout policy |
| Vision input | Often optional and used for inspection; single point | Often required for safety (separation monitoring); multiple cameras with calibration data the safety case depends on |
| Engineering-station path | Plant engineering station inside the OT lane during commissioning and rare maintenance | Engineering station may sit in the operator's office or even on a corporate-managed laptop; the path is exercised more often |
| Remote teleoperation | Rare in legacy fenced cells; remote-assist sessions are time-boxed maintenance | Increasingly common in some cobot product lines (remote operator assistance, off-site programming); the authority path is wider |
| Most likely threat actor | Engineering or service insider with physical access during a maintenance window | Operator misuse combined with a compromised remote engineering station; vision-input spoofing is a credible cobot-specific path |
| Reset on misuse | Usually a key-locked mode switch and a guarded reset | Often a software role change on the pendant; the cyber review has to confirm the role change actually drops authority |
For the worked ExampleCo CR-12, the fenced configuration emphasises engineering-station authority, recovery-slot integrity and decommissioning credential rotation. The cobot configuration adds vision-input authentication, calibration-data integrity, separation-monitoring tamper testing and a per-operator pendant role-store as first-class concerns.
What assets are we protecting?
Start the risk assessment with assets because robot threats are not all about the same thing. A loss of motion integrity, a compromise of safety configuration, and a takeover of the engineering channel need different controls and different release records.
| Asset | Why it matters | Where it lives |
|---|---|---|
| Motion program and parameters | Integrity failure can change trajectories, speeds, payload limits or workspace bounds | Controller program store, engineering project, backup |
| Safety configuration | Sets workspace limits, speed limits, force limits and stop categories; tampering creates a hazardous situation | Safety controller memory, signed configuration bundle |
| Firmware and boot chain | Update compromise can persist on a controller that runs for fifteen years | Bootloader, A and B firmware slots, signing service |
| Engineering credential | Grants program-load and firmware-write authority | Engineering station, controller user store, pendant accounts |
| Calibration and frame data | Wrong values silently shift tool centre point and produced parts | Controller storage, integrator backup |
| Fleet cloud credential | Connects the cabinet to the maker's update service and remote assist | Cabinet keystore, cloud connector |
| Diagnostic and service bundle | Reveals program names, network names, certificates and crash traces | Controller logs, support portal, internal service tooling |
| User instructions and support date | Drives safe commissioning, update expectations and end-of-support handling | Manual, web manual, support listing |
Where are the main trust boundaries?
For this example, the maker should model at least five environments. The point is not to draw every wire; it is to separate places where the attacker opportunity changes: inside the cabinet, on the pendant link, on the plant network, in the maker backend and on the engineering station.
| Environment | Expected protection | Why it changes likelihood |
|---|---|---|
| Inside the cabinet | Physical access is limited to maintenance, but service media, debug pads and recovery slots exist | Lower remote likelihood, higher consequence if keys are extractable |
| Pendant link | Wired into the cabinet, but the pendant is handled by every operator | Local access is plausible during normal work; default credentials are a common gap |
| Plant network | Shared with cell controllers, MES, OPC UA consumers and engineering stations | A compromised peer can attack discovery, OPC UA or remote-assist channels |
| Maker backend | Internet-facing and shared across the installed fleet | A backend mistake scales from one factory to many |
| Engineering station | Windows or Linux laptop with offline programming software, plugged into the OT lane during commissioning | Often corporate-managed; one of the most common entry points in published research |
The safety stack and the cyber stack are not the same project. They share evidence at specific points; the file has to be clear about who owns which clause.
Which threats should be evaluated first?
This example starts with fourteen product-specific threats. The point is not to be exhaustive; it is to show the level of traceability a maker should be able to defend.
| ID | Threat scenario | Asset at risk | Entry point |
|---|---|---|---|
| R1 | Engineering station pushes a program without authenticating the operator | Motion program | Engineering port |
| R2 | Recovery slot accepts an older or unsigned firmware bundle | Firmware integrity | Recovery mode |
| R3 | Pendant accepts a weak or default password and stays logged in across operators | Engineering credential | Pendant |
| R4 | Default OPC UA endpoint answers anonymously on the plant LAN | Calibration and frame data | Plant network |
| R5 | Safety configuration can be loaded without a signed bundle or out-of-band confirmation | Safety configuration | Safety controller |
| R6 | Service tunnel from the maker cloud stays open after a maintenance session | Fleet cloud credential | Remote assist |
| R7 | Calibration data is changed in storage and the tool centre point shifts silently | Calibration | Controller storage |
| R8 | A crafted EtherCAT or fieldbus frame causes a motion-CPU fault or cycle-time overrun | Motion availability | Fieldbus |
| R9 | USB backup or recovery image can be applied without operator audit | Firmware integrity | Service media |
| R10 | Diagnostic bundle exports program names, certificates or network identifiers | Service data | Support portal |
| R11 | A vulnerability in the RT operating system, fieldbus stack or vision module is not detected during the support period | Firmware components | Supplier advisory gap |
| R12 | Operator role binding survives a customer transfer and the old engineering station keeps writing to the controller | Engineering credential | Decommissioning gap |
| R13 | Programming-runtime parser crashes or executes unsafe content from a malformed project file | Tool integrity | Project import |
| R14 | An integrator combines the arm with a third-party safety PLC whose conformity claim is missing or stale | Supplier conformity | Cell handover |
Then look at the integrator handover separately. Who counts as the manufacturer for the resulting cell, and which records have to move with it.
Owns the arm, controller, safety controller, pendant, programming runtime, signed updates and fleet cloud. Evidence: shipped-product file plus vulnerability-handling process.
Combines arm with safety, vision, fixtures and cell logic. Where the cell ships under the integrator's name, the integrator becomes the cell manufacturer. Evidence: cell-level boundary memo and component due diligence.
Runs the cell, applies updates in maintenance windows, reports issues back. Not a manufacturer. Evidence: applied-advisory log and decommissioning record.
An importer or distributor that sells the robot under its own brand, or substantially modifies it, takes on manufacturer obligations for that offer. Other resellers cross that line only when their change is substantial, such as replacing the update channel, firmware identity, fleet cloud or intended use. Record the trigger and which part of the product file moves with the modified release.
How should the initial risks be ranked?
Use a release-gate ladder so every risk does not receive the same decision:
| Gate decision | Meaning in the example risk register |
|---|---|
| Block release | The product should not ship until the control is implemented and tested. |
| Block unless documented | Release may proceed only if a compensating control, limitation or variant-specific rationale is written and approved. |
| Ship with monitoring | Residual risk can remain, but the file must name the monitoring signal and owner. |
| Transfer to guidance | The maker keeps integrator or operator instructions because the condition depends on the customer cell. |
| Accept | The residual risk is low enough for this example, with rationale retained in the file. |
| ID | Likelihood | Impact | Gate decision | Why |
|---|---|---|---|---|
| R1 | High | High | Block release | Engineering writes are central to robot control |
| R2 | Low | Severe | Block release | Update bypass undermines every future firmware fix |
| R3 | High | High | Block release | A shared pendant is the most common operator surface |
| R4 | Medium | High | Block release | OPC UA misconfiguration is widely reported in real cells |
| R5 | Low | Severe | Block release | Safety configuration is the strictest write authority on the controller |
| R6 | Medium | High | Block unless documented | Service tunnels are useful but need explicit time-boxing and disablement |
| R7 | Medium | High | Block release | Silent shift in tool centre point can produce scrap or worse |
| R8 | Medium | Medium | Block unless documented | Real-time bus stress should be tested; some failures only show in production |
| R9 | Medium | Medium | Block unless documented | USB transfer is normal; the audit record is what changes |
| R10 | Medium | Medium | Ship with monitoring | Support bundles are needed; redaction and consent are the controls |
| R11 | Medium | High | Ship with monitoring | Supplier vulnerabilities are expected during a long support window |
| R12 | Medium | High | Block release | Transfer or resale paths are foreseeable for industrial equipment |
| R13 | Low | High | Block unless documented | Project-file parsers process untrusted content |
| R14 | Medium | Medium | Transfer to guidance | Integrator owns the cell-level conformity claim; the maker provides component evidence |
What design controls change the risk picture?
The control table should be traceable back to the R-IDs, but it should not read like a generic secure-development checklist. For each control, the maker should be able to show the test, design note or operational record that proves the control exists for this exact release.
| Threats | Design control | Evidence the maker should keep |
|---|---|---|
| R1, R3 | Authenticated engineering sessions, per-operator pendant accounts, no shared default credential, time-bound auto-logout | Authentication tests, pendant access matrix, negative tests for unauthenticated writes |
| R2, R9 | Secure boot, signed firmware, monotonic version counter, downgrade rejection, USB audit | Boot-chain evidence, update verification log, USB-import audit sample |
| R4 | OPC UA security profile by default, authenticated endpoints, certificate trust list, service inventory after commissioning | Post-commissioning service scan, OPC UA configuration test |
| R5 | Signed safety configuration, joint review with safety engineer at every cyber-relevant change, out-of-band confirmation for safety-firmware updates | Safety-configuration sign-off, safety-firmware downgrade-rejection test |
| R6 | Time-boxed service tunnels, explicit enablement on the pendant, visible tunnel state, credential rotation | Tunnel disablement test, remote-assist audit log |
| R7 | Integrity check on calibration data, periodic comparison with the integrator baseline, alarm on unsanctioned change | Calibration-integrity test, drift-alarm sample |
| R8 | Fieldbus fuzz testing, watchdog recovery, malformed-frame logging | Fieldbus fuzz report, watchdog recovery test |
| R10 | Diagnostic-bundle minimisation, redaction, operator consent before upload, retention limit | Diagnostic schema, redaction test, support workflow record |
| R11 | Component inventory with named owners for RT operating system, fieldbus stack, vision module and motion CPU; advisory watch and triage | Component register, advisory record, triage decisions |
| R12 | Decommissioning wipe, fleet-cloud unbind, credential rotation on transfer, refurbished-controller checklist | Decommissioning checklist, cloud-unbind audit, wipe verification |
| R13 | Project-file parser hardening, malformed-project test corpus, programming-runtime sandboxing | Parser fuzzing report, import regression tests |
| R14 | Integrator-facing manual with supplier evidence map, joint due-diligence record at handover, advisory routing back to the integrator | Handover memo, integrator advisory record |
What residual risk remains after controls?
After controls, the maker should rerun the assessment rather than mark threats as done. In this example, the supplier-vulnerability path, the integrator handover and the long product life remain actively managed during the support period. The residual risk is acceptable only if the maker can show that monitoring, triage, signed-update delivery, integrator notification and corrective-action processes are actually operating.
| Residual area | Why it remains | Operating evidence |
|---|---|---|
| Long product life | A robot can run for fifteen years or longer; supplier components will receive vulnerabilities throughout | Component advisory watch, support-window statement, end-of-support disclosure |
| Customer cell logic | The maker does not own integrator-written motion programs or cell safety configuration | Boundary memo, secure programming guidance, integrator-facing manual |
| Patch timing | Plants need maintenance windows and validation; some fixes cannot be applied immediately | Security advisory with machine-impact note, mitigation guidance, rollback path |
| Physical service access | Cabinets, pendants and engineering stations remain physically accessible during maintenance | Service-mode constraints, audit sample, debug-lock evidence |
How should fleet cloud advisories route?
The risk assessment above runs on one robot cabinet. The advisory routing runs across hundreds. When the maker fleet cloud serves multiple integrators and multiple operator sites, the question is not "is the cloud secure" but "when a 24-hour vulnerability warning fires, who in the chain hears it and who approves the update window for each site".
| Fleet topology | Who sits between the maker and the end user | What changes for the maker's release file |
|---|---|---|
| Single-site operator, direct from the maker | Maker → operator | The maker advisory routes straight to the operator's maintenance team; the user-notification duty is satisfied by one channel |
| Multi-site operator, central plant engineering | Maker → operator HQ → site engineering teams | The maker advisory routes to the operator HQ contact; the operator decides which sites accept the update and on which maintenance window. The release file should record the operator-HQ contact so the advisory is not stuck at a single site mailbox |
| OEM-managed fleet across many operators | Maker → robot OEM operations → end operators | The maker pushes the advisory to the OEM fleet operations team. The OEM then re-broadcasts to its operator base with site-specific machine-impact notes. The maker still needs a route to impacted users; the OEM is a downstream channel, not a substitute |
| Integrator-managed fleet (system integrator runs the fleet cloud for an SME customer base) | Maker → integrator → SME end users | The maker advisory routes to each integrator that runs a fleet on top of this controller. Integrators that ship under their own brand take on manufacturer obligations for the integrated cell; the maker's advisory feeds into the integrator's own vulnerability-handling process |
| Fleet of fleets (maker cloud federates with OEM and integrator clouds) | Maker fleet ↔ OEM fleet ↔ integrator fleet ↔ end operator | Define in writing which advisory chain is contractual and which is CRA-mandated. The CRA path covers regulatory reporting and user notification; the contractual path adds machine-impact notes, maintenance-window negotiation and rollback co-ordination. The release file should name both |
Release record. A fleet-cloud routing map that names, for each integrator and operator on the connector list, the contact for 24-hour vulnerability warnings, the maintenance-window owner, the rollback authority and the residual advisories still open. Without this map the deadline runs against a missing recipient.
Which validation gates run before release?
Avoid a generic "security reviewed" gate. Use one release-gate inventory with a failure mode, designed control and proof artifact for each decision that can stop the robot shipment.
- G1First-use claim and handoverBlock release
- Failure
Shared factory credentials are not rotated at integrator commissioning.
- Control
Per-device key, forced rotation, pendant-account binding.
- Proof
Commissioning record and pendant access matrix.
- Failure
- G2Exposed services after commissioningBlock release
- Failure
Anonymous OPC UA, FTP, VNC or web admin reachable on the plant LAN.
- Control
Service minimisation and authenticated OPC UA by default.
- Proof
Post-commissioning service scan.
- Failure
- G3Motion and safety authorityBlock release
- Failure
A pendant, engineering station or service tunnel changes safety configuration without an audit.
- Control
Authenticated sessions, signed safety configuration, out-of-band confirmation.
- Proof
Authority-path matrix and safety-configuration sign-off.
- Failure
- G4Update and recovery pathBlock release
- Failure
Recovery slot accepts an unsigned or older bundle, turning updates into a malware channel.
- Control
Secure boot, signed updates, monotonic counter, downgrade rejection.
- Proof
Failed-downgrade test result.
- Failure
- G5Supplier stackShip with monitoring
- Failure
A vulnerability in the RT OS, EtherCAT stack or vision module lands during the support window.
- Control
Component inventory with a named owner, advisory watch, backport readiness.
- Proof
Affected-component triage decision.
- Failure
- G6Decommissioning and resaleBlock unless documented
- Failure
A transferred controller keeps an old role binding, cloud account or stored program.
- Control
Wipe, fleet-cloud unbind, credential rotation, refurbished-controller checklist.
- Proof
Wipe and cloud-unbind verification.
- Failure
Who owns robot development from concept to support?
Lead ownership shifts as the robot moves from product definition to live support. Use this rail to assign one lead, one maintained record and one review gate at each stage while the product changes.
Freeze the boundary before architecture work, freeze the design intent before implementation, freeze the candidate before verification, freeze the decision before release, and keep the release operating through the support period. Incoming reports, supplier advisories, incident outcomes and regression results reopen the next boundary memo, threat list and component register.
Which evidence records belong in the file?
The file should let a reviewer follow the robot decision from product identity to security controls. Each row below should point to a maintained record, not to a folder of disconnected screenshots.
| Evidence area | What to capture for an industrial robot or cobot |
|---|---|
| Product identity | Arm model, payload, reach, controller cabinet, pendant, firmware branches, programming-runtime version, fieldbus options, hardware revisions |
| Intended purpose | Component sale to integrators, complete cobot cell, cleanroom variant, palletising variant or another industrial use |
| Cyber-resilience design file | Motion authority paths, safety-configuration authority, fleet-cloud exposure, plant LAN exposure, threat list and treatment plan |
| Component inventory | Motion CPU, RT operating system, EtherCAT slave stack, safety microcontroller, encoder protocol, gate driver, vision module, programming-runtime libraries |
| Secure defaults | No shared default credential, signed updates, downgrade rejection, OPC UA security profile by default, post-commissioning service inventory |
| Update mechanism | Signed firmware, recovery slot, machine-impact note, customer maintenance-window guidance, rollback decision |
| Vulnerability handling | Disclosure policy, single point of contact, triage workflow, component advisory watch and integrator notification routing |
| User instructions | Secure commissioning, role-store setup, update settings, decommissioning and end-of-support disclosure |
| Traceability and contact | Type, batch or serial information, maker contact details, support-period end date, and a single vulnerability-reporting contact that is not only an automated bot |
What goes in a robot SBOM?
The CRA requires a machine-readable SBOM that identifies the product's components and covers at least top-level dependencies, but it does not name one fixed format yet. Until the Commission specifies more detail, robot makers normally choose CycloneDX or SPDX. The cross-product detail on SBOM mechanics lives in the dedicated SBOM guide; this section covers the robot-specific tree.
A robot release usually ships several digital elements with separate update cycles, not one binary. Two implementation patterns meet the CRA minimum: one product-level SBOM with element-separated sections (each motion-CPU, safety-controller, RT OS and pendant firmware version pinned), or one SBOM per shipped digital element refreshed at each release. Either pattern is acceptable so long as the SBOM is machine-readable and top-level dependencies are covered.
SBOM record: a machine-readable SBOM in CycloneDX or SPDX covering at least top-level dependencies. Recommended robot-maker patterns: one product-level SBOM with element-separated sections, or one SBOM per shipped digital element refreshed at each release. Deeper transitive dependencies are recommended where the build system can produce them. Pair the SBOM with the component advisory-watch record (evidence-map row "Component inventory") so a reviewer can see which library a known vulnerability lands in and which release closes it.
What does the release sign-off check?
Before the robot is released for the EU market, the sign-off should close the same four record folders the SVG below names Q1 to Q4. The full file inventory lives in the evidence map above; this table is only the four release-blocking questions.
| Folder | Release question | Robot-specific evidence pointer |
|---|---|---|
| Q1 Classification rationale memo | Why is this product classified the way it is? | Intended use, sales context, supplied digital elements, integrator versus complete-cell route and the standard-route procedure chosen |
| Q2 Shipped-elements inventory | What exactly is the product? | Arm, controller, pendant, safety controller, programming runtime, OTA service, fleet cloud connector and excluded customer cell systems |
| Q3 Secure-default test pack | What has been secured by default and how will it be updated safely? | No shared default credential, signed updates, downgrade rejection, OPC UA security profile, post-commissioning service inventory, locked debug ports, recovery slot, machine-impact note and maintenance-window suggestion |
| Q4 Vulnerability-handling process | How will vulnerabilities and severe incidents be handled after shipping? | Public contact, disclosure policy, triage workflow, component advisory watch, integrator advisory routing, 24-hour and 72-hour notification readiness, plus final-report evidence |
Release sign-off folders Q1 to Q4
- Q1 Classification rationale memo. Why is this product classified the way it is? Intended use, sales context, supplied digital elements and the standard-route procedure chosen.
- Q2 Shipped-elements inventory. What exactly is the product? Arm, controller, pendant, safety controller, programming runtime, OTA service, fleet-cloud connector and excluded customer cell systems.
- Q3 Secure-default test pack. What has been secured by default, and how will it be updated? No shared default credential, signed updates, downgrade rejection, OPC UA security profile, post-commissioning service inventory and the maintenance-window guidance.
- Q4 Vulnerability-handling process. How will vulnerabilities and severe incidents be handled? Public contact, disclosure policy, triage workflow, component advisory watch and reporting readiness for warnings, notifications and final reports.
Pre-release checks (on the desk before sign-off):
- Each folder is pinned to the exact firmware branch and supplier-component baseline for the release.
- A named owner is in place with 24-hour and 72-hour notification readiness.
- The secure-default test pack covers per-device credentials and the OPC UA security profile.
Sign-off gate: if a record is missing, the release is not signed off.
Declaration record: use the main EU Declaration of Conformity guide for the template and required fields. For a robot release, the product identity should pin the arm, controller cabinet, pendant, firmware branch, supplied options and support-period reference. If the same declaration also covers machinery legislation, name that route in the declaration and keep the robot technical file and machinery safety file aligned.
How does the robot hand off to importer, distributor, integrator and operator?
The release file should make the handoff from robot maker to importer, distributor, integrator-as-manufacturer and end user testable. For robots and cobots, the weak point is usually not the CE mark alone; it is whether the shipment, manual, fleet cloud, OTA service and integrator handover still match the assessed release.
Economic-operator handoff: roles, side checks, adjacent regimes
- 01 Maker. Owns the release pack: declaration, CE, file index, support window and vulnerability contact.
- 02 Importer (pre-market acceptance). Verifies pack, CE, file index, support date and vulnerability contact. Pause shipment if pack, traceability, pendant credential model, fleet-cloud account or update channel is doubtful.
- 03 Distributor (visible due care). Listing CE, supplied docs, operator traceability, support and update statements. Pause listing if it overstates support, hides operators, mismatches the declaration or keeps selling after a known issue.
- 04 Integrator (machine manufacturer). Combines arm with safety, vision and cell logic. Where the cell ships under the integrator's name, the integrator becomes the cell manufacturer. Cell-level boundary memo and component due diligence required before release.
- 05 Operator (end user on the floor). Receives advisories, applies updates in maintenance windows, reports issues back. Not a manufacturer.
Side check A · Optional AR mandate & non-EU reporting. The authorised-representative mandate is optional, not a non-EU obligation. Non-EU makers without a representative use the reporting-endpoint cascade to pick the CSIRT designated as coordinator.
Side check B · New-manufacturer triggers. An importer or distributor that places the robot under its own name or trademark, or that substantially modifies it, becomes the manufacturer for that offer. Any other party crosses that line only when its change is substantial, and then only for the affected part unless the whole product's cybersecurity changes.
Adjacent regimes (each is a separate assessment): Machinery Regulation 2023/1230 from 20 January 2027, ISO 10218-1:2025 safety case, NIS2 for critical-infrastructure operators, AI Act for AI-driven applications.
The rows below are the short version: what to verify, when to pause, when the robot needs a fresh role analysis. The cross-product role-trigger detail (manufacturer, importer, distributor, authorised representative, open-source software steward) sits in Who must comply with the CRA.
Importer acceptance
Verify the declaration, CE control, file index, support-period statement, vulnerability contact, importer identity and destination-language manual. Pause if the pack, traceability, pendant credential model, fleet-cloud account or update channel is doubtful.
Distributor due care
Check visible CE, supplied documents, operator traceability, support and update statements on the listing. Pause if the offer hides operators, overstates support, mismatches the declaration or keeps selling after a known issue.
Integrator as machine manufacturer
An integrator that combines the arm with safety, vision and cell logic becomes the machine manufacturer when the cell ships under the integrator's name. The integrator then exercises component due diligence. The robot maker remains the component manufacturer for the arm, controller and shipped software.
Importer or distributor under own brand
An importer or distributor that places the robot on the Union market under its own name or trademark becomes the manufacturer for that offer. The same applies when an importer or distributor carries out a substantial modification of a robot already placed on the market: branded firmware, a new pendant identity, a new fleet cloud, a new update channel, a new safety configuration or a new intended purpose. The maker's product file is not inherited as an informal promise.
Other reseller after substantial modification
A party that is not the manufacturer, importer or distributor becomes the manufacturer only when it substantially modifies the robot before making it available. The role applies to the affected part, or to the whole product if the change affects cybersecurity as a whole. Treat a new update path, changed intended use or replaced security boundary as a fresh role check.
Authorised representative and non-EU reporting
A manufacturer may appoint an authorised representative by written mandate; it is a choice, not a non-EU obligation. Reporting endpoint selection is triggered by a different fact: no main establishment in the Union. A manufacturer in that position uses the cascade in the CRA: authorised representative, importer, distributor, then highest user base. A non-EU manufacturer that did not appoint a representative starts with the importer step.
Adjacent-regime check
Machinery Regulation 2023/1230 (from 20 January 2027) and ISO 10218-1:2025 cover the safety case. NIS2 applies if the operator is a critical-infrastructure entity. AI-Act applies to vision or AI applications. Each regime is a separate assessment.
Frequently Asked Questions
Are industrial robots and cobots Important or Critical under the CRA?
Industrial robots and cobots are not named in the CRA Important-product list or the Critical-product list. The planning assumption is the default route. The route only moves to Important if a listed function dominates the offer, for example a robot sold mainly as a firewall gateway, a network-management system or a hardened controller built around a tamper-resistant microcontroller. There is no robot category that automatically forces the Critical route.
Classification record: a one-page memo for the exact arm and controller variant that names the intended use, the supplied digital elements and the route rationale.
Does a 6-axis robot arm need a Notified Body?
Not for a default product. Robots and cobots are not in the Important-product list today, so the conformity route runs through the default procedure and the manufacturer chooses among internal control, EU-type examination plus module C, full quality assurance, or an applicable European cybersecurity certification scheme. A notified body is involved only in the modules the maker actually selects: internal control is fully in-house, while the other modules involve a notified body. The "standards fully applied" precondition belongs to the Class I fallback and would only apply if a future update added a robot or cobot sub-product to the list.
Conformity route record: a short memo that names the chosen procedure, the standards relied on, any gaps and the rationale; if the Important-product list is ever amended to include a robot sub-product, the memo records whether the Class I conditional fallback applies for the missing area.
Does the Machinery Regulation already cover the cyber side?
The Machinery Regulation 2023/1230 applies from 20 January 2027 and carries safety-related cybersecurity requirements for machinery, including protection against corruption and safety-control reliability. The CRA is the cyber-resilience layer on top: it covers the wider security posture, the vulnerability-handling process and the support-period obligation. Treat the safety file and the cyber file as two threads of the same product folder, not two separate compliance projects.
Recheck trigger: any change to safety-relevant firmware, the safety configuration model or the update channel reopens both threads.
Who is the manufacturer under the CRA when an integrator builds the cell?
The robot maker remains the manufacturer for the arm, controller, safety controller and shipped software. The integrator becomes the machine manufacturer under the Machinery Regulation for the resulting cell. When the cell is placed on the market as a product under the integrator's name, the integrator may also become the manufacturer for cyber-resilience purposes for the combined product and must exercise due diligence on each integrated component. Both roles can coexist in the same shipment.
Boundary record: a written handover memo that names which artifact moves with the cell and which stays with the robot maker.
Does a cobot for SME workshops fall in the same category as a fenced robot?
The category is the same: an industrial robot under the cyber-resilience layer, not a smart-home product. The risk profile differs because a force-limited cobot collaborating with humans relies more heavily on safety-rated force, speed and separation monitoring, which makes the safety-versus-cyber overlap tighter. The release file should reflect that overlap, not change category.
Risk-assessment record: a cobot-specific entry that names the collaborative operation mode and the cyber events that could disable it.
What if the robot ships with vision, AI or remote teleoperation?
A bundled vision system or AI module is a supplied digital element and stays inside the product boundary. Remote teleoperation, if supplied by the maker, is also inside the boundary and needs explicit authority, time-boxing and audit. An AI-based application may also fall under a separate regime; do not collapse those assessments into one.
Boundary record: name each bundled element, its owner, its update path and its excluded counterparts.
Does cloud fleet management change the product boundary?
Cloud fleet management does not by itself change the route. If the maker supplies the fleet cloud and the controller would not perform a function without it, treat that cloud as part of the boundary, the evidence and the risk assessment. The classification still follows the controller's core function.
Boundary record: a cloud-dependency map showing which fleet services are supplied with the robot, which functions fail without them, what data they process and which systems are outside the maker's offer.
What should a robot CRA risk assessment include?
Start with the product boundary, not the legal label. For a complete cobot, include the arm, controller cabinet, pendant, safety controller, programming runtime, fleet cloud connector, OTA service, vulnerability contact and decommissioning path. Then list the assets, trust boundaries, threats, likelihood, impact, initial decision, controls, evidence and residual risk.
Risk-assessment record: asset inventory, trust-boundary map, threat list, initial decisions, treatment plan, residual-risk rationale and the named owner for each post-market signal.
How specific should the threat model be for a robot?
Specific enough that an engineer can test it. "Unauthorised motion" is too vague. A useful entry is closer to: "A pendant left logged in lets an operator load a program that exceeds the workspace bounds set by the safety configuration." That points to the asset, entry point, attacker opportunity, control and test evidence.
Test artifact: one threat ticket per entry, linked to the pendant, fleet-cloud, update, fieldbus, calibration, support-export or decommissioning test that proves the control works.
Which robot risks should be assessed first?
Start with the paths that can change motion or the safety configuration: pendant authority, engineering-station write authority, signed updates, the recovery slot, the safety-firmware path, OPC UA exposure and the service tunnel. Those are the paths most likely to change the design before release.
Release check: a pre-release checklist covering motion authority, safety-configuration authority, exposed services, supplier advisory monitoring, decommissioning and integrator handover.
What is a good example of a robot risk entry?
Example: "R2: the recovery slot accepts unsigned or older firmware bundles." Initial likelihood may be low, but impact is severe because a broken recovery path can compromise the fleet for many years. The control is secure boot, signed recovery images, monotonic version checks, rollback policy and downgrade-rejection tests. The evidence is boot-chain design, update verification logs and a failed-downgrade test attached to the release record.
Test artifact: boot-chain design note, signed-update verification log, rejected-downgrade test and recovery-slot test result for the exact firmware build.
When should the risk assessment be updated?
Update it whenever the released state changes in a way that affects trust: a new pendant accounts model, a new fieldbus option, a fleet-cloud change, a safety-firmware change, a programming-runtime change, a new vision module, a debug-port behaviour change or a new decommissioning path. A release note is not enough if the change reopens an authority path. The earlier date matters here: reporting obligations apply from 11 September 2026 even though the rest of the CRA only takes full effect on 11 December 2027. The assessment, the disclosure policy and the named single point of contact should be working before the reporting deadlines start running.
Recheck trigger: any change to authority, update, exposed services, supplier components or decommissioning reopens the boundary and the risk assessment.
What is the first evidence item a robot maker should create?
Start with a short classification-and-boundary memo for the exact variant: arm model, payload, reach, controller cabinet, pendant, fieldbus options, programming runtime, fleet cloud connector, intended use and excluded customer systems. The memo should name the route rationale and the support window.
Classification record: a one-page memo that the risk assessment, conformity-route choice, file index, importer pack and support-period statement can all reference.
What if a vulnerability is found after release?
The CRA requires the manufacturer to take corrective measures immediately when the product or the supporting processes are not in conformity, and to withdraw or recall the product where appropriate. Operationally, the file needs readiness for the reporting sequence: a 24-hour early warning for an actively exploited vulnerability, a 72-hour vulnerability notification, a final report once the corrective or mitigating measure is available, and user notification. For a robot, the corrective measure is usually a signed firmware update with a machine-impact note and a maintenance-window suggestion; a recall is reserved for cases where the controller cannot be safely updated in the field.
Recall record: a corrective-action note that names the affected serials, controller firmware branches, integrators and distributors, the mitigation steps, the signed update artifact, the user advisory text and the CSIRT notification reference.