Cybersecurity, safety and the law

A connected robot that can be reprogrammed over a network can also be misused over a network. An attacker who changes a speed limit, a safety zone, a calibration value or a mobile robot's map can turn a safe machine into a dangerous one without touching it. Cybersecurity is therefore part of robot safety, and lawmakers have started to treat it that way, with security requirements appearing in machinery law, medical device law, product law and critical infrastructure law. ROB-360 lesson 10 covered the technical practices of securing robot software, such as threat modelling, secure communication, signed updates and least privilege, and the CISSP courses cover security governance in depth. This lesson focuses on the meeting point of security, safety and law: how attacks can defeat safety functions, how standards connect security to functional safety, what the law now requires of manufacturers and operators, and who is liable when a security failure leads to harm.

How attacks become safety problems

Safety engineering traditionally assumes that failures are random or result from honest mistakes. An attacker is different: intelligent, adaptive and able to choose the worst moment. Several kinds of attack can create physical hazards in robots.

Researchers demonstrated the risk in 2017, when a study by Politecnico di Milano and Trend Micro showed that industrial robot controllers exposed on networks could be manipulated to alter calibration and control parameters, subtly changing robot motion and the products made. Since then, government agencies such as the US Cybersecurity and Infrastructure Security Agency have published many advisories about vulnerabilities in robot controllers, programmable logic controllers and safety components. Well-designed safety architectures limit the damage: a hardwired emergency stop, safety functions in a separate safety controller with its configuration protected by passwords and checksums, and independent safety-rated sensors that do not depend on the network all reduce what an attacker can do. Lessons 3 and 4 showed that independence of channels protects against common cause failures; the same idea protects against common cause attacks.

Standards that connect security and safety

The IEC 62443 series is the main framework for security of industrial automation and control systems, including robot cells. It divides a system into zones of assets with similar security needs, connected by conduits through which communication is controlled, and assigns each zone a target security level based on the threats it must resist. IEC 62443-3-2 describes the security risk assessment for zones and conduits, IEC 62443-3-3 the system security requirements, and IEC 62443-4-1 and 4-2 the product development life cycle and component requirements that robot and controller makers follow.

Security and safety can conflict. A security patch may change a safety-related controller and require revalidation; locking doors against intruders may conflict with emergency egress; account lockouts after failed passwords may prevent a technician from stopping a dangerous process. IEC TS 63074:2023 addresses security aspects related to the functional safety of safety-related control systems, explaining how threats to safety functions should be considered in the IEC 62061 and ISO 13849-1 processes, and ISO/IEC TR 5469 notes similar issues for AI. The practical rule is to run safety and security risk assessments together, so that each team knows what the other's measures do. The EU Machinery Regulation, discussed in lesson 5, makes protection against corruption a legal essential requirement for machinery placed on the EU market from January 2027, and machinery makers are expected to use IEC 62443 and related standards to show compliance.

# Choosing security measures for a robot cell under a budget, by risk reduction per dollar (illustrative)
threats = {   # name: (likelihood per year, consequence score 1-100)
    "remote change of safety config": (0.05, 95),
    "ransomware on cell HMI":         (0.20, 40),
    "spoofed AMR map update":         (0.08, 70),
    "USB malware via technician":     (0.15, 35),
}
measures = [  # (name, cost, {threat: fraction of likelihood removed})
    ("safety password + checksum audit", 4000, {"remote change of safety config": 0.85}),
    ("cell firewall and zone design",   18000, {"remote change of safety config": 0.6, "ransomware on cell HMI": 0.6, "spoofed AMR map update": 0.4}),
    ("signed map and update pipeline",  12000, {"spoofed AMR map update": 0.9}),
    ("USB port control and policy",      2500, {"USB malware via technician": 0.7, "ransomware on cell HMI": 0.2}),
    ("offline backups and recovery",     6000, {"ransomware on cell HMI": 0.3}),
]
def risk(t):
    return sum(l * c for l, c in t.values())
budget, chosen, current = 30000, [], dict(threats)
print(f"initial annual risk score: {risk(current):.2f}")
while True:
    best = None
    for name, cost, eff in measures:
        if name in chosen or cost > budget:
            continue
        trial = {k: (l * (1 - eff.get(k, 0)), c) for k, (l, c) in current.items()}
        gain = (risk(current) - risk(trial)) / cost
        if best is None or gain > best[0]:
            best = (gain, name, cost, trial)
    if best is None:
        break
    _, name, cost, current = best
    chosen.append(name); budget -= cost
    print(f"add {name:34s} cost {cost:6d}  risk now {risk(current):.2f}  budget left {budget}")

initial annual risk score: 23.60
add USB port control and policy        cost   2500  risk now 18.33  budget left 27500
add safety password + checksum audit   cost   4000  risk now 14.29  budget left 23500
add signed map and update pipeline     cost  12000  risk now 9.25  budget left 11500
add offline backups and recovery       cost   6000  risk now 7.33  budget left 5500

Quantitative scores like these are rough, but they force teams to state assumptions and compare options on the same basis. Note that the cheapest measures against the most severe threat, protecting the safety configuration, come first, which mirrors the safety principle of addressing severe consequences early.

What the law requires

Security duties come from several directions: product law for manufacturers, critical infrastructure law for operators in essential sectors, privacy and breach notification law for anyone holding personal information, sector regulators for medical devices and vehicles, and securities law for public companies. The European Union's Cyber Resilience Act, Regulation (EU) 2024/2847, is the most comprehensive product security law and affects any company selling connected robots in Europe.

In Canada, Bill C-8, which received royal assent in June 2026, enacts the Critical Cyber Systems Protection Act for federally regulated critical sectors such as telecommunications, energy, finance and transportation, with obligations for cyber security programs, supply chain risk management and incident reporting that come into force in phases; robots and automation used by operators in those sectors will fall within their compliance programmes. PIPEDA requires organizations to report breaches of security safeguards involving personal information to the Privacy Commissioner and to notify affected individuals where there is a real risk of significant harm, and Quebec's Law 25 has similar rules for confidentiality incidents. Health Canada expects pre-market cybersecurity information for connected medical devices. The Canadian Centre for Cyber Security publishes guidance and receives incident reports, and provincial securities regulators expect public companies to disclose material cyber risks and incidents.

Liability for security failures

When an attack on a robot causes injury or loss, the questions of product liability and negligence from lesson 8 return in a new form. Was it reasonable to ship the robot with a default password, an unpatched known vulnerability or an exposed remote service? Did the operator follow the manufacturer's security guidance and apply updates? Was the attack foreseeable? Courts generally expect security measures in line with the state of the art and the known threat environment, so the publication of a vulnerability advisory or a patch can change what is reasonable overnight. Contracts increasingly allocate security responsibilities explicitly, such as who patches, who monitors and who responds, and specify support periods for security updates. Insurance for cyber events is usually separate from general liability insurance, and policies may exclude bodily injury or acts of war, which can leave gaps when a cyber attack causes physical harm. Companies should check how their policies would respond to a cyber attack that injures someone, because the answer is often unclear.

The bottom line for robot engineers is that security is a design input with legal consequences. Building in secure defaults, unique credentials, signed updates, network segmentation, protected safety configurations, logging and a coordinated vulnerability disclosure process is no longer just good practice; it is increasingly what the law requires and what courts will expect.