Behind the Logo: Who Really Built Your Security Robot?

By Renato Cudicio, MBA, President of Glocal Robotics

Like many of you, I spend part of my week on LinkedIn and YouTube. And for the past few months, the same show has been playing on loop: robot dogs performing backflips, dancing humanoids, and wheeled platforms slaloming between cones—all presented, with sometimes disarming seriousness, as the next generation of “security robots.”

I don’t dispute that these machines are technically impressive. But as for whether a backflip has anything to do with protecting a port, a power plant, or a military site—allow me to doubt it.

So I’d like, politely, to voice a slight complaint. Not against robotics—it’s my profession, and I believe in it deeply—but against a growing confusion that, at sensitive sites, can prove costly: the belief that marketing a robot and mastering it are one and the same.

At its core, what is a security robot?

From the outside, a security robot consists of four wheels or tracks, cameras, a LiDAR, an antenna, and a computer. It’s tempting to lump it in with an autonomous cart or a cleaning robot. That’s a misconception.

A security robot is a sophisticated, connected computer system equipped with sensors that sees, listens, maps, analyzes, communicates, and… moves. For a material-handling robot, the origin and control of the technology primarily have commercial or operational implications. For a robot tasked with monitoring a factory, a port, an energy infrastructure, or a strategic facility, these implications become a matter of cybersecurity, confidentiality, business continuity, and, potentially, sovereignty.

Because what such a machine collects and processes is far from trivial: precise images of the interior and exterior of a site, detailed maps of the facilities, GPS coordinates, patrol routes and schedules, operational patterns, access points, the presence or absence of personnel, their faces, security incidents, telemetry, sometimes audio, and even information about the client’s network architecture.

In other words, a security robot can create a precise and continuously updated map of a sensitive site. So the right question is no longer just, “Is the robot working properly?” It becomes, “What happens to the information it collects, which components have access to it, and who actually controls the system?”

The real risk isn’t always what we imagine

In this context, there’s a lot of talk about “Trojan horses”—the fear of a hidden chip that would spy on everyone without their knowledge. Let’s be precise, because this is a subject where vagueness does everyone a disservice.

The Canadian Centre for Cybersecurity, in fact, believes it is unlikely, in the short term, that a purely hardware-based Trojan horse will become a major attack vector. However, it defines very clearly what a hardware supply chain compromise is: the addition or modification of components intended to create a backdoor, which can then be used to establish remote access, exfiltrate data, or compromise the equipment via remote command. And he adds a crucial clarification: when a physical product becomes a vector for infection, it most often serves as a vehicle for a software-based threat.

This nuance shifts the focus of the issue to where it belongs. The real issue is almost never a mysterious chip soldered in secret. It’s much more mundane—and much harder to spot: who controls the software, firmware, communications, and updates flowing through this connected device?

Be wary of unusually low prices—and spectacular demonstrations

A word must also be said about pricing. A platform packed with cameras, LiDAR, onboard computing, and artificial intelligence models involves considerable design and manufacturing costs. When such a robot is offered at a surprisingly low price, it’s not industrial magic. It means that someone, somewhere, is absorbing the difference—and it’s legitimate to ask why, and in exchange for what.

An unusually low price for such a capable machine isn’t just a good deal. It’s a red flag. It warrants asking who actually designed the platform, who controls its core layers, and what the supplier whose logo is on the product can actually guarantee. A demonstration of flips answers none of these questions.

First requirement: knowing exactly what’s inside the device

A genuine manufacturer must be able to answer simple questions for each critical component: who manufactures it, in which country, under what exact part number, with what firmware, what interfaces it has, what communications it can initiate, how it updates itself, what data it can record, and what external dependencies it has.

On the software side, we’re familiar with the concept of an SBOM—the Software Bill of Materials. This must be complemented by its hardware equivalent, the HBOM (Hardware Bill of Materials). Without this traceability, we simply don’t know what the robot is made of.

This is not a theoretical concern. The Canadian Cyber Security Centre explicitly recommends safeguarding against unauthorized production, counterfeiting, modification, and the insertion of malicious code or backdoors throughout a system’s lifecycle.

Second requirement: knowing exactly what the software does

This is the heart of the matter. I distinguish four software layers, and for each one, you need to know who controls it.

Navigation: autopilot, trajectories, obstacle avoidance, localization, motor controls, and security behaviors. If the seller does not have access to these layers, they depend on a third party to fix even the smallest vulnerability or modify even the slightest behavior.

Perception and artificial intelligence: video streams, models, object recognition, thermal processing, generated metadata, and the data used to train or improve the models. One question reveals a lot: Is the analysis performed locally, or do certain images leave the robot?

Communications: Which addresses does the machine contact? Outgoing calls, telemetry servers, APIs, cloud services, automatic updates, DNS, VPN, 4G/5G, Wi-Fi, mesh networks, satellite. The principle is simple: a security system should not contain any communications that its operator cannot identify, audit, or disable.

Updates: this is the point most often overlooked. A machine may be flawless on the day it is installed but become far less so six months later. ENISA’s 2021 report (PDF – 4.8 MB) on supply chain attacks sheds light on this issue: in the cases studied, approximately 66% of attacks targeted vendor code, with legitimate update mechanisms being used specifically to distribute malicious code. A system’s sovereignty is therefore not measured solely by the software installed on it today, but by what might be installed on it tomorrow.

The “black box”: a concept we must never lose sight of

A system integrator may know their robot very well while still lacking control over certain components. We often see setups like this: platform assembled by A → controller supplied by B → smart camera from C → 4G module from D → proprietary firmware from E → cloud environment operated by F.
At the end of this chain, who actually controls the data? This is where we must distinguish between two approaches that commercial terminology often confuses.
– Integration: “I buy an existing platform and add my own equipment to it.”
– Technological control: “I understand the entire architecture and can choose, remove, modify, or replace each of the critical components.”
The difference is not merely semantic. It determines what a supplier is actually able to guarantee.

