In this series, we've explored how autonomous systems are changing the defence threat model, why physical capture needs to be considered from the design stage, and what an adversary could extract from a captured drone.

We've established what is at risk. Now comes another important question: how do we know that the mechanisms protecting those assets will actually hold up against an attack?

Modern embedded systems rely on established security mechanisms: encryption, authentication, secure boot, signed firmware and memory readout protection. These are essential foundations, but having them in place does not automatically guarantee that the final product is secure.

There is a difference between designing a system to be secure and demonstrating that its implementation can withstand someone actively trying to compromise it.

‍

Strong encryption doesn't tell the whole story

Cryptographic algorithms are designed to protect sensitive information. But even when the underlying mathematics is sound, the physical device executing those algorithms can introduce vulnerabilities.

Side-channel analysis (SCA) is one example. By observing physical signals generated during computation, such as variations in power consumption or electromagnetic emissions, an attacker may be able to recover information that should remain secret, including cryptographic keys.

In other words, the attacker doesn't necessarily need to break the encryption. They may find a weakness in how the device performs it.

This distinction is particularly relevant as the industry transitions towards post-quantum cryptography (PQC). Adopting quantum-resistant algorithms addresses an important emerging threat, but it does not remove the need for implementation security. As we've discussed in our article on securing PQC implementations against physical attacks, even newer cryptographic algorithms need to be evaluated against physical attack techniques.

Whether we're talking about conventional cryptography or PQC, the principle remains the same: choosing a secure algorithm is one thing. Ensuring that the device executes it securely is another.

‍

What happens when security mechanisms are deliberately challenged?

Encryption is only part of the picture.

Secure boot, for example, is designed to ensure that only authorised firmware can execute. Memory readout protection is intended to prevent unauthorized extraction of sensitive content.

But these protections depend on the hardware and software behaving as intended.

Fault injection (FI) deliberately challenges that assumption. By introducing precisely controlled disturbances, such as voltage glitches or electromagnetic pulses, an attacker may cause a processor to behave unexpectedly. Depending on the implementation, this can lead to skipped security checks, bypassed protections or access to firmware that should have remained inaccessible.

This doesn't mean every protection is vulnerable. It means that the presence of a security feature and its resistance to attack are two different things.

Specifications describe what a system is designed to do. Physical security testing helps establish whether those promises still hold when an attacker deliberately pushes the device outside its normal operating conditions.

‍

Security needs to be demonstrated on the final product

For manufacturers and engineering leaders, this has practical implications.

A secure component does not necessarily guarantee a secure system. The final result depends on how hardware, firmware, cryptographic implementations and the wider architecture work together.

And the later a weakness is discovered, the more difficult it may become to address. A vulnerability identified while the architecture is still being developed leaves room for design changes. Discovering the same issue once hardware is finalised and production has begun can significantly limit the available options.

This is why implementation-level security testing should be considered earlier in the development process, rather than treated solely as a final validation exercise.

The objective is not to prove that every possible attack can be prevented. It is to understand how well critical protections resist realistic threats and identify weaknesses before an adversary does.

For organisations developing autonomous defence systems, the question should therefore evolve from "Have we integrated the right security mechanisms?" to "Have we demonstrated that those mechanisms protect what matters, even when the system is physically attacked?"

That is what turns security specifications into evidence.

‍

Coming next: One System, One Attack Surface

So far, we have looked at physical capture, the assets it can expose and the security mechanisms intended to protect them. But a UAV is not a collection of isolated components.

In the next article, we'll widen the perspective to examine how onboard hardware, firmware, communication interfaces and the wider operating environment interact, and why securing each element individually does not necessarily secure the complete system.

‍

‍