Cybersecurity

The Navy Drone Camera That Was Quietly Calling China

Chinese-made camera components on Royal Navy drone boats sent heartbeat signals to China. The MoD stripped connectivity. Here is what it means for EU/UK buyers.

CybersecurityBy Servola Tech Desk2026-08-104 min read

AI-assisted, edited by humans. | Editor-in-Chief: Leon Soliman | Editorial standards

The Navy Drone Camera That Was Quietly Calling China

Key takeaways

The Telegraph reported on 9 August 2026 (Richard Holmes) that Chinese-made camera components fitted to Royal Navy K3 Scout drone boats were sending unexplained "heartbeat communications" - routine online-status signals - to an IP address in China. The Ministry of Defence confirmed the finding and stripped internet connectivity from the cameras.
The K3 Scout is an uncrewed surface vessel built by British defence contractor Kraken Technology Group under the Royal Navy's Project Beehive. Twenty vessels, worth GBP 12 million, have been operated by the Royal Marines since March 2026.
A Ministry of Defence spokesperson said the transmissions were found during a "routine cyber vulnerability assessment" and that a subsequent investigation found no evidence MoD data or systems were accessed, compromised or sent externally. Kraken Technology Group said the cameras were NDAA-compliant but contained "a small number of components from outside the UK", sourced from a third-party supplier that had given security assurances.
The transmissions were caught after the equipment had already been in operational use for roughly five months, and only because of a routine check, not because Kraken's or its supplier's own assurances flagged the behaviour beforehand.
That gap - a paper assurance from a subcontractor versus the actual network behaviour of the hardware in service - is not unique to defence procurement. Any EU or UK business embedding third-party camera or IoT modules in its own products or premises carries the same exposure, and NIS2's supply-chain provisions now put a compliance duty on top of it.

What the Ministry of Defence found

The Telegraph's defence correspondent Richard Holmes reported on 9 August 2026 that surveillance cameras fitted to Royal Navy K3 Scout drone boats, used by the Royal Marines and closely linked to Special Boat Service operations out of Poole, contained Chinese-made components that were sending "heartbeat communications" to a device in China. A Ministry of Defence spokesperson confirmed the substance of the story, stating the transmissions were identified during a "routine cyber vulnerability assessment" of the K3 fleet and that the information exchanged amounted to confirmation the camera was online and functioning, not any operational data. Following the discovery, the MoD stripped all internet connectivity from the affected cameras.

The MoD's official position, repeated to multiple outlets, is that a subsequent investigation found no evidence any MoD data or systems were accessed, compromised or transmitted externally. That is a narrower claim than saying the components were safe: it confirms no known exfiltration, not that the phone-home behaviour was intended, disclosed, or ever meant to be there.

The GBP 12 million fleet behind Project Beehive

The K3 Scout is an 8.4-metre uncrewed surface vessel built by Kraken Technology Group, a British defence contractor based in Fareham, Hampshire. The Royal Navy contracted Kraken to supply 20 K3 Scouts and their ground control systems under Project Beehive, a programme to integrate high-speed uncrewed vessels into fleet operations; the boats can carry sensor, cargo or weapons payloads and have separately been used in trials such as an airdrop from an RAF A400M. The GBP 12 million fleet has been in service with the Royal Marines since March 2026, with some vessels reportedly earmarked for a Gulf deployment protecting shipping in the Strait of Hormuz.

Kraken Technology Group told reporters the cameras were NDAA-compliant - meeting the US defence procurement standard that bars certain Chinese suppliers - but acknowledged the units contained "a small number of components from outside the UK", which it said it sourced from a third-party supplier that had provided security assurances. Kraken maintained no sensitive information had been shared.

Where the assurance chain actually broke

The chain of custody here has three links: Kraken built and sold the K3 Scout to the Royal Navy; Kraken bought the camera module from a third-party supplier; that supplier gave Kraken assurances about the component's security. None of those assurances caught the heartbeat traffic before the boats were deployed. It surfaced only once, roughly five months into operational use, when the MoD ran a routine cyber vulnerability assessment - the kind of check that happens periodically, not the kind built into onboarding a new supplier's part.

