The Heartbeat Beneath the Hull: What the Royal Navy Drone Incident Reveals About Cyber-Physical Supply Chains

The discovery of communications between a camera subsystem on Royal Navy uncrewed vessels and a China-based internet address is not, on the evidence available, proof of espionage. It is nevertheless an important warning: in connected defence and critical-infrastructure systems, assurance must extend beyond the platform and its prime supplier into the firmware, chipsets, communications pathways and embedded components beneath them.

What has been established?

The Royal Navy purchased 20 K3 Scout uncrewed surface vessels from British manufacturer Kraken Technology Group under the £12.3 million Project Beehive programme. The vessels are intended for operations, training and capability development by the Coastal Forces Squadron and 47 Commando Royal Marines. Their open architecture allows additional sensors and capabilities to be integrated as the Royal Navy develops its “Hybrid Navy” of crewed and uncrewed systems.

In May, the Royal Navy described Kraken vessels operating as part of a wider mesh network in which uncrewed boats, drones and other systems exchanged data with a shore-based command node. The Navy said the work had enabled the craft to become integrated components of the Joint Force. This is important context: the K3 Scout is not simply a standalone vessel, but a potentially connected sensor and operational node within a wider military system. The subsequent security assessment reportedly found that a component within third-party cameras fitted to the vessels was sending automatic “heartbeat” communications to an IP address in China. These messages are normally used to indicate that a device is online and functioning.

The Ministry of Defence says the issue was discovered through a routine cyber-vulnerability assessment and that a thorough investigation found no evidence of MoD systems or data being accessed, compromised or transmitted externally. Internet connectivity was removed from the affected equipment. Kraken has also said that an audit conducted with the Royal Navy found no evidence of sensitive information leaving intended channels and that the potential vulnerabilities had been closed.

These conclusions should be given proper weight. There is currently no public evidence that imagery, audio, location data, operational plans or classified information was transmitted. Nor is there evidence publicly attributing the communications to a Chinese intelligence service or state-sponsored threat actor. An IP address identifies a network endpoint; it does not, by itself, establish who controlled the endpoint or why the communication occurred.

Why a “heartbeat” can still matter

Automated telemetry is common in commercial technology. Devices may contact external infrastructure for health monitoring, licensing, time synchronisation, software updates, crash reporting or vendor support. Functionality that is routine in a consumer product can, however, create an unacceptable dependency or information flow when incorporated into a defence platform.

Even where a heartbeat contains no imagery or mission data, its metadata may disclose that a device is active, its source IP address, connection frequency, software or device identifiers, and the timing and duration of its operation. If observable across several systems, this could potentially contribute to an assessment of testing patterns, readiness or operational tempo. Whether that occurred here is not known, but it is one reason seemingly innocuous telemetry warrants investigation.

More fundamentally, an undocumented outbound connection shows that the device’s behaviour was not fully understood or controlled by its operator. Investigators would therefore need to establish:

• Exactly what information was transmitted and whether it was encrypted. 
• Who owned and administered the receiving infrastructure. 
• Whether the channel was outbound-only or capable of receiving instructions. 
• Whether it supported configuration changes, diagnostics or firmware updates. 
• What certificates, credentials or cryptographic keys were used. 
• Whether equivalent functionality existed in other power, maintenance or failover states. 
• What logs were retained and whether they were sufficient to exclude earlier or different activity.

“No evidence of compromise” should not be misrepresented as proof of hostile activity, but neither should it make an unauthorised external communication path irrelevant. The real security issue is the loss of assured control over a component operating within a sensitive cyber-physical environment.

The wider threat-intelligence context

There is no established link between this incident and any known Chinese cyber campaign. Nevertheless, it sits within a threat landscape in which embedded and edge devices are actively targeted.

In April 2026, the UK National Cyber Security Centre and international partners warned that China-nexus actors were increasingly using large networks of compromised routers, internet-connected cameras, video recorders and other smart devices to conceal malicious activity. The NCSC described the use of such infrastructure by Volt Typhoon to pre-position capability against critical infrastructure and by Flax Typhoon to support cyber espionage. The Raptor Train network alone had infected more than 200,000 devices worldwide.

This does not make every Chinese-manufactured component malicious. Country of origin is a risk factor, not a vulnerability. The more useful questions concern who designed and manufactured the component, who controls its firmware and update infrastructure, what external services it trusts, what data it can reach, and what operational effect could follow from its compromise.

For an uncrewed system, the consequences also extend beyond conventional data loss. A compromised sensor might be unavailable at a critical moment, provide misleading information, expose the platform’s location, enable access to an adjacent subsystem, or create a pathway through which future disruption could be attempted. Cyber-physical risk therefore encompasses confidentiality, integrity, availability, safety and mission effectiveness.

Looking beneath the platform

Supplier questionnaires, certifications and contractual declarations remain necessary, but they provide organisational assurance rather than complete technical assurance of every product. A prime supplier may itself depend on camera manufacturers, original design manufacturers, chipset vendors, software libraries, cloud services and firmware developers several tiers below it.

The MoD’s Cyber Security Model Version 4 recognises the importance of flowing security requirements through subcontracting tiers. Product assurance must complement that process by examining the actual behaviour and construction of the device.

A meaningful component-level assessment should include hardware and software bills of materials; manufacturer and country-of-origin analysis; firmware extraction and integrity checking; secure-boot and update-chain validation; examination of chipsets, storage and debug interfaces; protocol and network-traffic analysis; credential and certificate review; and testing under realistic operational configurations. An SBOM can improve transparency, although the NCSC cautions that it is not a security guarantee and must be accurate, current and combined with technical testing.

MITRE EMB3D provides a particularly useful structure for this work. Unlike enterprise-focused threat models, EMB3D maps threats to the physical and logical properties of embedded devices. Relevant areas include unverified peripheral firmware, insecure or remotely initiated updates, hard-coded credentials, undocumented protocol features, unauthorised connections and weakly protected communications. The framework helps translate a component inventory into plausible attack paths and prioritised mitigations.

This is the approach Talan Threat Services is already applying in component-level cyber-physical risk assessments for defence manufacturers and energy-sector operators. Live threat intelligence provides the adversary context; device, firmware and communications analysis establishes the actual exposure; and MITRE EMB3D provides a consistent means of mapping findings to real-world embedded-system threats. The objective is not simply to identify vulnerabilities, but to explain which weaknesses could affect operations, safety or supply-chain integrity and therefore require priority treatment.

Assurance must continue after deployment

The positive aspect of this incident is that assurance testing detected the unexpected behaviour and enabled it to be contained. The broader lesson is that this testing cannot be a one-off procurement gate.

Mission systems should operate with tightly controlled outbound connectivity, destination allow-listing, authenticated and encrypted communications, segmented sensor networks, locally controlled update mechanisms and monitoring capable of detecting changes from an approved baseline. Component substitutions, firmware updates, supplier acquisitions and newly identified threat intelligence should all trigger reassessment.

Rapid innovation and robust assurance are not opposing objectives. As defence and critical-infrastructure operators adopt increasingly connected and autonomous systems, speed must be supported by continuous, intelligence-led scrutiny extending all the way down to the component and chipset. A platform can only be considered trusted when its provenance, communications and behaviour have been demonstrated, not merely assumed.