Cyber Security on Board
Cyber risk management within the Safety Management System
Learning objectives
- Describe the IMO regulatory framework on cyber risk management (Resolution MSC.428(98)).
- Distinguish IT and OT systems on board and understand the logic of network segregation.
- Recognise the main cyber attack vectors at a conceptual level.
- Apply a cyber risk management cycle (govern, identify, protect, detect, respond, recover).
- Manage the response path to an onboard cyber incident.
- Contribute to an organisational culture of cyber security awareness.
The regulatory framework: Resolution MSC.428(98)
Module objectiveDistinguish the binding ISM Code/SMS basis from the role of MSC.428(98) and current IMO Rev.4 guidance in structuring cyber risk management.
The current IMO document is MSC-FAL.1/Circ.3/Rev.4, issued on 28 May 2026 after FAL 50 and MSC 111. It is high-level guidance with six functional elements and organisational, operational and technical controls.
For ships subject to the ISM Code, the ISM Code and flag implementation provide the mandatory basis for management through the SMS. MSC.428(98) addresses Administrations and brought cyber risk into SMS verification; Rev.4 explains how to structure it.
MSC.428(98) encourages Administrations to ensure cyber risks are addressed in the SMS no later than the first annual DOC verification after 1 January 2021. For ships in scope, the mandatory basis is the ISM Code through SOLAS IX and flag implementation; class rules form a separate layer. An audit finding must connect evidence to an applicable requirement, without treating guidance as an independent obligation.
Key takeaways
- MSC.428(98) addresses Administrations; practical verification occurs through the SMS and applicable regime.
- The current IMO source is
MSC-FAL.1/Circ.3/Rev.4, dated 28 May 2026. - Cyber risk management integrates safety and security management; it is not a separate IT file.
The regulatory layers: who is bound to what, and from when
Module objectiveMap IMO/ISM, guidance, class rules and NIS2 to their respective addressees, scope, verification and reporting windows.
ISM/SMS, IMO guidance, class rules and EU/national law have different addressees and legal character. One plan may coordinate them but does not make their obligations identical.
NIS2: establish scope
Annex I of Directive (EU) 2022/2555 includes inland, sea and coastal passenger and freight water transport companies, port managing bodies and their port facilities, and VTS operators. Individual vessels operated by the companies are excluded as addressee entities. Check activity, size (generally at least medium-sized), establishment, Article 2 exceptions, identification and national transposition: a ship manager is not automatically included merely because it manages a vessel.
Significance and notifications — Article 23
An incident is significant if it has caused or is capable of causing severe operational disruption of services or financial loss to the entity, or has affected or is capable of affecting other persons by causing considerable material or non-material damage.
- Without undue delay and within 24 hours of becoming aware of the significant incident: early warning to the CSIRT or competent authority.
- Without undue delay and within 72 hours of that same awareness: notification with an initial severity and impact assessment and available indicators of compromise.
- Intermediate report on request.
- Within one month of the incident notification: final report. If the incident is ongoing, provide a progress report at that deadline and a final report within one month of handling it.
Rev.4, §3.5.5.1, recommends reporting to necessary parties within Administration-defined time frames; it does not set a single global cyber deadline. The company matrix must include applicable flag, safety/security, ISM §9.1, class, NIS2/national, privacy, insurance and contractual obligations. Internal reporting does not replace external notifications.
Key takeaways
- The SMS, class and NIS2 do not have the same addressee or legal character.
- NIS2 applies to entities in scope, not automatically every ship manager or individual vessel.
- The reporting matrix must combine flag, class, national law, contracts and insurance.
IT and OT systems: an essential distinction
Module objectiveRecognise onboard IT, OT, dependencies and conduits, linking cyber criticality to operational and safety consequences.
Understanding the distinction between IT (Information Technology) and OT (Operational Technology) systems is the first step towards effective cyber risk management on board, since the two categories require different protection approaches.
| Category | Typical examples on board |
|---|---|
| IT (Information Technology) | Email, administrative systems, communications with the office, crew entertainment |
| OT (Operational Technology) | ECDIS, GPS, engine automation systems, cargo management systems |
Classification depends on function and interdependencies. Risk includes loss of confidentiality, integrity and availability from configuration, maintenance or update errors as well as intentional actions. Competent IT/OT personnel should verify segmentation using tests compatible with operational safety; DPA and HSEQ monitor its management within the SMS according to their assigned functions.
Key takeaways
- IT primarily uses data and communications; OT controls or monitors physical processes.
- Asset classification depends on function and dependencies, not device type alone.
- Inventory, topology and flows are prerequisites for verifiable segmentation.
From segregation to design: IEC 62443 and the class rules
Module objectiveInterpret zones, conduits and E26/E27 deliverables to verify design requirements, contractual responsibilities and handover evidence.
IEC 62443 organises industrial systems into zones and conduits. Segmentation is risk-based: architecture, inventory, flows, dependencies, access and security levels must be verifiable.
IACS UR E26 addresses the integrated ship; E27 addresses onboard systems and equipment. They are class requirements applied according to ship type, tonnage, contract date, scope and class-society rules, not one identical direct duty for yard, supplier and owner.
Deliverables, topologies, configurations, tests and handover responsibilities remain lifecycle assets.
IEC 62443-3-2 assigns target security levels (SL-T) to zones and conduits based on risk assessment. Component security capabilities are addressed separately, for example in IEC 62443-4-2. These are not ISPS security levels 1, 2 and 3. Responsibility for inventories, topology, configurations, integration, tests and handover must follow applicable E26/E27 provisions, contracts and class rules.
Key takeaways
- E26 addresses the integrated ship; E27 addresses onboard systems and equipment.
- Scope depends on ship type, tonnage, contract date and class rules.
- Inventories, topologies, configurations and tests are operational assets to maintain after delivery.
Examples of attack vectors
Module objectiveRecognise attack vectors and other incident causes, linking them to vulnerabilities, exposed systems and preventive controls.
At a conceptual level, it is useful for non-specialist personnel to know examples of attack vectors, to recognise warning signs and adopt prudent behaviours, without going into operational technical details that fall outside the scope of this course.
| Category | General description |
|---|---|
| Email phishing | Deceptive communications that induce the user to provide credentials or execute malicious code |
| Uncontrolled removable devices | Unverified USB sticks or external devices that can introduce malicious code |
| Remote maintenance access | External connections for technical assistance that, if not adequately controlled, can be exploited |
| Unprotected wireless networks | Onboard or in-port wireless access points lacking adequate protection |
Training, technical controls and procedures complement each other: assigning most incidents to one cause is not justified without relevant evidence. Include errors, configuration, maintenance and supply-chain risks.
Key takeaways
- Email, removable media, remote access and wireless are examples, not a complete list.
- A vector describes entry; vulnerabilities and consequences depend on architecture and privilege.
- Behaviour, configuration, maintenance and supply chain must be assessed together.
The cyber risk management cycle
Module objectiveApply the six Rev.4 elements as a continuous system of governance, identification, protection, detection, response and recovery.
MSC-FAL.1/Circ.3/Rev.4 uses six concurrent and continuous elements: Govern, Identify, Protect, Detect, Respond and Recover. Govern defines strategy, expectations, policy, roles, resources, continuity and crisis management; the others translate governance into inventory, protection, detection, response and recovery.
NIST CSF 2.0 uses the same six-function architecture. Govern is therefore not an external addition to the current IMO model, although the frameworks remain distinct in nature and application.
Key takeaways
- Govern is now an element of both IMO Rev.4 and NIST CSF 2.0.
- The six elements operate concurrently and generate continuous feedback.
- Strategy, accountability and resources must sustain technical controls.
Access management and updates
Module objectiveDefine risk-based controls for identity, privilege, third-party access, patching and change without compromising OT availability and safety.
Access and update management support protection of critical systems and must be compatible with operational continuity.
General good practice principles
- Restrict access to critical OT systems to personnel who have an actual operational need.
- Promptly revoke the access of personnel who disembark or leave the company.
- Maintain an up-to-date inventory of all onboard digital systems and their update status.
- Verify the identity and authorisation of every external technician before allowing maintenance access, remote or physical.
External technicians for the maintenance of specific equipment (for example the engine or automation system manufacturer) often require access to critical OT systems: verifying their identity and authorisation and limiting access to the strictly necessary time is an essential protective measure that is often neglected for operational convenience.
Use individual credentials, change default passwords, separate privileged accounts and enforce least privilege; provide MFA where appropriate and controlled emergency access. Supplier access should be approved, time-limited, logged and closed after the work. For OT updates, assess vulnerabilities, manufacturer compatibility and dependencies: test, approve an operational window, prepare backups and rollback, then verify operation. If a patch cannot be applied, document residual risk, compensating measures and review. Avoid unvalidated automatic updates or intrusive scans on critical systems.
Key takeaways
- Individual accounts and separated privileges make actions attributable.
- Remote access should be authorised, time-limited, monitored and verifiably closed.
- OT patches and configurations require compatibility, testing, approval and management of change.
Anomaly detection
Module objectiveCombine technical monitoring, operational baselines and crew reporting to identify anomalies without confusing a failure with an attack.
The ability to promptly recognise an anomaly, before it escalates into a full-blown incident, depends both on technical tools and on the crew's awareness in recognising unusual system behaviour.
General warning signs (conceptual level)
- Abnormal behaviour or unexpected slowdown of critical systems with no apparent cause.
- Unsolicited and unexpected access requests or communications from apparently legitimate sources.
- Unauthorised changes to system configurations detected during routine checks.
As with the safety reporting seen in the Incident Investigation course, a crew that fears appearing overly cautious tends not to report anomalies that could prove significant, even in the cyber domain. Building a simple, non-judgemental reporting channel for cyber-related doubts is just as important as for traditional operational safety doubts.
An anomaly alone does not prove an attack. Compare the state with a baseline and independent sources, record times and alarms and use the established escalation route. For example, a GNSS anomaly may result from radio interference and requires navigational assessment even without network compromise. Protect logs and use monitoring tools validated for the OT systems, without improvised intrusive tests.
Key takeaways
- An anomaly is a signal to investigate, not automatic proof of compromise.
- Synchronized logs, baselines and escalation channels reduce diagnostic time.
- Early reporting should preserve evidence and avoid improvised technical action.
Responding to a cyber incident
Module objectiveConduct a safety-led cyber response coordinating ship command, IT/OT support, containment, evidence, notifications and recovery.
OT incident response is safety-led. A critical system is not automatically disconnected, shut down or restarted.
- Detect and record anomaly, time, system and alarms without unnecessary state changes.
- Protect navigation and operations, inform the Master and use planned manual or redundant modes.
- Escalate under the cyber plan to IT/OT, DPA and other matrix roles.
- Contain network, account, service or device only after assessing dependencies, authority and operational consequences.
- Preserve logs, configurations and chronology; report according to threshold and regime.
- Eradicate and recover to a known, verified state.
- Authorise return to service with tests, monitoring and root-cause review.
Key takeaways
- Ship safety governs every isolation or shutdown decision.
- Containment, evidence preservation and reporting may proceed in parallel.
- Return to service requires a known, verified state, not merely restarting equipment.
Backup and operational continuity
Module objectiveDesign and verify a recovery capability covering data, configurations, dependencies, manual procedures and acceptance criteria.
Backup is a recovery capability, not merely an existing copy. It covers data, software, configurations, licences, keys, dependencies, versions, manual procedures and support contacts.
RTO, recovery point, segregation and tests must reflect operational criticality. Technical restore and operational authorisation to return to service are separate decisions, with acceptance criteria and enhanced monitoring.
RTO (Recovery Time Objective) is the target time for restoring service; RPO (Recovery Point Objective) expresses the required recovery point and tolerable data loss in time terms. Set them according to operational continuity needs. Offline or immutable copies and separate backup credentials reduce the risk of backup compromise; they do not by themselves guarantee recovery. Test restoration from a trusted state, including dependencies and configurations; safeguard keys and licences with dedicated access controls.
Key takeaways
- An existing but untested copy does not demonstrate recoverability.
- Recovery time, RPO and dependencies must reflect operational criticality.
- Technical restoration and operational authorisation to return to service are separate decisions.
Convergence between physical security and cyber security
Module objectiveIntegrate physical access, service ports and technical spaces into cyber risk assessment while coordinating the SMS, SSA/SSP and operational controls.
Physical access can bypass logical controls but does not make segmentation, authentication, logging or least privilege irrelevant. Technical spaces, service ports and removable media enter the cyber assessment.
Restricted areas and ISPS measures derive from the approved SSA/SSP: not every OT space is automatically restricted. SMS, SSP and technical procedures should form coherent defence in depth without universally requiring one-way flow.
Key takeaways
- Physical access can bypass logical controls but does not make network defences irrelevant.
- Restricted areas and ISPS measures follow from the assessment and approved plan.
- Physical, logical and procedural controls should form coherent defence in depth.
Training and organisational culture
Module objectiveBuild role-based training and familiarisation including drills, knowledge checks and non-punitive reporting.
Rev.4, §3.5.3.6, recommends annual basic cybersecurity training for all employees, specific training for OT users and familiarisation for all crew members when joining the ship. It includes cyber hygiene, detection, response and recovery; knowledge and capability should also be tested through exercises.
Adapt content and assessment to crew, shore personnel, management and suppliers according to their roles. Exercises should verify contacts, escalation, operational continuity and recovery criteria without endangering live systems.
A just culture supports prompt reporting of good-faith errors: explain channels, fair treatment and the limits of confidentiality and accountability under law and policy. It does not promise immunity for intentional or grossly negligent conduct. After an error, report and preserve evidence without attempting deletion or improvised remedies.
Key takeaways
- Rev.4 calls for annual basic training, OT-specific training and onboard familiarisation.
- General awareness and specialist competence have different audiences and outcomes.
- Just culture supports reporting but does not remove accountability for intentional or grossly negligent conduct.
The DPA's role in cyber risk management
Module objectiveDistinguish the DPA’s ISM functions from designated cyber accountability and construct an interface and escalation matrix.
Rev.4 recommends designating a person or entity accountable for cyber planning, resources and execution, with authority, support and competence. It does not prescribe the DPA.
The DPA retains ISM functions: ship–management link, safety/pollution monitoring and availability of resources and support. For safety-relevant cyber risks, the DPA verifies that the SMS governs risk and escalation reaches competent authority.
The matrix distinguishes senior accountability, cyber risk owner, Master’s authority, IT/OT, DPA, CSO/SSO, privacy/legal and communications.
Priority depends on impact and urgency. The DPA needs competence appropriate to assigned functions and specialist support; any additional appointment to cyber accountability requires defined additional competence and authority.
Key takeaways
- Rev.4 recommends designating an accountable person/entity but does not automatically prescribe the DPA.
- The DPA verifies that safety-relevant risks are governed in the SMS and support is available.
- The Master, IT/OT, DPA, CSO/SSO, legal and communications roles must be defined before an incident.
Emerging trends
Module objectiveAssess 2024–2026 developments while distinguishing current instruments, industry guidance and IMO work that remains non-mandatory.
- Current: MSC-FAL.1/Circ.3/Rev.4, 28 May 2026, six elements and minimum controls.
- Current within scope: IACS E26/E27 Rev.1 for new ships contracted from 1 July 2024.
- Guidance: Guidelines on Cyber Security Onboard Ships, version 5 dated 14 November 2024; the Cyber Security Workbook is separate.
- Under development, non-mandatory: FAL/MSC Maritime Cyber Code, under development as a non-mandatory instrument, not yet adopted.
- Monitor: Maritime Single Window, supply chain, remote operations and ship–shore connectivity.
Key takeaways
- E26/E27 Rev.1 apply within scope to ships contracted for construction on or after 1 July 2024.
- IMO Rev.4 of May 2026 brings governance and minimum controls into the current framework.
- The Maritime Cyber Code is under development as a non-mandatory instrument; it has not yet been adopted.
Recurring mistakes
From the Mistake Library of SuperbaKnowledge, filtered to the subjects this course covers. This view selects and organises content published in SuperbaKnowledge; it does not modify or replace it. The linked Knowledge page remains the reference version, while official texts remain authoritative.
| Topic | Mistake | Typical consequence | Topic sheet |
|---|---|---|---|
| Cyber Risk Management in the SMS (MSC.428(98)) | Cyber risk managed as a separate IT matter, not integrated into the SMS's general risk assessment | Lack of integrated documentary evidence in the event of an audit, despite the existence of technical IT measures | See the topic sheet |
| Designated Person Ashore (DPA) | DPA appointed only formally, without real access to top management | NC in certification audit, ineffective escalation system in an emergency | See the topic sheet |
| Management of Change | Changes implemented informally without a structured assessment process | Risks associated with the change not identified before implementation | See the topic sheet |
| Crew Familiarisation and Training | Familiarization treated as a formality to be signed off, without real knowledge transfer | Crew nominally 'familiarised' but unprepared in a real emergency | See the topic sheet |
Glossary of acronyms
| Acronym | Definition |
|---|---|
| DPA | Designated Person Ashore |
| ECDIS | Electronic Chart Display and Information System |
| IACS | International Association of Classification Societies |
| ISM | International Safety Management Code |
| IT | Information Technology |
| MSC-FAL.1/Circ.3 | IMO circular carrying the guidelines on maritime cyber risk management; current revision Rev.4, 28 May 2026 |
| NIST | National Institute of Standards and Technology |
| NIST CSF | NIST Cybersecurity Framework — since version 2.0 (2024), six functions: Govern, Identify, Protect, Detect, Respond, Recover |
| OT | Operational Technology |
| Ransomware | Malware used for extortion, often through encryption; an incident may also involve data theft and threats of publication |
| SMS | Safety Management System |
| UR | Unified Requirement — an IACS requirement binding on member classification societies |
| CBS | Computer-Based System |
| DMZ | Demilitarized Zone |
| CSIRT | Computer Security Incident Response Team |
| MFA | Multi-Factor Authentication |
| RTO | Recovery Time Objective |
| RPO | Recovery Point Objective |
| NIS2 | Directive (EU) 2022/2555 |
References and sources
Sources consulted for the review of 15 September 2026. Check applicable flag requirements, national transposition and class rules.
| Source | Document and reference |
|---|---|
| IMO/ISM | ISM Code — SOLAS IX; §§1.2.2.2, 4, 9, 12 |
| IMO | MSC.428(98) — 2017 |
| IMO | MSC-FAL.1/Circ.3/Rev.4 — 28 May 2026; §§2–4 |
| IACS | UR E26 Rev.1 — Cyber resilience of ships |
| IACS | UR E27 Rev.1 — Cyber resilience of onboard systems and equipment |
| UE / EU | NIS2 — Directive (EU) 2022/2555, Articles 2, 20, 21, 23; Annex I |
| IEC | IEC 62443-3-2:2020 — zones, conduits, SL-T |
| NIST | Cybersecurity Framework 2.0 — 2024 |
| Industry guidance | The Guidelines on Cyber Security Onboard Ships — v5, 14 November 2024 |
| IMO — development | FAL 50 — non-mandatory Maritime Cyber Code |
This course is educational material for training purposes and does not constitute a professional certification or qualifying credential. Read the full disclaimer.