Shadow security minister Alicia Kearns said the episode showed how supply-chain vulnerabilities can undermine sovereign defence capability even when a prime contractor is British and a compliance standard (NDAA) has formally been met. That is the part of the story compliance paperwork does not capture: a component can pass a named standard and a supplier's written assurance and still behave, in production, in a way nobody upstream tested for or disclosed.

What this means for EU and UK businesses beyond defence

This is not only a Ministry of Defence problem. Chinese-made camera and sensor modules sit inside a huge range of commercial hardware bought by ordinary EU and UK businesses: security cameras, access-control systems, smart building sensors, industrial monitoring equipment, even consumer-facing kiosks. The K3 Scout case shows that a documentary assurance from a supplier - "NDAA-compliant", "no sensitive data shared", a signed security questionnaire - is not the same claim as "we tested what this device actually does on a network," and the two can diverge without anyone in the chain noticing until an unrelated audit catches it.

Under NIS2, essential and important entities across the EU (utilities, healthcare, digital infrastructure, manufacturing of critical products, and more) carry an explicit supply-chain risk-management obligation: Article 21(2)(d) requires assessing the security practices of direct suppliers and service providers, not just their paperwork. The Royal Navy episode is a concrete illustration of why that obligation should translate into a technical step, not only a contractual one. A procurement team that wants to avoid discovering its own "heartbeat" problem five months after go-live should require, before deployment, an independent network-traffic capture of any third-party camera, sensor or IoT module - checking what it actually calls out to, not just what its supplier says it does not do. The UK sits outside NIS2's jurisdiction but faces the same practical exposure, and its own NCSC has pushed similar supply-chain assurance guidance for exactly this reason.

Frequently asked questions

Did any classified or sensitive data actually leave the Ministry of Defence?

The MoD says no. Its stated position, after investigating, is that no evidence was found of MoD data or systems being accessed, compromised or transmitted externally, and that the "heartbeat" traffic only confirmed the camera was online. That is the MoD's own account; it has not published the technical evidence behind it, and the finding rests on the same assessment process that only caught the traffic roughly five months after the equipment entered service.

Is this only a risk for defence contractors?

No. The same category of component, a camera or sensor module with embedded network behaviour, is used far more widely in commercial security cameras, building-management sensors, and industrial IoT equipment sold across the EU and UK, much of it sourced through multi-tier supply chains where the buyer never sees the original component manufacturer directly.

What should a business actually do differently after this?

Treat a supplier's written security assurance as a starting point, not a conclusion. Before deploying any third-party camera, sensor or IoT hardware on a business network, capture and review its actual outbound network traffic, and ask the supplier to name the specific manufacturer of each network-capable component, not only the assembler. For EU essential and important entities, this is also the practical way to satisfy the NIS2 Article 21(2)(d) supply-chain security-practice requirement rather than relying on a signed questionnaire alone.

The most useful detail in this story is not that a Chinese-made component was found phoning home - that risk is now widely assumed across Western procurement. It is that the assurance chain built specifically to catch this failed, quietly, for five months, on hardware operated by Britain's special forces, and was only caught by a routine check that was not part of onboarding the part in the first place. Any EU or UK business relying on a supplier's written word about what a camera, sensor or IoT device does on a network should read this as a prompt to verify that behaviour directly, before deployment, not after an unrelated audit stumbles onto it.

Royal Navysupply chain securityChinese componentsNIS2IoT securitydefense procurementKraken Technology Group

Clearing the Attacker Also Clears Your Logic

The FBI and CISA both tell water operators to wipe the controller and restore a clean image. That instruction only works if someone can still produce the program file - and in most European plants the integrator holds it, not the operator.

6 min read

Cybersecurity

Siemens and Schneider Joined the Advisory on 22 July

CISA's PLC advisory named Rockwell in April. On 22 July it added the Siemens S7-1200 and Schneider Modicon M340 - the controllers in European plant rooms.

5 min read

Decisions

The Third Pivot Was the Warning Magic Leap Missed

Magic Leap filed a WARN notice for 193 layoffs effective 1 October 2026, its fourth strategic pivot after $4 billion raised. The lesson is the pattern, not the pivot.

4 min read

← All articles