How to Map IMO MSC-FAL.1/Circ.3 to NIS2 Article 21 — Clause-by-Clause for Shipping Operators and Port Authorities

Shipping companies and port operators that closed their IMO MSC.428(98) loop — integrating cyber risk into their Safety Management Systems before 2021 — are now discovering that NIS2 Directive (EU) 2022/2555 arrives as a second, structurally different obligation. The two frameworks share a risk-based philosophy, but NIS2 adds requirements that IMO MSC-FAL.1/Circ.3 Rev.3 does not address: supply chain contractual obligations, cryptographic policies, and multi-factor authentication provisions that apply to the company’s network and information systems, including those that manage vessel operations.

Most guidance available to maritime compliance teams treats the two frameworks in parallel, listing what each requires without mapping one to the other. This guide maps each NIS2 Article 21(2) clause against the IMO five functional elements, identifies the three structural gaps where IMO guidance alone will not satisfy an NIS2 audit, and addresses the practical question vessel operators consistently raise: how to demonstrate Article 21(2)(e) compliance for ECDIS, AIS, and ballast water management systems that cannot be conventionally patched.

Which Maritime Operators NIS2 Applies To — And the Individual Vessel Exclusion

NIS2 Directive Annex I classifies water transport as a sector of high criticality, meaning qualifying entities are designated as essential entities subject to the directive’s strictest supervisory tier. Annex I identifies three distinct categories within the water transport subsector:

Entity Type	NIS2 Classification	Key Compliance Implication
Inland, sea, and coastal passenger and freight transport companies (as defined in Regulation (EC) No 725/2004)	Essential (large) / Important (medium)	Covers the operating company, not individual vessels
Port managing bodies and port facility operators (within the meaning of Article 3(1) of Directive 2005/65/EC)	Essential (large) / Important (medium)	Obligations distinct from the shipping company
Vessel Traffic Service (VTS) operators	Essential (large) / Important (medium)	Includes shore-based traffic management centres

The individual vessel exclusion. Annex I explicitly excludes “individual vessels operated individually by those companies” from scope. This does not exempt shipping companies from compliance. It means each vessel is not treated as a separately regulated entity. The company operating a fleet remains fully in scope, and its network infrastructure, operational technology management systems, and shore-based IT that connects to vessel systems all fall within the Article 21 perimeter.

Size thresholds. Large entities — 250 or more employees, or annual turnover exceeding EUR 50 million — are classified as essential entities with the highest supervisory obligations. Medium-sized entities — 50 or more employees, or annual turnover exceeding EUR 10 million — qualify as important entities. A sole-provider exception removes size thresholds entirely: if a shipping company or port operator is the only provider of a critical service in its region, NIS2 applies regardless of headcount or revenue.

Apply the decision logic in sequence: Is the entity a passenger or freight water transport company, port managing body, or VTS operator? If not, NIS2 does not apply on water transport grounds. Does it meet the medium-enterprise threshold? If not, check the sole-provider exception. Is it large? Essential entity obligations apply. Is it medium? Important entity obligations apply — lower penalty ceilings, but all Article 21 measures still required.

IMO MSC-FAL.1/Circ.3 Rev.3 — Five Functional Elements and the ISM Code Bridge

IMO MSC-FAL.1/Circ.3 Rev.3, approved by the Maritime Safety Committee at MSC 108 in May 2024, provides high-level guidelines on maritime cyber risk management structured around five functional elements adapted from the NIST Cybersecurity Framework:

• Identify — catalogue cyber threats and vulnerabilities across systems, services, assets, and data; assess likelihood and impact on safety, availability, integrity, and confidentiality
• Protect — implement risk control processes and measures, including contingency planning, to protect critical systems and maintain business continuity of shipping operations
• Detect — develop and implement activities necessary to identify a cyber event in a timely manner
• Respond — develop and implement plans to provide resilience and restore systems impaired by a cyber event
• Recover — identify and implement measures to back up and restore cyber systems necessary for shipping operations following a cyber event

