A port is a chain of interdependent IT, OT and shared data systems, and a cyber incident at any link can stop containers moving for days. The 2023 incidents at the Port of Nagoya and DP World Australia, and the 2017 NotPetya outbreak at Maersk, showed that the usual failure is not a crane being hijacked but a terminal operating system or corporate network going down and taking cargo flows with it. This guide covers the systems that matter (port community systems, terminal operating systems, cranes, gates and vessel traffic services), the regulatory baseline including IMO guidance and the US Coast Guard cybersecurity rule, how to segment and secure terminal OT, and how to plan for recovery. It is written for security teams at port authorities, terminal operators and logistics companies, and for the OT and operations engineers who work with them.
Key takeaways
- Availability is the main risk. Recent port incidents stopped operations through ransomware or forced disconnection of IT, not through direct manipulation of cranes.
- The port community system is shared infrastructure. A PCS exchanges vessel, cargo and dangerous goods data between many organisations, so its machine-to-machine interfaces and accounts need the same care as a payment system.
- Terminal OT has a large vendor footprint. Cranes, automated gates and yard equipment are often remotely supported by manufacturers, which makes third-party access the key OT control.
- US rules are now mandatory and dated. The Coast Guard rule in 33 CFR Part 101 subpart F took effect on 16 July 2025, with training due by 12 January 2026 and plans and assessments due by 16 July 2027.
- Recovery is a logistics problem. Plan manual gate and yard procedures, data reconciliation and communication with shipping lines and hauliers, not only server restores.
The port and logistics system landscape
ENISA's 2019 port cybersecurity report describes the main systems and stakeholders. They differ sharply in owner, exposure and impact.
| System | Owner (typical) | What it does | Main cyber concern |
|---|---|---|---|
| Port community system (PCS) | Port authority or a community company | Single window sharing arrival and departure data, crew lists, customs and dangerous goods declarations between stakeholders | Data manipulation or theft through web flaws, weak access rights or insecure machine-to-machine exchanges |
| Terminal operating system (TOS) | Terminal operator | Plans berth, yard and equipment moves, container status and release | Ransomware stops all terminal operations; cargo release fraud |
| Cranes (ship-to-shore, yard) | Terminal operator, maintained by manufacturer | Load and unload vessels, stack containers | Remote vendor connections, PLC and drive manipulation, safety impact |
| Gate and access control | Terminal operator | Plate readers, badge and barcode readers, automatic gates, appointment systems | Container theft, haulier credential abuse, gate shutdown |
| VTS and VTMIS | Port or maritime authority | Monitor and manage vessel traffic | Safety of navigation, GNSS and AIS dependence |
| Corporate IT and cloud | Each organisation | Email, ERP, booking, invoicing, identity | Initial access and lateral movement into operations |
Freight forwarders, shipping lines, hauliers, customs and rail operators all connect into these systems, so a port is better treated as a supply chain of digital trust than as a single network. For the vessel side, see the Maritime Cybersecurity Guide.
Regulatory baseline
| Instrument | Applies to | Status (checked October 2026) | What it asks for |
|---|---|---|---|
| IMO MSC-FAL.1/Circ.3/Rev.3, Guidelines on maritime cyber risk management | Primarily ships and shipping companies; ports indirectly through ship-port interfaces | Issued 4 April 2025, supersedes the interim guidelines in MSC.1/Circ.1526; non-mandatory | Six concurrent functional elements: Govern, Identify, Protect, Detect, Respond, Recover; refers to NIST CSF 2.0 and IAPH port guidelines |
| IMO Resolution MSC.428(98) | Ship operators under the ISM Code | Adopted June 2017; cyber risks to be addressed in safety management systems by the first annual DOC verification after 1 January 2021 | Cyber risk in the SMS |
| US Coast Guard final rule, 33 CFR Part 101 subpart F | US-flagged vessels, facilities and OCS facilities with security plans under 33 CFR parts 104, 105 and 106 | Effective 16 July 2025; incident reporting from that date; training by 12 January 2026; Cybersecurity Officer, assessment and plan by 16 July 2027. The Coast Guard sought comment on a further 2 to 5 year delay for US-flagged vessels | Cybersecurity Officer, Cybersecurity Plan, assessment, penetration testing, MFA, segmentation, KEV mitigation, drills and incident reporting to the National Response Center |
| US Coast Guard MARSEC Directive 105-4 | Owners and operators of PRC-manufactured ship-to-shore cranes | Issued February 2024; security-sensitive, obtained from the Captain of the Port | Cyber risk management actions for those cranes |
| IAPH Cybersecurity Guidelines for Ports and Port Facilities | Port executives | First edition submitted to IMO (MSC 104/7/1) in July 2021 | Leadership, risk assessment, defence in depth, training, information sharing |
| EU NIS2 Directive | Managing bodies of ports, port facility operators and VTS operators in EU member states (transport sector) | Applies through national transposition | Risk management measures, incident reporting, management accountability |
The Coast Guard rule in practice
- Account security (101.650(a)): automatic lockout, change of default passwords, minimum password strength, least privilege for privileged accounts, separate credentials on critical systems and revocation when users leave.
- MFA (101.650(a)(4)): required on password-protected IT systems and remotely accessible OT; where not feasible, documented compensating controls.
- Segmentation and monitoring (101.650(h)): IT and OT segmented, with logging and monitoring of all connections between them; no OT directly connected to the public internet unless operationally required.
- Vulnerabilities: the Cybersecurity Officer must ensure known exploited vulnerabilities are mitigated without delay; the assessment covers KEV patching or compensating controls.
- Training (101.650(d)): everyone with IT or OT access, contractors included; new staff within 5 days of access and no later than 30 days of hiring.
- Exercises (101.635): drills at least twice per calendar year and an exercise at least once per calendar year, no more than 18 months apart.
Read the current eCFR text before relying on dates; see the NIS2 Directive Guide for the EU side.
Securing terminal OT and cranes
Terminal OT follows industrial control system practice, with some port-specific twists: equipment is spread over a large yard, often linked by wireless networks, and maintained remotely by manufacturers. ENISA's attack scenarios include an infected maintenance laptop spreading malware to OT and causing cranes or bridges to move unexpectedly.
- Zones and conduits: separate crane control, yard equipment, gates, CCTV and building systems into their own zones, with the TOS interface as a defined conduit. See the IEC 62443 Guide.
- Vendor remote access: crane and automation suppliers may control, service and program equipment remotely. Disable standing connections such as cellular modems, route support through a brokered, recorded jump host, and require approval per session (ATT&CK for ICS T0822 External Remote Services, T0886 Remote Services). See the Third-Party Access Guide.
- Maintenance laptops and media: dedicated, managed engineering laptops for OT, scanned media kiosks and controls on physical ports, as the Coast Guard rule also requires.
- Wireless: yard and crane wireless links carry control traffic; use WPA3-Enterprise or equivalent strong authentication, separate SSIDs per zone and monitor for rogue access points.
- Safety systems stay independent: emergency stops and anti-collision systems must not depend on networks that IT incidents can take down.
- Asset inventory: list every PLC, drive, HMI and remote access path, with firmware versions. See the OT Security Guide.
Port community systems and data exchange
A PCS is a high-value target because it connects many organisations and holds data that releases cargo. ENISA lists PCS compromise for data manipulation or theft as one of four main port attack scenarios, alongside targeted cargo theft, ransomware shutdown and OT compromise.
- Machine-to-machine interfaces: EDI, API and message queue links between the PCS, TOS, customs and shipping lines run on certificates, API keys or service accounts. Inventory them, give each a named owner, scope them to the minimum message types and rotate them.
- Stakeholder accounts: forwarders and hauliers log in from outside the port. Require MFA for every external user and federate where the stakeholder has its own identity provider.
- Cargo release controls: container release PINs and codes are a classic cargo theft target. Prefer one-time release authorisations tied to a verified haulier identity over static PINs shared by email.
- Web application security: PCS portals are public-facing; test against OWASP guidance and patch quickly (ATT&CK T1190 Exploit Public-Facing Application).
- Logging: log every change to cargo status, release and dangerous goods data with the identity that made it, so manipulation can be detected and reconstructed.
Where machine identities carry this traffic, see the Service Account Security Guide.
Lessons from incidents
| Incident | What happened (as reported) | Lesson |
|---|---|---|
| Maersk and NotPetya, June 2017 | Maersk's chairman said in January 2018 that the company reinstalled 4,000 servers, 45,000 PCs and 2,500 applications in about 10 days, at an estimated cost of 250 to 300 million US dollars | A supply chain malware outbreak (ATT&CK T1195.002) on a flat global network can take out a shipping company's IT; offline identity and backup recovery decides the recovery time |
| Port of Nagoya, July 2023 | Ransomware hit the Nagoya Port Unified Terminal System, which controls all container terminals at a port handling about a tenth of Japan's trade; container loading and unloading by trailer was cancelled | A single shared terminal system is a single point of failure; plan manual fallbacks |
| DP World Australia, November 2023 | The operator disconnected its systems from the internet after detecting the attack; terminals in Sydney, Melbourne and other cities stopped for about three days and nearly 30,000 containers were reported stranded | Containment by disconnection stops landside operations too; pre-plan how gates and hauliers work while IT is isolated |
For response planning see the OT Incident Response Guide and the Ransomware Response and Recovery Guide.
How to implement: a phased approach
- Map the operation (months 0-2): list business processes (vessel call, discharge, yard, gate out, rail) and the systems, vendors and data flows each depends on. This is also the core of the Coast Guard Cybersecurity Assessment.
- Close the internet-facing gaps: find OT and remote access exposed to the internet, remove or broker it, and enforce MFA on VPN, remote desktop and external PCS users.
- Segment IT from OT: introduce a DMZ between the TOS and crane, gate and yard OT, starting in monitor mode (log flows for 30 days), then enforce allow rules zone by zone. Keep the previous rule set ready to restore if a crane interface fails during a vessel window.
- Control third-party and machine access: move vendor sessions to a brokered jump host; inventory PCS and TOS integration credentials.
- Build recovery: immutable backups of TOS and PCS databases and configurations, offline copies of directory recovery material, OT configuration backups, and documented manual gate and yard procedures. See the Backup Security and Immutable Backup Guide.
- Exercise with the community: run drills that include shipping lines, hauliers and customs; meet the twice-yearly drill and annual exercise cadence where the US rule applies.
- Monitor and improve: deploy OT network monitoring at IT/OT conduits and review findings in the annual plan audit.
Decision guidance
- Port authority vs terminal operator: the authority usually owns the PCS, VTS and common infrastructure and should lead community exercises and information sharing; the terminal operator owns TOS, cranes and gates and carries most OT risk. Agree in writing who notifies whom.
- Disconnect vs contain in place: full internet disconnection, as at DP World Australia, is decisive but stops landside business. Pre-define smaller containment options (isolating corporate IT while keeping the TOS to OT conduit alive) and decide in advance who can authorise each.
- Remote vendor support vs on-site only: remote support speeds up crane repairs; keep it, but brokered and time-bound. Block it entirely only for equipment where safety risk outweighs downtime.
- Small vs large operators: a small inland terminal can rely on managed services, MFA, segmentation and tested backups; a global operator needs standard OT architecture across terminals, central monitoring and separate identity tiers so that one compromised domain does not reach every port.
Detection and measurement
- Monitor: all IT to OT connections (a Coast Guard rule requirement), new remote sessions to crane and gate controllers, PLC program downloads or mode changes, TOS changes to container release status, logins by PCS integration accounts from unexpected sources, and outbound traffic from OT to the internet.
- Report: in the US, reportable cyber incidents go to the National Response Center without delay. Pre-write the reporting template.
| Metric | Target direction | Why it matters |
|---|---|---|
| Internet-exposed OT or remote access services | Zero | Most direct path into terminal operations |
| Vendor OT sessions that were brokered and recorded | 100% | Cranes and automation have heavy vendor access |
| External PCS and remote IT users with MFA | 100% | Required by the US rule; stops credential reuse |
| Median days to mitigate KEV-listed vulnerabilities on port systems | Down | KEV mitigation without delay is an explicit duty |
| Hours to resume gate operations in the last exercise | Down, against a target set by the business | Measures real recovery, not just backup success |
Common failure patterns
- One terminal system for everything: a single TOS or shared terminal platform with no tested manual fallback, so an incident stops every berth, as at Nagoya.
- Flat corporate network reaching operations: ransomware moves from email to the TOS servers because there is no tiering or segmentation (ATT&CK T1486 Data Encrypted for Impact).
- Always-on vendor modems: cellular or VPN links installed with a crane for warranty support and never inventoried.
- Static, shared credentials in the PCS: integration accounts and release PINs shared by email between stakeholders and never rotated (ATT&CK T1078 Valid Accounts).
- Exercises that stop at IT: recovery plans that restore servers but never test how gates, hauliers and vessel planning work in the meantime.
- Treating the rule as paperwork: a Cybersecurity Plan written for approval that does not match the real network, which penetration testing will expose.
Framework mapping
| Topic | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | ATT&CK (enterprise and ICS) |
|---|---|---|---|
| Asset and data flow inventory | ID.AM-01 | CM-8 | n/a |
| Segmentation of IT and OT | PR.IR-01 | SC-7 | T0886 Remote Services |
| Vendor and third-party access | GV.SC-01 | SR-3, AC-17 | T0822 External Remote Services, T1199 Trusted Relationship |
| Identity, MFA and least privilege | PR.AA-01, PR.AA-05 | IA-2, AC-6 | T1078 Valid Accounts, T0859 Valid Accounts (ICS) |
| Vulnerability mitigation | PR.PS-02 | RA-5 | T1190, T0866 Exploitation of Remote Services |
| Monitoring IT/OT connections | DE.CM-01 | SI-4 | T0831 Manipulation of Control |
| Backup and recovery | PR.DS-11 | CP-9 | T1486, T0828 Loss of Productivity and Revenue |
| Coordinated response | RS.MA-01 | IR-4 | n/a |
Practitioner checklist
- Map each port process to the systems, vendors and data flows it depends on.
- Remove or broker every internet-exposed OT and remote access service.
- Enforce MFA for remote IT access, remotely accessible OT and external PCS users.
- Segment corporate IT, TOS and terminal OT, and log every IT to OT connection.
- Replace standing crane and automation vendor connections with brokered, recorded sessions.
- Inventory PCS and TOS integration credentials, assign owners and rotate them.
- Keep immutable backups of TOS, PCS and OT configurations, and test restore.
- Document and exercise manual gate, yard and vessel planning procedures with community partners.
- Track Coast Guard rule dates (training, plan, assessment) where 33 CFR Part 101 subpart F applies.
- Pre-write incident reporting templates for the National Response Center and national CSIRTs.
Standards and references
- eCFR: 33 CFR Part 101 Subpart F, Cybersecurity
- Federal Register: Cybersecurity in the Marine Transportation System (final rule)
- US Coast Guard: Final rule implementation timeline
- IMO: MSC-FAL.1/Circ.3/Rev.3 Guidelines on Maritime Cyber Risk Management
- IMO: Maritime cyber risk
- ENISA: Port Cybersecurity, Good practices for cybersecurity in the maritime sector
- IAPH: Cybersecurity Guidelines for Ports and Port Facilities (MSC 104/7/1)
- NIST: Cybersecurity Framework 2.0
Related NHI Mgmt Group resources: OT Security Guide · IEC 62443 Guide · Software Supply Chain Security Guide · Maritime Cybersecurity Guide · Incident Response Guide. This guide summarises the US Coast Guard cybersecurity rule, IMO guidance and related port security frameworks and is not legal advice.