Shipboard penetration testing & red teaming
Test the bridge and engine room through an attacker's eyes — safety first, never gambling with live systems under way.
- 4Test-window tiers
- Under way / alongside·in port / dry dock·off-hire / FAT rig·digital twin — testing depth is strictly tiered to the ship's state.
- 0Destructive tests under way
- Generally no destructive testing on live systems under way — the safety constraint is written into the Rules of Engagement.
- IT/OTThe gateway as the boundary
- A core verification goal: confirming an IT-side compromise cannot cross the gateway into OT and navigation systems.
What it is
Assessing the security of a ship's IT and OT systems from a real attacker's perspective: covering the bridge/navigation systems (ECDIS, radar, GPS/GNSS, AIS), engine room/OT (propulsion, power, alarms), IT (Windows domain, email, cargo management), satcom, and the IT/OT gateways and network segmentation. The core constraint — high-risk testing is done in a safe state (alongside, at the yard, in dry dock / off-hire, or on a FAT rig, in port, or against a digital twin), and generally no destructive testing is done on live systems under way.
Who it's for
Owners, equipment makers and yards who want to know 'what would happen if someone really attacked' yet worry most that the test itself could affect ship safety.
How we do it
First map the ship's attack surface — the bridge, engine-room OT, IT, satcom VSAT and the IT-OT gateway are each a class of risk; high-risk testing runs only in safe states (alongside / dry-dock·off-hire / FAT bench / digital twin), never gambling with systems underway.
- SatcomVSAT
- BridgeECDIS · radar · GPS · AIS
- ITWindows domain · mail · cargo mgmt
- IT-OT gatewayzone & conduit boundary
- Engine-room OTpropulsion · power · alarms
High-risk testing only in safe states: alongside / dry-dock·off-hire / FAT bench / digital twin
Which tests in which state — the safety boundary spelled out first
| Ship's state | What we do | What we don't |
|---|---|---|
| Under way | Interviews, configuration and document review, passive observation | Any injection or destructive testing that could disturb systems under way |
| Alongside / in port | Controlled IT and network testing in an agreed window, stoppable at any moment | Deep exploitation of in-use OT beyond the 'block initial access' objective |
| Dry dock / off-hire | The deep-testing window: segmentation verification, IT/OT gateway penetration, measured OT checks | Any target outside the written authorization |
| FAT rig / digital twin | Offensive verification opens up: exploitation, fault injection | — an isolated environment that never touches the real ship |
※ Rules of Engagement are signed before every test: scope, window, contacts and the stop mechanism in black and white.
What we do / deliverables
- Maturity assessment (against the Identify/Protect/Detect/Respond/Recover framework)
- Network-segmentation and IT/OT gateway testing (verifying IT cannot affect OT)
- Core-network (satcom, firewalls, switches) and wireless/Wi-Fi assessment
- IT-infrastructure penetration (focus: the Windows domain, which can affect a whole fleet)
- Measured inspection of OT systems (aimed at 'blocking initial access', avoiding disturbance)
- Severity-ranked vulnerability report (impact + actionable fixes) and debrief
Why choose us
A safety-first testing philosophy — dry dock/FAT/digital-twin first, never breaking live systems under way, addressing owners' biggest concern head-on.
Fleet thinking, prioritized like an attacker — using one representative ship to find high-impact issues reproducible across the fleet, spending budget on the risks that truly shake the whole fleet.
How the engagement runs
Scope & Rules of Engagement
Confirm targets, windows and the stop mechanism in writing with the owner / maker.
Window scheduling
Match testing depth to the ship's state — high-risk items go only into dry-dock / FAT / digital-twin windows.
Execution
Proceed in attacker-priority order, stopping on any anomaly; in-use OT gets measured checks only.
Report & debrief
A severity-ranked vulnerability report, each finding with its impact and an actionable fix.
Fix verification
Targeted retesting after remediation to confirm the holes are actually closed.
Standards & basis
FAQ
Could penetration testing break on-board systems and affect sailing?
What do we need to prepare before the test?
How are the results and vulnerability details kept confidential?
Tell us what you need
The message below is pre-filled with the solution you're viewing (you can still edit it). Haishide's compliance engineering team will get back to you within 1–2 business days.
Shipboard penetration testing & red teaming