The Chain of Trust

From this observation arises an idea that I believe is central: the concept of the chain of trust. It extends from electronic components to firmware, then to the operating system, navigation, artificial intelligence, communications, command and control, storage, and, finally, updates.

The rule is ironclad: a robot’s cybersecurity can never be stronger than that of the weakest link in the chain controlled by its manufacturer. Let’s remember that a supply chain is a network of trust relationships, and that a compromise at a supplier can allow an attacker to reach the customer as soon as the equipment connects to the network.

Where Data Resides—and Which Laws Apply

Next, we must distinguish, in very practical terms, between five key aspects: where the data is generated (within the robot), where it is analyzed (at the edge, on a local server, or in the cloud), where it is stored, where it transits, and—this is the decisive point—who, legally speaking, can access it.

This is where sovereignty ceases to be a slogan and becomes a legal issue. In many jurisdictions, a government can compel a company subject to its laws to cooperate with its intelligence agencies, regardless of that company’s intentions. The debate is therefore not about “this country is good, that one is bad.” The relevant line of reasoning is as follows: In which jurisdiction are my service providers located, and what legal obligations can be imposed on them without my knowledge?

Operational sovereignty: operating without depending on anyone

A robot’s true autonomy is not limited to its ability to move on its own. It also includes its ability to carry out its mission without constantly relying on infrastructure that its user does not control.

A security robot should be able to perform its essential functions without an internet connection, without foreign cloud computing, without authentication with a remote server, without a remote license required for navigation, and without a permanent link to the manufacturer. A system that stops working because a server located on the other side of the world is no longer responding is not a sovereign system. It is a leased service.

Substitutability: Industrial Resilience

Let’s shift from cybersecurity to industrial sovereignty. What happens if a border closes, if a manufacturer discontinues a product, if geopolitical tensions arise, if an export license is revoked, if a part becomes unavailable, or if software is no longer supported?

A local manufacturer capable of qualifying multiple suppliers, replacing a component, mechanically adapting the machine, modifying the firmware, and recompiling its software possesses a level of resilience that is incomparable to that of a distributor dependent on a single original equipment manufacturer. In this context, we strongly recommend diversifying supply sources and identifying multiple suppliers for replacement components. A manufacturer has full control over its product when it can replace a critical component without having to replace the robot itself.

The Canadian Context in 2026—and the Same Challenge in Europe

This reasoning is by no means abstract, and current Canadian regulatory developments confirm it. In April 2026, the Government of Canada introduced the first level of the Canadian Program for Cyber Security Certification (CPCSC), whose requirements apply to certain defense contracts since the summer of 2026, with higher levels—subject to certification by accredited third parties—to follow thereafter. Ottawa puts it bluntly: Canadian defense supply chains are increasingly being targeted by cyber-malicious activities, and supplier security is now a component of national security.

The country’s strategic trend is therefore toward systems, suppliers, and supply chains whose level of trustworthiness can be demonstrated. And it would be wrong to believe that this is a strictly Canadian concern: Europe is following exactly the same path, driven by the work of ENISA, the NIS2 Directive, and an increasingly explicit debate on technological and industrial sovereignty. The terminology may vary from one continent to another, but the logic remains the same.

Twelve Questions to Ask Before Buying
Here is a summary of the questions every security manager should ask a vendor—and why they matter.

If there’s one thing to remember: before buying a security robot, ask who actually built it.

What this means for Glocal Robotics

It is precisely for these reasons that Glocal Robotics has chosen to retain control over the THALAMUS architecture rather than simply customizing a platform designed by a third party. In practical terms, this is organized around six areas of expertise.

Mechanical expertise: physical architecture, sensor integration, propulsion, and power supply. Electronic expertise: the selection and qualification of key components. Navigation expertise: autopilot, localization, trajectories, and behaviors. Perception and AI expertise: sensor processing and detection functions. Communications expertise: the ability to choose multiple technologies and operate within different network architectures. Command, control, and data expertise: control over where data flows, is processed, and is stored.

It is also in line with this approach that Glocal Robotics already complies with Level 1 criteria of the CPCSC and is working toward achieving Level 2. Not just to check a box, but because these requirements describe, in regulatory language, what we have considered from the outset to be the right way to build a safety machine.

A clarification, because this is important to me. I am not claiming that “robots from a certain country send their data abroad”: to assert that without specific technical evidence regarding a given product would be dishonest. I am saying something else—something more defensible. When a supplier markets a platform designed by a third-party manufacturer, it should be able to demonstrate that it has control over all the components, firmware, data flows, and update mechanisms that make up the system. Can it truly guarantee this if it neither designed the machine nor has access to its essential technological layers? I’ll let everyone draw their own conclusions.

The Real Question

If this article had to be summed up in four words, these would be them.
Traceability: knowing exactly what the robot is made of. Control: being able to understand, modify, and secure both the hardware and the software. Sovereignty: controlling the data, communications, suppliers, and dependencies. Resilience: being able to continue operating and upgrading the machine regardless of geopolitical or commercial circumstances.

When it comes to security robotics, the question is no longer just about where a robot is assembled, nor how many somersaults it can do. The real question is who controls what it sees, what it understands, what it transmits, and what it is capable of doing.

It’s not “Canadian” versus “Chinese.” It’s controlled, traceable technology versus technology where certain aspects remain black boxes. At an industrial site, a critical infrastructure facility, or a defense installation, it is this distinction—far more than the mere “locally manufactured” argument—that should guide the decision.