In the first article in this series, we looked at how autonomous systems are changing the defence threat model. In the second, we explored why physical capture needs to be treated as a realistic security scenario.

This third article takes the next step: once a system is captured, what could an adversary actually learn from it, and where should teams start looking?

‍

What becomes visible after capture?

A captured autonomous system can expose far more than a single secret key. It may reveal a chain of technical and operational assets that together show how the platform communicates, authenticates, updates, senses and makes decisions.

Cryptographic keys and credentials can protect communications, authenticate components, validate software or control access to services. Strong cryptography is essential, but implementation security determines whether a secret can be used without leaking enough information for an attacker to recover it. Side-channel analysis is relevant here because it targets the gap between the mathematical security of an algorithm and the physical behaviour of its implementation. ‍

Firmware can reveal functionality that is not visible from external interfaces, including boot logic, authentication checks, update paths, hardware configuration and undocumented behaviour. Secure boot and readout protection raise the barrier to extraction, but they also depend on correct implementation and correct processor execution. Fault injection can test what happens when those assumptions are deliberately challenged.

Once software becomes accessible, an adversary may also learn much more about how the platform fits into the wider system. Reverse engineering can reveal proprietary communication protocols, command-and-control mechanisms, authentication logic and relationships between the platform and ground-control systems.

There is also the know-how embedded in the platform itself. Proprietary algorithms, sensor-processing logic and AI models can represent substantial R&D investment and operational knowledge. Their surrounding software may reveal how sensor inputs are processed, how classifications or decisions are made and how the system responds to particular conditions.

‍

The value is often in the combination

Not every extracted element represents a vulnerability on its own. But together, firmware, protocols, credentials, algorithms and system logic can give an adversary a much richer understanding of how the platform operates.

This is why starting with attack techniques can be misleading. Side-channel analysis, fault injection and reverse engineering describe ways to investigate a target. For product, engineering and security teams, the more useful starting point is often simpler: what could be lost?

‍

Start from what matters most

A useful exercise is to ask:

If an adversary obtained one of our systems tomorrow, what would we most want them not to learn?

The answer becomes the beginning of an asset map. Teams can then locate each asset across hardware and software, identify the mechanisms protecting it and determine which realistic attack paths could expose it.

This keeps physical security connected to mission and business impact instead of treating security testing as a catalogue of attack techniques.

Once the critical assets are clear, the next question is whether the mechanisms protecting them actually hold up when an attacker starts challenging the implementation.

That is where we go next: beyond the presence of encryption, secure boot or readout protection, and into how those protections behave under real adversarial conditions.

‍