The ISM Code bridge. IMO Resolution MSC.428(98), adopted in June 2017, requires that cyber risks receive appropriate attention within Safety Management Systems (SMS) as defined in the ISM Code — addressed no later than the first annual verification of the company’s Document of Compliance after 1 January 2021. For most international shipping companies, the ISM Code framework is already the primary compliance vehicle: designated persons ashore, emergency procedures, internal audits, and audit-ready documentation are all SMS components. Integrating MSC-FAL.1/Circ.3 into the existing SMS provides a natural starting point for NIS2 Article 21(2)(a) risk analysis documentation.

Why IMO alone does not satisfy NIS2. MSC-FAL.1/Circ.3 is intentionally technology-neutral and high-level. It provides no equivalent for supply chain contractual obligations under Article 21(2)(d), cryptographic requirements under Article 21(2)(h), or multi-factor authentication mandates under Article 21(2)(j). Shipping companies that equate IMO compliance with NIS2 readiness carry three structural gaps in their compliance posture, each independently examinable during a competent authority audit.

Article 21 Clause-by-Clause: Where IMO Aligns and Where Gaps Remain

The table below maps each of the ten mandatory Article 21(2) categories against the IMO functional element that most directly corresponds, with explicit notation where IMO guidance does not provide sufficient coverage for NIS2 compliance. Partial indicates the IMO element addresses the same domain but at lower specificity. Gap indicates no substantive IMO equivalent.

Art. 21(2)	Requirement	IMO Element	Coverage Assessment
(a)	Risk analysis and information security policies	Identify	Strong alignment — IMO Identify covers threat identification, vulnerability assessment, and likelihood/impact analysis across safety, availability, integrity, and confidentiality
(b)	Incident handling	Detect + Respond	Partial — IMO covers detection and response plans; NIS2 adds mandatory notification timelines under Article 23 that IMO does not address
(c)	Business continuity: backup management, disaster recovery, crisis management	Recover	Partial — IMO Recover addresses system restoration; NIS2 adds explicit governance requirements for crisis management at management body level
(d)	Supply chain security with direct suppliers and service providers	Identify (partial)	Gap — IMO identifies supply chain dependencies as assets but does not mandate contractual security requirements with each direct supplier, a specific NIS2 obligation
(e)	Security in network and IS acquisition, development, and maintenance, including vulnerability handling and disclosure	Protect	Partial — IMO Protect covers risk controls broadly; NIS2 adds specific vulnerability disclosure requirements and addresses the procurement-to-decommission lifecycle
(f)	Policies to assess effectiveness of cybersecurity risk-management measures	Ongoing process (general)	Partial — MSC-FAL.1/Circ.3 describes cyber risk management as an ongoing process with feedback mechanisms but does not require formal documented effectiveness assessment procedures
(g)	Cyber hygiene practices and cybersecurity training	Protect (personnel)	Partial — IMO acknowledges human factors under Protect; NIS2 mandates explicit training programmes and documented hygiene standards
(h)	Cryptography and encryption policies	None	Gap — MSC-FAL.1/Circ.3 is technology-neutral; cryptographic requirements are not addressed in the IMO circular
(i)	Human resources security, access control, asset management	Identify + Protect	Partial — IMO addresses asset identification and protective access controls; NIS2 requires formal HR security procedures integrated with access control policies
(j)	Multi-factor authentication, secured communications, secured emergency systems	None	Gap — MSC-FAL.1/Circ.3 does not address MFA or secured voice/video/text protocols; NIS2 requires these where appropriate

The three gaps in practice. Article 21(2)(d) supply chain security requires shipping companies to assess the cybersecurity practices of each direct supplier — not just identify them as dependencies. In practical terms, this means security clauses in contracts with ECDIS update vendors, satellite communication providers, remote monitoring suppliers, and port state control software vendors. Article 21(2)(h) cryptography requires a documented policy even where full encryption is not technically feasible in OT environments — the policy must acknowledge this and document the compensating approach. Article 21(2)(j) MFA is qualified by “where appropriate,” but for shore-based administrative systems and remote access paths to vessel management infrastructure, it has become a baseline expectation that competent authorities examine.

Vessel OT Under Article 21(2)(e): ECDIS, AIS, and Ballast Water Management

