Cameras on Royal Navy drone boats were found contacting a Chinese IP address during a UK Ministry of Defence cybersecurity assessment, prompting officials to cut their internet access.
Kraken Technology Group’s K3 Scout vessels used the affected third-party camera subsystem. Unexpected outbound traffic from military hardware has put supplier vetting and device-level security under scrutiny.
Questions remain over how the connection passed supplier checks and why it surfaced only during later testing.
Camera subsystem contacted a Chinese IP address
Investigators detected “heartbeat communications” from the cameras to an IP address in China, according to The Telegraph. Heartbeat traffic is commonly used to tell another system that a connected device remains online and operational.
Officials removed internet access from the cameras after discovering the connection. Ownership of the Chinese IP has not been publicly established, leaving the purpose of the traffic unresolved. Similar IoT camera supply-chain risks have shown how embedded components can introduce network behavior buyers may never see during procurement.
UK Ministry of Defence (MoD) investigators said they found no evidence that internal systems or sensitive data were compromised or transmitted. Kraken also said an audit with the Royal Navy found no sensitive information had left intended channels and that identified vulnerabilities were closed.
Third-party cameras put supplier assurance under scrutiny
Kraken did not manufacture the affected cameras. The equipment came from a third-party supplier, and some camera components originated outside the UK. The supplier had reportedly provided security assurances before deployment.
MoD’s Cyber Security Model requires suppliers to carry cybersecurity protections through subcontracting tiers. Later testing still found outbound traffic that required investigation, despite those earlier assurances. Similar third-party risk management problems can emerge when organizations rely on paperwork or vendor declarations without validating how connected hardware behaves on a live network.
Supplier checks can reduce risk, but embedded-device security also depends on what happens after installation. Firmware updates or cloud dependencies can alter where a device connects and what information it sends.
Security teams should test what connected devices actually do
Organizations using cameras, IoT equipment, or embedded hardware should treat vendor documentation as a starting point and verify actual network behavior before deployment. Acceptance testing should identify expected outbound destinations, then block connections with no operational need.
Network segmentation limits what a device reaches if unexpected traffic appears later.
On the other hand, network detection and response can help security teams spot new or unusual connections after deployment. Firmware updates and configuration changes should trigger fresh checks because device behavior can change over time.
Security teams managing sensitive environments should investigate unexplained outbound traffic even when no data loss has been confirmed. Isolating the device, identifying the destination, and confirming why the connection exists can prevent an unnoticed communication path from becoming a larger exposure.
Also read: Palo Alto Networks is facing fresh scrutiny in China as regulators examine products used across sensitive enterprise environments.