CE Marking for Robot Cells: What Integrators Actually Need
A CE-marked robot arm is not a CE-marked cell. The integrator owns the risk assessment, and getting it wrong costs 2-3x to retrofit.
A robot arm arrives on your dock with a CE mark on the nameplate. Your project manager sees that mark and assumes the cell is compliant. It is not. The arm carries a Declaration of Incorporation - not a Declaration of Conformity - and that single distinction is the root cause of most compliance failures I saw during a decade integrating lines. The integrator must issue a fresh CE Declaration of Conformity for the complete workcell, backed by a full ISO 10218-2 risk assessment. Skip that step and the liability for every incident transfers entirely to you.
This is not legal advice. Consult an accredited notified body before finalising any conformity documentation.
What is the difference between a Declaration of Incorporation and a Declaration of Conformity?
The manufacturer of a robot arm ships what the Machinery Directive classifies as “partly completed machinery.” They issue a Declaration of Incorporation (DoI), which explicitly states the machine must not be put into service until the final machinery into which it is incorporated has been declared conformant. In plain terms: the CE mark on the arm means the arm alone was built to certain standards. It says nothing about how you mount it, fence it, program it, or what tooling you bolt onto the end.
When you deliver a complete robot cell to an end customer, you become the manufacturer of that system in the eyes of EU law. You must issue a Declaration of Conformity (DoC), affix your own CE mark to the cell, and retain the technical file - including the full risk assessment - for ten years.
The failure mode is predictable: an integrator receives a CE-marked UR10e or a FANUC CRX, copies the arm’s DoI into the project file, and ships. An auditor or an incident investigator asks for the cell-level DoC. There is none. The integrator is now fully exposed.
What does ISO 10218-2 actually require?
ISO 10218 is split into two parts. Part 1 covers robot manufacturers. Part 2 - published in its 2011 edition and substantially revised in 2025 - is what integrators and end-users work from. It specifies safety requirements for the design and construction of robot systems and integration of industrial robots.
The 2025 revision is significant: it absorbed the collaborative-workspace requirements that were previously spread across ISO 10218-1, ISO 10218-2, and the technical specification ISO/TS 15066. That means the separate ISO/TS 15066 document you may have used for cobot risk assessments is no longer the primary reference. Everything now lives in ISO 10218-2:2025, and the methodology for calculating contact forces, approach speeds, and protected zones has been updated accordingly.
For integrators, the core deliverables under Part 2 are:
- A systematic risk assessment covering all hazards across the full operating lifecycle (installation, operation, maintenance, foreseeable misuse)
- Documented risk reduction measures with verification evidence for each
- Performance Level determination for each safety function, per ISO 13849-1
- A technical file that can be reconstructed and audited
- The signed Declaration of Conformity
The risk assessment is not a checkbox. It is a living document that must reference specific hazard scenarios, the chosen safeguarding measures, and the residual risk after mitigation. Auditors distinguish immediately between a genuine assessment and one copy-pasted from the robot manufacturer’s generic documentation.
What are the most common audit failures?
Based on what I saw before I started writing about this instead of living it, the failure list is short but consistent.
Incomplete risk assessment. The assessment covers normal operation but not maintenance access, tool-change procedures, or jam-clearing with the cell in a degraded state. Maintenance is where most injuries happen.
Missing Performance Level documentation. The integrator specifies a safety-rated monitored stop but cannot produce the PL calculation showing the combination of sensors, logic, and actuators meets the required PL. The safety function exists in hardware; the paper trail does not.
Wrong document on file. The DoI from the robot manufacturer is filed as if it were the cell’s DoC. This is the single most common finding in the cells I’ve seen reviewed post-incident.
Undocumented modifications. The cell was modified after initial commissioning - a new gripper, a different payload, an updated end-of-arm tool - without triggering a reassessment. Each modification that changes the risk profile restarts the conformity process.
Collaborative workspace misconfiguration. The integrator relied on the cobot’s rated speed limits without applying the force and pressure limits from the standard to the actual tooling and payload in use. More on this below.
Does a cobot need guarding?
The short answer: it depends on the application, and the standard is explicit that the robot’s collaborative rating does not exempt the cell from guarding requirements.
The longer answer is that “collaborative” describes an operating mode, not a robot category. Cobots in our database range from 3 kg to 35 kg payload. They achieve safety through one or more of four collaborative functions defined in ISO 10218: safety-rated monitored stop, hand-guiding, speed and separation monitoring, or power and force limiting.
Power and force limiting - the mode that allows physical contact without injury - has strict force and pressure thresholds per ISO 10218-2:2025 (updated from the ISO/TS 15066 values). Those thresholds apply to the total end-effector assembly: the robot flange, the tool changer, the gripper, and whatever the gripper is holding.
A cobot running at 250 mm/s with a 2 kg gripper gripping a 1 kg part may stay within contact-force limits. The same cobot at the same speed with a 6 kg welding torch or a sharp edge tool does not. The physics do not care about the label on the arm.
RoboDK’s safety documentation summarises the practical point cleanly: cobot safety is contingent on the entire application, not the robot model. High speed, heavy payloads, or sharp tooling require conventional safeguarding regardless of the arm’s collaborative rating.
The “no fence needed” claim that some vendors circulate is a marketing simplification. It may be accurate for a specific, low-payload, low-speed application with verified force limits. It is not a general property of cobots. Apply the risk assessment to your actual cell.
What happens when you import a robot without CE marking?
This comes up repeatedly with robots from Chinese manufacturers, where the product may not carry CE marking, or carries marking that was not issued through an accredited process.
Under EU Machinery Directive 2006/42/EC - and its successor, EU Machinery Regulation 2023/1230, which takes effect from January 2027 - importing machinery without valid CE marking and placing it on the market transfers full manufacturer responsibility to the importer. You must perform a conformity assessment, compile the technical file, conduct the risk assessment, and issue the DoC as if you had built the machine yourself.
This is not a theoretical risk. Customs authorities can stop machinery at the border. Market surveillance authorities can order withdrawal from service. And if an incident occurs with an improperly certified machine, the liability chain runs directly to the entity that placed it on the market.
The practical implication: if you are integrating a robot arm that lacks credible CE documentation, budget for the conformity work upfront. The cost of a proper assessment is a fraction of the cost of a retrofit after an incident or regulatory action.
| Standard | What it covers | Who is responsible |
|---|---|---|
| ISO 10218-1:2023 | Robot design and manufacture (the arm itself) | Robot manufacturer |
| ISO 10218-2:2025 | Integration, workcell design, installation, commissioning | Integrator / system builder |
| ISO 13849-1:2015 | Performance Level calculation for safety functions | Integrator (PL verification) |
| IEC 62061:2021 | Functional safety for SIL-rated safety functions (alternative to 13849-1) | Integrator |
| EU Machinery Regulation 2023/1230 | Placing machinery on the EU market (replaces 2006/42/EC, effective Jan 2027) | Importer / integrator |
See EVS International’s 2026 overview and Grab a Robot’s ISO standards guide for additional detail on the standard revision timeline and transition requirements.
Compliance checklist for integrators
Before you ship a robot cell, verify each item:
- Robot arm DoI is in the technical file - confirmed it is a DoI, not a DoC
- Cell-level risk assessment completed under ISO 10218-2:2025, covering all lifecycle phases
- Collaborative workspace assessed using 10218-2:2025 force/pressure limits (not legacy ISO/TS 15066 values if the 2025 edition applies)
- Every safety function has a documented Performance Level calculation (ISO 13849-1 or IEC 62061)
- Safeguarding verified for the actual tooling and payload, not the robot’s rated payload
- Modification procedure documented: any post-commissioning change triggers reassessment
- Technical file complete and retained (minimum 10 years under current directive; confirm under 2023/1230 for post-2027 deliveries)
- Declaration of Conformity signed, dated, references the correct standards, lists all applicable directives
- CE mark affixed to the cell (not just the arm)
- UKCA documentation prepared separately if the cell ships to Great Britain
The cost of getting it wrong
Retrofitting a non-compliant cell costs 2-3x the original safeguarding budget, in my experience. Mechanical guarding changes require new fixtures and re-validation. Safety function changes require new PL calculations and potentially new hardware. Everything needs re-testing and re-documentation.
The risk assessment is not overhead. It is the cheapest engineering task in the project relative to the cost of skipping it.
Browse the full robot database to check specifications for arms you are integrating, and review the cobot category if you are evaluating collaborative operating modes for your application.