Article 21(2)(e) addresses “security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure.” For maritime operators, the practical challenge is that several critical vessel systems were deployed before cybersecurity was a design consideration and cannot be patched through conventional software update processes — yet they remain within Article 21(2)(e) scope because they are networked information systems affecting operational continuity.

ECDIS. ECDIS units on vessels operating today commonly run Windows XP or Windows 7 — operating systems that reached end-of-life in 2014 and 2020 respectively and no longer receive security patches. Third-party applications on ECDIS workstations, including remote desktop tools, web servers, and update clients, are frequently outdated and contain known vulnerabilities. A compromised ECDIS can propagate malware across interconnected bridge workstations and, in documented attack scenarios, allow remote modification or erasure of navigational chart data. The patch-and-update lifecycle that Article 21(2)(e) assumes does not operate as designed for most installed ECDIS units.

AIS. The Automatic Identification System operates over VHF radio using the NMEA 0183 protocol, which was designed without any authentication mechanism. The system broadcasts vessel identity, position, heading, and speed to all receivers in range — with no cryptographic verification that messages originate from the claimed vessel. Documented attack vectors include false position broadcasting, identity hijacking, and collision alarm manipulation through fabricated AIS messages. The Black Sea GPS spoofing incidents — in which more than 20 vessels simultaneously reported false positions at inland airports — demonstrated what coordinated GNSS and AIS manipulation achieves operationally. AIS receivers cannot be upgraded to add authentication without hardware replacement.

Ballast water management systems. Modern vessels carry ballast water management systems (BWMS) under the IMO Ballast Water Management Convention. BWMS typically communicate with vessel control networks via Modbus-TCP or CAN bus — industrial protocols with no native encryption or authentication. These systems directly affect physical vessel stability operations, placing them within the network and information systems scope of Article 21(2)(e). BWMS are often proprietary systems from single manufacturers with multi-year update cycles and limited remote patching capability, creating a vulnerability profile comparable to legacy ICS equipment in other industrial sectors.

GMDSS. Global Maritime Distress and Safety System terminals handle emergency communications and, in integrated bridge configurations, share network segments with other vessel systems. In documented risk assessments, GMDSS exposure includes jamming, distress signal spoofing, and — where terminals share NMEA 0183 connections with other vessel systems — potential malware propagation through shared network segments.

Compensating Controls That Satisfy NIS2 When Patching Is Not Possible

Article 21(1) requires “appropriate and proportionate technical, operational and organisational measures” calibrated to the entity’s risk exposure, size, and the likelihood and severity of incidents. This proportionality provision is the legal basis for compensating controls: documented measures that reduce risk to an acceptable level where conventional patch management is not technically feasible. NIS2 does not require patching in all cases; it requires demonstrated, documented vulnerability management with an audit trail showing management judgment was applied.

Zone-based network segmentation. The most widely applicable compensating control for vessel OT is three-zone segmentation: a Global Ship Zone (external communications — satellite, VSAT, and port state connections), a Ship Control Zone (vessel management systems and bridge communications), and a Ship System Zone (OT — ECDIS, AIS, and BWMS). Traffic between zones passes through monitored DMZ boundaries with strict filtering rules. For Article 21(2)(e) documentation, the segmentation architecture, zone boundary definitions, and inter-zone traffic rules must be formally recorded, version-controlled, and reviewed at defined intervals.

Device whitelisting for legacy protocols. Systems communicating via NMEA 0183 interact with a defined and predictable set of devices. Implementing a device whitelist — authorising specific sensors, receivers, and workstations to communicate with each other — provides an authentication overlay that the protocol cannot supply natively. Devices attempting unauthorised communication trigger anomaly alerts. Whitelists must be documented and reconciled against physical hardware inventories as part of access control and asset management under Article 21(2)(i), creating dual-purpose documentation that satisfies both the asset register requirement and the vulnerability management evidence Article 21(2)(e) needs.

Anomaly detection without protocol upgrades. Where cryptographic retrofitting is impractical for legacy OT, behavioural anomaly detection provides a compensating control that operates independently of device-level patching. Machine learning models trained on normal vessel operational patterns can identify suspicious deviations — unexpected AIS position jumps, abnormal ECDIS query volumes, or unusual Modbus-TCP traffic — without any modification to the legacy device. Gaussian process models have been applied in peer-reviewed maritime research for this purpose, satisfying the Detect functional requirement while contributing to Article 21(2)(e) vulnerability surveillance where patching is not possible.

