Autonomy is moving onto the battlefield faster than most security programs were designed to follow. As unmanned platforms shift from pilot programs to production at scale, a growing share of their intelligence (navigation, sensing, target recognition, decision logic) runs on embedded hardware that operates far from any controlled environment.

This is the first article in a series on implementation security for autonomous defense systems. We start with the foundation: why the security perimeter moves when intelligence moves to the edge, and what that means for engineering teams.

The autonomous defense market is moving from experimentation to scale

Autonomous and semi-autonomous systems are becoming a standard part of modern defense operations. UAVs are increasingly visible, but the same trend extends to unmanned ground, surface and underwater platforms. Navigation, communications, sensor processing, target recognition and decision-making are moving onto embedded computing platforms deployed at the edge.

That shift is happening while manufacturers face pressure to shorten development cycles, add capabilities rapidly and scale production. Recent defense exhibitions have also highlighted the speed at which interceptor-drone concepts, onboard AI and new autonomous architectures are entering the market.

The cybersecurity consequence is easy to miss: more intelligence is being placed inside devices that may operate in hostile environments and may eventually be lost, intercepted, jammed, recovered or purchased for analysis.

‍

The security perimeter is moving with the intelligence

Traditional cybersecurity programs often focus on remote compromise: protecting networks, communication channels, cloud infrastructure and software interfaces. Those controls remain essential, but they do not fully address the security model of a physically deployed autonomous system.

An embedded platform can contain cryptographic keys, firmware, communication protocols, mission configuration, proprietary algorithms, sensor-processing logic and increasingly AI models. Protecting the communication link does not automatically protect those assets if the device itself becomes available to an adversary.

This means defense engineering teams need to extend the threat model from “Can someone attack the system while it is operating?” to “What happens if someone can study the system without time or access constraints?”

‍

Why implementation security matters

Encryption is necessary, but the strength of an algorithm is only one part of the problem. The implementation can leak information through power consumption, electromagnetic emissions or timing. A processor can also be deliberately disturbed through fault injection in ways that challenge assumptions made by secure boot, readout protection and other security mechanisms.

These are not purely theoretical attack paths. Physical attacks such as side-channel analysis and fault injection are increasingly part of the security assessment of critical embedded systems, including in the space sector, as in the creation of ESA's Hardware Security Laboratory, which eShard helped build.

Software adds another layer. Firmware and control applications can reveal proprietary protocols, authentication logic, update mechanisms and intellectual property through reverse engineering. Hardware and software need to be considered as connected parts of the same attack surface.

‍

A new engineering question

For defense and autonomous-system manufacturers, security needs to include a simple but demanding scenario: assume the device is captured.

Which assets would matter most if they were exposed? Where are they stored and manipulated? Which mechanisms protect them? And have those mechanisms been tested under conditions chosen by an adversary rather than by the product specification?

The organizations that answer those questions early can make security part of architecture and product development instead of discovering implementation weaknesses after hardware is frozen and production has begun. This is also where a “shift left” approach to implementation security becomes important: testing critical security assumptions earlier in the engineering lifecycle, while teams still have the freedom to change hardware, firmware or architecture.

‍

From the lab to the field: what comes next

Autonomous systems will keep gaining capability, and the pressure to field them quickly is not going away. What changes is the starting assumption. Once intelligence lives on a device operating in contested environments, it is no longer enough to ask whether the communication link is secure: the device itself must still protect what it carries when it leaves the manufacturer’s hands. Shifting left to address physical attacks earlier in the development lifecycle is what keeps that a design choice rather than a late-stage fix.

That is where the engineering conversation has to begin, and it is where this series picks up. In the next article, When Your Drone Falls Into Enemy Hands, we look at how to design autonomous systems for the reality of physical capture: what an adversary can realistically do with a recovered device, and what that means for architecture and development choices.