Part of the PROTECT Playbook ← Return to Hub
Phase: Protect All vessels
Satisfies: E26E27IMO MSC-FAL.1BIMCO v5

Wireless & Bluetooth Hardening

This guide covers the security controls required for all wireless communication on board — from Wi-Fi access points to Bluetooth sensors — ensuring encrypted, authenticated, and segmented wireless networks. Under IACS UR E26 §4.2.5, wireless interfaces must be managed as conduits and subject to the same zone boundary controls as wired network connections.

Wireless technology on ships — from Bluetooth vibration sensors to Wi-Fi tablets for engine rounds — offers operational efficiency but expands the attack surface. Unlike a physical cable, wireless signals travel through bulkheads, meaning an attacker in a pilot boat, on the quayside, or in a passing vessel could potentially access your OT backbone without ever stepping on deck. Distance is not a security control.

The invisible threat — shadow wireless

Rogue access points

Crew members often install travel routers in the ECR or accommodation to extend Wi-Fi coverage. These devices create an unmonitored back-door with no VLAN segmentation, no firewall, and no logging — directly bridging the crew network into whatever switch port they plug into.

Default Bluetooth pairing

Industrial sensors and HMI devices often ship with default Bluetooth pairing codes (0000 or 1234) and discoverable mode enabled. Without hardening, an attacker within 10–100 metres can spoof sensor data, hijack the connection, or use the device as a pivot point into the vessel network.

Signal bleed beyond the hull

Access points at default transmission power broadcast well beyond the vessel’s hull. In port — where the vessel is stationary and surrounded by quayside workers, contractors, and adjacent vessels — an attacker within range can conduct a passive survey of all vessel SSIDs, capture handshake traffic, and run offline cracking without any active connection attempt triggering your IDS. The risk is highest during port calls and maintenance periods when the vessel is accessible and third parties are on board.

Step 1 — Protocol hardening standards

Securing wireless OT requires encryption, authentication, and signal management applied consistently across all wireless protocols in use on the vessel.

Protocol Minimum standard Configuration actions What to avoid
Wi-Fi — OT zone WPA3-Enterprise Disable SSID broadcasting · certificate-based auth (802.1X) · dedicated VLAN for OT Wi-Fi devices · no internet access on OT SSID WPA2-PSK with shared password · SSID visible to all · no VLAN assignment
Wi-Fi — crew / hotel WPA3-Personal minimum Separate SSID from OT · dedicated crew VLAN · internet access via iDMZ only · no access to any OT subnet Bridging crew and OT SSIDs · no VLAN isolation · shared AP between crew and OT
Bluetooth SSP / LE Secure Connections Disable discoverable mode after pairing · use non-default complex PINs · enable Secure Simple Pairing · whitelist paired devices only Default PIN 0000/1234 · permanently discoverable · no device whitelist
RF / LoRaWAN sensors AES-128 end-to-end Enable end-to-end encryption at gateway level · rotate network session keys · verify gateway firmware against OEM baseline Unencrypted RF · default gateway credentials · no key rotation
Satcom / VSAT TLS 1.2 minimum on all sessions VSAT modem on dedicated VLAN · no direct OT access from VSAT segment · all traffic through iDMZ firewall · OEM remote sessions via SEP only VSAT modem bridged directly to OT switch · no firewall between VSAT and vessel network

Step 2 — Rogue access point detection

Physical RF surveys must be conducted at every port call and after any maintenance period. A rogue AP installed during a port call can be operating silently for weeks before it is detected by network monitoring alone.

Conduct a Wi-Fi walk-through with a spectrum analyser or Wi-Fi scanning app — Walk all machinery spaces, the ECR, bridge, and crew accommodation. Any SSID not in the approved AP inventory is a rogue device. Document the location and MAC address.
Check the switch MAC address table for unknown devices — Run show mac address-table on the core switch. Any MAC address not in the CBS Register is an unauthorised device connected to the vessel network.
Check DHCP leases for unexpected devices — Review the DHCP server lease table for any device with an unrecognised hostname or MAC OUI (manufacturer prefix). Consumer router manufacturers (TP-Link, Netgear, Asus) appearing in an OT DHCP lease are an immediate red flag.
Physically inspect all accessible switch ports in machinery spaces — Any port with an active link light and an unknown device connected must be investigated immediately. Port security (MAC-based lockdown) should be configured to alert on new MAC addresses in OT zones.

Step 3 — Configuration hardening checklist

ETO wireless audit checklist
RF survey — post port call

Conduct a walk-through with a Wi-Fi analyser to identify unauthorised SSIDs in machinery spaces and ECR. Log all detected SSIDs against the approved AP inventory. Any unrecognised SSID is a Level 2 incident trigger.

No admin-over-Wi-Fi

Verify that switch and PLC management interfaces are accessible only via a physical wired connection. Test by attempting to reach the management IP from a Wi-Fi connected device — the connection must fail.

Transmission power tuning

Reduce AP transmission power so the signal does not bleed excessively outside the vessel hull. Target: minimum power required for coverage, verified by walking the perimeter of the vessel at a pier to confirm signal is not readable beyond 5 metres from the hull.

Bluetooth device audit

Scan for discoverable Bluetooth devices across all machinery spaces using a mobile device in Bluetooth discovery mode. Any device responding that is not in the CBS Register must be investigated. Confirm all paired devices have non-default PINs and are set to non-discoverable after pairing.

Legacy vessel note: On older ships where the OT network is flat (no VLAN segmentation), never connect a Wi-Fi access point directly to an OT switch. Place a dedicated firewall between the AP and the OT switch, inspect all traffic, and log all connections before considering the wireless installation compliant.

Audit evidence requirements

Class surveyors reviewing the PROTECT phase will ask to see documented evidence that wireless interfaces are managed as conduits under E26 §4.2.5. The following records must be maintained.

Evidence required Frequency Where filed
Approved AP and wireless device inventory Updated after every MoC event CBS Register — CSDD Appendix
RF survey log — post port call After every port call with maintenance access Cyber Incident Log or dedicated wireless audit log
AP configuration baseline Captured at commissioning and after each firmware update Configuration Backup — CSDD §4.4.3
Bluetooth device pairing register Updated when any device is paired or removed CBS Register — Bluetooth subsection

Next Section

ZTNA and iDMZ—The Gold Standard for OT Remote Access

ZTNA and iDMZ—The Gold Standard for OT Remote Access This guide explains the Zero Trust Network Access and Industrial ...

Scroll to Top