Risk acceptance documentation. Where compensating controls reduce but do not eliminate residual risk, NIS2 compliance requires a formal risk acceptance record: the specific vulnerability, the compensating controls in place, the residual risk level, the management sign-off accepting that risk, and the scheduled review date. Without this documentation, an unpatched ECDIS running Windows XP is a compliance gap. With it — combined with zone segmentation, device whitelisting, and anomaly detection — it is a managed and documented risk that satisfies Article 21(2)(e) vulnerability handling at audit.

Enforcement, Penalties, and Management Liability for Maritime Operators

Article 34 of NIS2 sets maximum fines for essential maritime entities at EUR 10 million or 2% of total worldwide annual turnover, whichever is higher. For important maritime entities, the ceiling is EUR 7 million or 1.4% of worldwide annual turnover. For large shipping groups and major port operators, the turnover-based calculation typically produces figures substantially above the fixed cap — a group reporting EUR 1.5 billion in annual revenue faces essential entity exposure of EUR 30 million.

Beyond financial penalties, competent authorities may issue binding instructions requiring specific remediation actions within defined timeframes, mandate security audits at the entity’s expense, suspend or revoke relevant certifications or authorisations, and — for essential entities — temporarily prohibit individuals from exercising management functions. This personal exposure makes the accountability chain concrete for ship operators, port directors, and IT leadership alike.

NIS2 Directive (EU) 2022/2555 establishes management body accountability explicitly. Management bodies are required to approve the cybersecurity risk-management measures adopted by the entity, oversee their implementation, and may be held personally liable for infringements attributable to failure to discharge this duty. This transfers cybersecurity from an IT department function to a board-level governance responsibility — consistent with Article 21(2)(g), which requires that management bodies themselves receive cybersecurity training sufficient to identify risks and assess their impact.

Incident reporting under Article 23. Maritime operators experiencing a significant cybersecurity incident must submit an early warning to the national competent authority within 24 hours of becoming aware. A formal incident notification follows within 72 hours, including severity assessment and indicators of compromise where available. A final report is due no later than one month after the notification. Navigation incidents, cargo system failures, or port operational disruptions caused by cyber events fall within the significant incident category that Article 23 incident notification reporting covers.

Port Infrastructure — Separate NIS2 Obligations Beyond the Vessel

Port managing bodies and port facility operators carry NIS2 obligations that are structurally separate from those of the shipping companies whose vessels call at their facilities. A port authority’s compliance programme must address the systems it operates, and supply chain security under Article 21(2)(d) extends to the cybersecurity practices of the terminal operators and shipping companies with which it has direct service relationships — creating a perimeter that each party manages independently but must document toward each other.

Port infrastructure OT includes cargo terminal management systems — automated crane control, container tracking, berth scheduling — as well as customs integration platforms and port management information systems. These systems often have long refresh cycles and on-premises deployment, connected to both internal port networks and external bodies including customs, border control, and vessel traffic management. Ransomware attacks on major container terminals have produced multi-day cargo processing outages, demonstrating the operational impact that port OT compromise causes at scale. Article 21(2)(e) vulnerability handling applies to these systems with the same logic as vessel OT: documented management of known vulnerabilities, with compensating controls and risk acceptance records where patching is constrained.

Vessel Traffic Service operators face a specific obligation: their shore-based traffic management systems, radar installations, AIS aggregation platforms, and VHF communication infrastructure fall within NIS2 scope. The disruption of a VTS during high-density shipping traffic is precisely the scenario the essential entity tier is designed to protect against. VTS operators should verify that their network security documentation addresses scenarios involving spoofed or jammed AIS data — a realistic threat vector where VTS systems interface directly with the maritime radio environment.

