Robotics & Embedded Security Testing
Xium Labs tests robots, machinery and the embedded systems inside them the way an attacker would approach them: by hand, with proof of exploitation, and with the physical consequences held in view throughout. We are a UK security lab that also builds AI and production software, so the same team can read a controller’s firmware, abuse a fleet management API and probe the autonomy stack sitting on top of both. The evidence you get is written to go into a technical file, not just an inbox.
What robot and embedded security testing covers
A robot is not a web application with wheels. It is a safety-related control system, a stack of firmware, an industrial network, usually a radio link, a cloud fleet backend and, increasingly, a model deciding what moves next. A weakness in any one of those layers can put a machine into a state its safety case never anticipated.
Two things separate this from a conventional penetration test. The impact model is physical, so a finding is graded on whether it can defeat a protective function, move an axis or reach a whole fleet. And the output has to survive a technical file, so every finding is mapped to the requirement it bears on.
Testing is manual work supported by automated tooling, not a tool scan. Every finding carries a severity rating, proof of exploitation and reproduction steps, and every engagement includes a free re-test within six weeks.
Who this is for
We work with the people who build, connect and answer for machines: robotics manufacturers and OEMs building industrial arms, collaborative applications, service and humanoid platforms, drones and autonomous mobile robots; machine builders working back from 20 January 2027; systems integrators, who inherit the security posture of everything they connect; retrofit and modernisation specialists; and compliance teams who need defensible evidence inside a technical file or a tender. If you are answering one of those with no test evidence to point at, that is the gap this service fills.
What EU and UK law now requires of robotics manufacturers
Four EU instruments now reach directly into how a robot, a machine or an embedded controller is engineered, and two more reach you through your customers. All of them ask whether you can evidence that the machine resists interference, and keep doing so for years after it leaves your factory.
Regulatory position last verified 30 September 2026.
EU Machinery Regulation (EU) 2023/1230: cybersecurity inside the safety requirements
Regulation (EU) 2023/1230 applies from 20 January 2027, the day Directive 2006/42/EC is repealed. Worth checking against anything else you read: the original Official Journal text said 14 January 2027, corrected by the corrigendum at OJ L 169, 4 July 2023. Machinery placed on the market under the Directive beforehand may still be made available, but nothing new may be certified under it.
Interference is now treated as a source of mechanical harm. Two essential health and safety requirements in Annex III carry the weight.
- 1.1.9, protection against corruption. Connecting another device, including a remote device that communicates with the machinery, must not lead to a hazardous situation. Hardware, software and data critical for the machine’s compliance with the essential requirements must be identified as such and adequately protected against accidental or intentional corruption. The machine must identify the software installed on it that is necessary to operate safely and supply that information at any time in an easily accessible form. And it must collect evidence of legitimate or illegitimate intervention, in the hardware and in the software or its configuration.
- 1.2.1, safety and reliability of control systems. Control systems must withstand, where appropriate to the circumstances and the risks, intended and unintended external influences, including reasonably foreseeable malicious attempts from third parties leading to a hazardous situation. Point (f) adds a five-year tracing log of intervention data and of safety software versions uploaded after the machine is placed on the market.
Annex I Part A, which requires one of the notified body procedures in Article 25(2), now includes safety components and embedded systems with fully or partially self-evolving behaviour using machine learning approaches ensuring safety functions. Self-assessment is not available for those.
EU Cyber Resilience Act (EU) 2024/2847: the reporting clock is already running
Regulation (EU) 2024/2847 covers products with digital elements: hardware and software made available on the EU market whose intended or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network. Robot controllers, PLCs, HMIs, fieldbus modules, edge gateways and embedded firmware are inside that definition, and robots are not named in the adopted Annex III or Annex IV, so classification turns on core functionality.
It entered into force on 10 December 2024 and arrives in tranches. Chapter IV applied from 11 June 2026. Article 14 reporting applied from 11 September 2026 and is live now. Everything else, including the Annex I essential requirements, the risk assessment, technical documentation, conformity assessment and CE marking, applies from 11 December 2027.
Article 14 runs two parallel tracks, one for actively exploited vulnerabilities and one for severe incidents. Each begins with an early warning within 24 hours of becoming aware and a fuller notification within 72 hours, submitted simultaneously to the CSIRT designated as coordinator and to ENISA. A vulnerability then needs a final report no later than 14 days after a corrective or mitigating measure is available; a severe incident, one within a month of the 72-hour notification. Under Article 69(3) that duty reaches products already on the market, so a robot shipped in 2019 is inside it today.
Two obligations are underestimated. Under Article 13(8) the support period must reflect how long the product is expected to be in use and is at least five years, so for a machine with a fifteen-year service life five years is a floor, not an answer. Under Article 13(9) each security update must then stay available for at least ten years after issue.
EU AI Act and the Digital Omnibus: the machinery date moved to 2 August 2028
The AI Act, Regulation (EU) 2024/1689, was amended on 27 July 2026 by Regulation (EU) 2026/1744, the Digital Omnibus on AI. Most published robotics compliance material still carries the superseded dates.
High-risk obligations for standalone Annex III systems now apply from 2 December 2027. High-risk AI that is, or is a safety component of, a product covered by Annex I, the machinery case, now applies from 2 August 2028 rather than 2 August 2027. The Omnibus also moved the Machinery Regulation from Section A to Section B of the AI Act’s Annex I, so only Article 6(1), Article 60a and Articles 102 to 112 apply directly; the substantive requirements are to arrive as delegated acts adding AI health and safety requirements to Machinery Regulation Annex III, applying by 2 August 2028.
None of that moves the Machinery Regulation’s own 20 January 2027 date or its Annex I Part A. A learned safety function is in scope under machinery law from January 2027, whatever the AI Act timetable says.
Radio equipment, NIS2 and the UK position
Radio equipment. Commission Delegated Regulation (EU) 2022/30 activated the cybersecurity requirements in Article 3(3), points (d), (e) and (f) of the Radio Equipment Directive from 1 August 2025. It is repealed with effect from 11 December 2027 by Delegated Regulation (EU) 2026/339, so equipment placed on the market between 1 August 2025 and 10 December 2027 stays subject to it. EN 18031-1, -2 and -3 were cited in January 2025 with restrictions, so the presumption of conformity they give is partial.
NIS2. Directive (EU) 2022/2555 lists manufacture of machinery and equipment, NACE Rev. 2 division 28, in Annex II, making an in-scope manufacturer an important entity, though transposition is uneven so your Member State’s law binds you. The part that reaches your sales cycle is Article 21(2)(d), elaborated by Article 21(3): your customers must manage supply chain security, including their suppliers’ secure development procedures.
The UK. Great Britain has not adopted Regulation (EU) 2023/1230, and the Supply of Machinery (Safety) Regulations 2008 contain no equivalent of 1.1.9 or of the malicious-third-party wording in 1.2.1. CE marking is recognised in GB with no announced end date, and SI 2026/867, in force 20 January 2027, lets machinery CE marked under the EU Regulation onto the GB market. Government has said it will introduce similar measures while ruling out full alignment, with no date set. Northern Ireland is different: the EU Regulation applies there directly.
What we test inside a robot or machine
Scope is agreed in writing before anything starts and follows your architecture rather than a fixed checklist. The organising principle is a chain: an attacker needs a way in, a way to persist, and a way to reach something that matters. We test each link, then whether the chain joins up.
What you get out of it
Evidence for a technical file
A dated, independent report naming the exact build tested, mapped to the requirements you actually have to satisfy.
Physical impact, not just data loss
Findings graded on whether they can defeat a protective function, move an axis or reach a whole fleet.
One test, several files
The same engagement feeds your Machinery Regulation file, your CRA documentation, a tender annex and a customer questionnaire.
A software bill of materials that holds up
Generated from the shipped firmware image rather than your build manifest, with a triaged vulnerability position.
Free re-test within six weeks
We re-test what you fixed and reissue the report, so the version you hand over is the closed-out one.
Fixed quote after a free scoping call
A written scope and a fixed price before any work starts. No open-ended day rates, no surprise change notes.
The surfaces we cover
Hardware and debug interfaces
UART, JTAG and SWD access, flash and memory extraction, the secure boot chain, hardware roots of trust and tamper response.
Firmware and the update path
Hardcoded secrets and fleet-wide keys, binary hardening, signature verification, anti-rollback, and whether a downgrade to a known-vulnerable image is possible.
Middleware and control networks
ROS 2 and DDS, Modbus TCP, PROFINET, EtherCAT, EtherNet/IP, CAN and CANopen, OPC UA and MQTT, and whether segmentation actually holds.
Remote access and radios
Teleoperation and vendor support tunnels, SSH and VNC exposure, Wi-Fi, Bluetooth and BLE provisioning, cellular, and what happens when the link drops.
Safety-related control systems
Whether safety parameters, zones and limits can be changed without authority, whether a stop can be delayed or its indication suppressed, and whether interventions are recorded.
Perception, AI, cloud and apps
Sensor spoofing, model integrity and the model update path, prompt injection where a model plans, fleet APIs, tenant and device isolation, provisioning secrets and the operator app.
How findings map to the requirements you have to satisfy
Every finding is written against the requirement it bears on, so the report can go into a technical file, a tender annex or a customer questionnaire without being rewritten. Regulatory position last verified 30 September 2026.
| Requirement | What we test | What you get |
|---|---|---|
| Machinery Regulation Annex III 1.1.9, protection against corruption: connecting another device must not lead to a hazardous situation | We connect the unexpected device on every reachable interface, including remote-access paths, and observe what the machine does | Per-interface verdict on whether a connection produced a hazardous state, with proof of exploitation and reproduction steps where it did |
| Annex III 1.1.9: compliance-critical software and data adequately protected against accidental or intentional corruption | Attempted modification of compliance-critical parameters, configuration and safety software, on the fieldbus and through engineering interfaces | Requirement-by-requirement statement of what held and what did not, with the modification method documented |
| Annex III 1.1.9: the machine must identify the software necessary to operate safely and supply that information at any time | Whether the on-machine software inventory exists, is complete against the shipped image, and can be read without special tooling | Comparison of the machine’s own declared software inventory against the binary composition of the shipped firmware |
| Annex III 1.1.9: collect evidence of legitimate or illegitimate intervention in hardware and in software or its configuration | We intervene, then check whether the record exists, whether it can be erased or forged by the same compromise, and whether anyone would see it | Intervention log assessment naming each recorded and unrecorded action, with the suppression or erasure method where one worked |
| Annex III 1.2.1: control systems withstand reasonably foreseeable malicious attempts from third parties leading to a hazardous situation | Attacks on remote access, teach pendants, engineering workstations and the OPC UA, MQTT and ROS 2 surfaces through which the cell is reached | Attack paths from each entry point to the control plane, with exploitability judgement and the physical consequence reached |
| CRA Annex I Part I: made available without known exploitable vulnerabilities, with a secure by default configuration | Binary composition analysis against the shipped image, reachability triage of identified components, and review of the as-shipped configuration | Triaged vulnerability list distinguishing reachable and exploitable from present but unreachable, plus the gap between documented and shipped defaults |
| CRA Annex I Part II point 1: a software bill of materials in a commonly used, machine-readable format covering at least top-level dependencies | SBOM generated from the shipped firmware image and reconciled against your build manifest | Machine-readable SBOM plus a reconciliation showing components present in the product but absent from the manifest |
| CRA Annex I Part II: effective and regular security testing, and a working coordinated vulnerability disclosure route | The disclosure and remediation chain end to end, and whether a finding reaches the right engineer, is triaged and shipped | Dated report plus a dated re-test report within six weeks confirming which findings were actually remediated |
| CRA Annex I Part I: secure update mechanism, and Annex III 1.1.9 protection of safety software against corruption by update | Signature verification, anti-rollback, update transport and certificate validation, bootloader and secure boot chain, and downgrade to a known-vulnerable image | Firmware trust chain assessment showing where the chain holds and where it breaks, with the bypass method documented |
| IEC 62443-4-2 component requirements at the capability security level you are targeting | Identification and authentication, use control and privilege separation, system integrity, secrets handling, segmentation enforcement, logging, and behaviour under malformed or high-volume traffic | Per-requirement assessment of the component capability level we could substantiate, and each control that failed |
| IEC TS 63074 and ISO 13849-1: security aspects affecting a safety-related control system | Every path by which a safety function’s assumptions can be falsified: parameter modification, logic replacement, safety network configuration abuse, diagnostic suppression | Safety-impact annex naming each affected safety function and the mechanism that could defeat it, written for your functional safety engineer as an input to their assessment, not a PL or SIL verification |
| UK GDPR Article 32(1)(d): regularly testing the effectiveness of technical and organisational measures | Protection of personal data the machine handles, most often camera and sensor imagery, operator identity and badge or biometric access data, in transit, at rest and in logs | Findings framed to Article 32’s appropriate-measures test, usable directly in a DPIA |
Standards and requirements we map findings to
Findings are mapped to the references your buyers, auditors and notified bodies already use: Machinery Regulation Annex III 1.1.9 and 1.2.1; Cyber Resilience Act Annex I Parts I and II; IEC 62443-4-1:2018, 62443-4-2:2019, and 62443-3-2:2020 and 62443-3-3:2013 for a cell; IEC TS 63074:2023; ISO 10218-1:2025 and ISO 10218-2:2025; ISO 3691-4:2023 for AGVs; EN 18031 for radio equipment; the OWASP Firmware Security Testing Methodology, IoT Security Verification Standard, MASVS, API Security Top 10 and LLM Top 10, with MITRE ATLAS and ATT&CK for ICS; and UK GDPR Article 32(1)(d).
One caution, because this is routinely overstated. No harmonised standard has yet been cited in the Official Journal under either the Machinery Regulation or the Cyber Resilience Act, so nothing available today gives you a presumption of conformity under those instruments. EN ISO 10218-1:2025 and EN ISO 10218-2:2025 were cited in September 2026, but under Machinery Directive 2006/42/EC, and that route closes when the Directive is repealed. The draft prEN 50742, which introduces safety-related security levels SRSL 0 to SRSL 3 and accepts the IEC 62443 family as an equivalent route, confers nothing yet. The one presumption that does exist for 1.1.9 and 1.2.1 is Article 20(9), for machinery certified under an EU cybersecurity certification scheme adopted under Regulation (EU) 2019/881.
How this fits with your safety assessor and notified body
Security testing sits alongside two other workstreams, and the division of labour is worth stating up front so the scope of each is clear.
- Conformity assessment. Where Annex I Part A of the Machinery Regulation routes a product through one of the Article 25(2) procedures, a designated body carries that out. What we produce is the security evidence that goes into the technical file they review, written so it can be read by someone who was not in the room.
- Functional safety. A Performance Level under ISO 13849-1 or a Safety Integrity Level under IEC 62061 rests on architecture, diagnostic coverage, failure-rate data and a defined validation process, and your safety assessor determines it. What we test is whether an attacker can falsify the assumptions that argument rests on, which is the question ISO 13849-1 hands to ISO/TR 22100-4 and IEC TS 63074 rather than answering itself. The two pieces of work are complementary: a protective function that a remote attacker can disable has a gap no failure-rate calculation will surface.
- Your declaration of conformity stays yours to sign. Our job is to make sure the security evidence behind it holds up to scrutiny.
What you receive
- A technical findings report: every finding with a severity rating, proof of exploitation, reproduction steps, the affected component, hardware variant and firmware version, and remediation guidance for the engineer who has to act on it. Safety-relevant findings are separated out, and anything established by analysis rather than demonstrated exploitation is labelled as such.
- A statement of scope and methodology for your technical file: what was tested, on which build and configuration, the dates, the tools, what was excluded and why, and a mapping of findings to the instruments and standards in scope.
- A software bill of materials generated from the shipped firmware image in a commonly used, machine-readable format, reconciled against your build manifest, with a triaged vulnerability position rather than an alert dump.
- A shareable summary stating coverage and the remediation position, without exposing unfixed detail, a developer debrief call, and a free re-test within six weeks with an updated report confirming what has actually been closed.
How an engagement runs
- A free scoping call, mapping the product, its interfaces, the standards you work to and the date you are working back from.
- A fixed quote against a written scope, stating deliverables, mapping tables, the test window and the rules of engagement, including what may and may not be done to a machine that can move.
- Threat modelling against your safety case, with the paths we will test ranked by consequence and the paths we are not testing listed with reasons.
- Testing, with a same-day warning on anything critical, then a draft report and a factual accuracy review.
- A developer debrief, then a free re-test within six weeks and an updated report.
Safety-relevant testing runs against a rig, a spare unit, a digital twin or a guarded cell with nobody in reach, under written sign-off from your named competent person and with an agreed stop signal either side can use. Where a live line is the only target, the scope reduces to non-interfering tests and the report says which attacks were not attempted.
What drives the cost
Robot and embedded engagements vary far more than web application tests, so a published price would mislead. These are the variables that move the number.
- The number of hardware variants. Two controllers on different silicon are two pieces of work; two enclosures around one board are not.
- Whether firmware and source code are available. Source access shortens the engagement and deepens it at the same time.
- The number of interfaces and protocols in scope. Wi-Fi, BLE, cellular, CAN, Modbus, PROFINET, EtherCAT and OPC UA are each separate work.
- Whether a sample can be shipped to us or testing must happen on site inside maintenance windows.
- Whether the fleet backend, cloud platform and companion app are in scope, and how many requirement mappings the deliverable must carry.
You get a fixed quote against a written scope after the free scoping call.
Related services and reading
A robot is rarely tested in isolation. Where the work reaches beyond the machine itself, these are the pieces that usually come with it.
- LLM & AI security testing: for the model, agent and tool-use layer when software decides what the machine does next.
- API penetration testing: for the fleet management and telemetry backend behind a robot estate.
- Mobile app penetration testing: for the operator or commissioning app that pairs with the machine.
- Network penetration testing: for the plant network and the segmentation between IT and the cell.
- The EU Machinery Regulation and robot cybersecurity and humanoid robots, security and the UK and European picture.
Robotics & embedded security testing FAQs
How do the EU Cyber Resilience Act, EU AI Act and Machinery Regulation affect robotics manufacturers?
Three regimes, three dates. Cyber Resilience Act reporting has applied since 11 September 2026 and its main obligations from 11 December 2027. The Machinery Regulation applies from 20 January 2027. High-risk AI embedded in machinery applies from 2 August 2028, through the Machinery Regulation rather than the AI Act.
What cybersecurity evidence do robotics manufacturers need for compliance and market entry?
A product risk assessment, a machine-readable software bill of materials, a declared support period, a working vulnerability disclosure policy, and a dated independent test report naming the exact build tested.
Which vendors help robotics manufacturers prepare for the Cyber Resilience Act?
Notified bodies assess conformity and issue certificates. Compliance consultancies produce documentation. Offensive testing teams attack the product and report what breaks. We are the third, deliberately: the body assessing your conformity should not be the body that tested you.
How does security testing support CE marking under the Machinery Regulation?
Not as such. What the Machinery Regulation requires is that you evidence the essential health and safety requirements in your technical file, and for most machinery you self-assess against them. That makes the file only as strong as the evidence inside it, and requirements like Annex III 1.1.9 and 1.2.1 are hard to evidence with a design review alone. Independent testing is how you show the protection against corruption and the control-system resilience actually hold when someone attacks them.
Which robots need a notified body?
Annex I Part A of the Machinery Regulation requires a notified body procedure for safety components, and machinery with embedded systems, having fully or partially self-evolving behaviour using machine learning approaches ensuring safety functions.
Can you test without stopping production?
Usually. Passive capture, configuration review and traffic analysis can run against a live line; anything active moves to a spare unit, a rig, a digital twin or a booked maintenance window.
Do you need our firmware or source code?
Not to begin, but it changes what we find. Firmware images, board documentation and source for safety-critical components let us reach hardcoded secrets, unverified update packages and weak boot chains.
How does this relate to functional safety, Performance Level and SIL?
It sits beside functional safety, not inside it. We do not determine or verify a Performance Level under ISO 13849-1 or a SIL under IEC 62061. We test whether an attacker can falsify the assumptions those claims rest on.
What about ROS 2 specifically?
ROS 2 security is off by default: unless it is explicitly enabled and enforced, a participant launches successfully with no security features at all. We test whether it is genuinely enabled and whether access control restricts anything.
Do the automotive cybersecurity rules apply to our robots?
For an industrial robot, machine tool or factory AMR, no. UN R155, UN R156 and ISO/SAE 21434 are road-vehicle rules, and only vehicle manufacturers can hold a UN R155 approval.
We are a UK manufacturer selling into the EU. What applies?
EU law sets your engineering standard and the lighter Great Britain position buys you nothing. Place products on the EU or Northern Ireland market and you meet Regulation (EU) 2023/1230 and the Cyber Resilience Act.
How long does an engagement take, and is re-testing included?
You get a fixed quote after a free scoping call, because duration depends on the number of targets and whether we get a sample or a production machine. A free re-test within six weeks is included.