ISPS Code integration. Port facilities already operate under the ISPS Code, which requires Port Facility Security Plans, designated security officers, and regular security assessments. NIS2 extends this existing security management structure into the cyber domain. Where ISPS assessments have already mapped physical dependencies — power supply, communications, access control — these provide the starting point for the Article 21(2)(a) risk assessment. The objective is integration rather than duplication: a single risk register covering both physical and cyber threats satisfies both frameworks more efficiently than parallel processes.

Maritime NIS2 Compliance Checklist

The following checklist maps the ten Article 21(2) obligations to maritime-specific implementation actions. Shipping companies that have completed MSC-FAL.1/Circ.3 SMS integration can use the IMO Baseline column to identify where existing documentation provides a starting point versus where new work is required.

Art. 21(2)	Maritime Implementation Action	IMO Baseline	Owner	Effort
(a)	OT/IT risk assessment covering ECDIS, AIS, BWMS, VSAT, and shore-based systems; documented in SMS-linked register	Extends IMO Identify	CISO / DPA	High
(b)	Incident response procedures with 24h/72h/1-month Article 23 notification chain; integrated with SMS emergency procedures	Extends IMO Detect/Respond	IT / Legal	Medium
(c)	Tested backup and disaster recovery for shore-based and vessel-management systems; defined RTOs per system type	Extends IMO Recover	IT / CISO	Medium
(d)	Review and update contracts with ECDIS vendors, satellite providers, and port service providers to include cybersecurity clauses	No IMO equivalent	Legal / Procurement	High
(e)	OT vulnerability register; zone-based segmentation architecture; risk acceptance records for unpatched legacy systems	Extends IMO Protect	CISO / IT	High
(f)	Annual effectiveness review of all security measures; linked to SMS internal audit cycle	Partial IMO equivalent	CISO / Board	Low
(g)	Mandatory cyber hygiene training for shore-based and seafaring personnel; board members included; completion records maintained	Extends IMO Protect	HR / IT	Low
(h)	Cryptography policy documenting which systems use encryption, which cannot and why, and key management procedures	No IMO equivalent	CISO / IT	Medium
(i)	Formal access control for shore-based systems and all remote vessel access connections; maintained asset register	Partial IMO equivalent	IT / HR	Medium
(j)	MFA for all remote vessel access and shore-based administrative systems; documented exceptions where technically not feasible	No IMO equivalent	IT / CISO	Medium

Shipping companies that have completed IMO MSC.428(98) SMS integration will find items (a), (b), (c), (f), and (g) require extension rather than creation. Items (d), (h), and (j) require new work regardless of IMO compliance status. Item (e) is the highest-effort obligation: the OT vulnerability register and compensating control documentation for unpatched vessel systems. For step-by-step guidance on the vulnerability and patch management documentation process, the dedicated guide on this site covers each requirement in full.

Key Takeaways

IMO MSC-FAL.1/Circ.3 Rev.3 and NIS2 Article 21 share a risk-based framework structure, but NIS2 adds three obligations for which IMO guidance provides no equivalent: supply chain contractual security requirements under Article 21(2)(d), cryptographic policies under Article 21(2)(h), and multi-factor authentication governance under Article 21(2)(j). Shipping companies treating IMO compliance as NIS2 readiness carry these three gaps into every competent authority audit.

The practical starting point for most maritime compliance teams is Article 21(2)(e): building the OT vulnerability register for ECDIS, AIS, BWMS, and communication systems; implementing zone-based segmentation as the primary compensating control; and creating risk acceptance records with management sign-off for unpatched legacy systems. This is the evidence base that makes the difference between a managed risk and an enforcement gap. The remaining Article 21 measures — supply chain contract review and the cryptography policy — can proceed in parallel once the OT vulnerability documentation is in place.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Sources

1. NIS2 Directive Article 21 — Cybersecurity Risk-Management Measures — nis-2-directive.com
2. Maritime Cyber Risk Management — IMO MSC-FAL.1/Circ.3 Rev.3 — IMO.org
3. Maritime Cybersecurity: A Comprehensive Review — arXiv (2024)
4. NIS2 Directive in the Maritime Sector — Zbroja Adwokaci
5. NIS 2 Directive, Water Transport — maritime-cybersecurity.com
6. NIS2 Annex I.2: Transport Sector Cybersecurity Requirements — AuditFront