Robustel Maritime Cybersecurity Blog: IMO, IACS & IEC 61162-460

Maritime cybersecurity is no longer a niche IT topic. It now sits alongside safety, operational resilience, and class-driven assurance—especially as vessels become more connected, more software-defined, and more reliant on remote access, vessel-to-shore data flows, and integrated navigation/communications networks.

One of the biggest sources of confusion we see is the phrase “required certifications.” In reality, maritime cyber compliance is rarely a single certificate you can buy and forget. What’s expected depends on the vessel type, project scope (newbuild vs retrofit), the equipment’s role in the onboard architecture, and which stakeholders must sign off the final design.

This guide is designed to do two things:

give you a clear glossary of the terminology the industry uses, and
explain, step by step, how customers typically build an approach that is credible, auditable, and aligned to modern expectations—without over-claiming what is “mandatory” in all cases.

Glossary: the terms you’ll hear in maritime cybersecurity (and what they mean)

Maritime cyber risk management

A structured way to identify, assess, and control cyber risks that could affect operations, safety, or security—then document what you did about those risks. In shipping, this is often treated as an extension of existing safety and security management practices rather than a brand-new discipline.

SMS (Safety Management System) and the ISM Code

The Safety Management System (SMS) is the set of documented processes a shipping company uses to manage safe operations and meet regulatory expectations. The International Safety Management (ISM) Code is the framework behind it. In practical terms: if cyber risk is part of the SMS, it becomes something you must manage, evidence, and improve over time—not a one-off procurement requirement.

IMO (International Maritime Organization)

The IMO is the UN agency that sets global standards for safety, environmental performance, and security in international shipping. The IMO’s cyber work matters because it shapes what shipping companies are expected to incorporate into management systems and operational controls.

Flag State and Port State Control

The Flag State is the country where the vessel is registered. The Flag State (and its recognized organizations) plays a central role in how compliance expectations are interpreted and enforced. Port State Control is the inspection regime that can verify compliance when vessels call at ports internationally.

Classification societies (“class societies”)

Classification societies set technical rules for vessel design and construction and verify compliance through surveys. In many projects, class requirements shape what evidence must be produced by yards, integrators, and equipment vendors—particularly in newbuild programmes and major system upgrades.

IACS (International Association of Classification Societies)

IACS is the body that coordinates many of the major class societies. When IACS issues “Unified Requirements,” they influence how class societies consistently assess certain aspects of ship design and onboard systems.

IACS UR E26 and UR E27

These are IACS Unified Requirements focused on cyber resilience:

E26 is oriented toward ship-level resilience outcomes and overall approach.
E27 focuses on onboard systems and equipment expectations across the lifecycle.

You’ll hear these referenced frequently in newbuild and class-driven environments because they shape how cyber resilience is designed, implemented, and evidenced.

“Computer-Based Systems” (CBS)

A broad term used to describe systems that rely on software and networked computing to perform functions onboard. Cyber risk management discussions often use CBS language because the risk is rarely confined to a single device—risk emerges through system interactions and interconnections.

IT vs OT (Operational Technology)

IT typically refers to business systems and enterprise networks. OT refers to operational systems that directly support vessel functions (including industrial control and shipboard operational systems). Maritime cybersecurity requires careful handling because OT environments have different safety priorities, availability requirements, and change-control realities than office IT.

Type Approval vs Class Notation (why these are not the same thing)

These two get mixed up constantly:

Type Approval is generally a product-level approval: it assesses whether a specific model/version meets a defined set of requirements or standards under a defined scope.
A Class Notation is a vessel-level (or system-level) designation: it indicates the vessel has been built/operated in accordance with specific class requirements, verified by surveys and evidence across the broader ship context.

In other words: product approvals can be powerful evidence, but they do not automatically “make the vessel compliant” on their own.

IEC standards (why they matter)

The IEC (International Electrotechnical Commission) publishes technical standards used globally. In maritime cybersecurity, IEC standards matter because they can define technical requirements and test methods—especially for networks and equipment involved in navigation and radiocommunications contexts.

IEC 61162-450 and IEC 61162-460 (and what “460” signals)

IEC 61162 is the family of standards associated with maritime navigation and radiocommunication data exchange. IEC 61162-460 is often discussed in projects where a higher security posture is needed for Ethernet-based interconnections and where secure boundaries between networks must be designed and verified.

You may hear terms like:

“460 Network”: a network that is designed and managed to meet the IEC 61162-460 requirements and test expectations.
“460 Gateway” / “460 Wireless Gateway”: roles used to describe how a device functions at the boundary between networks and how data is allowed to pass under controlled conditions.

IEC 63154 (correct context)

IEC 63154 is a maritime cybersecurity standard focused on requirements, test methods, and required test results for maritime navigation and radiocommunication equipment and systems. It is not an alarm management standard—its purpose is cybersecurity assurance in the relevant maritime equipment context.

IEC 62443 (industrial cybersecurity) and IEC 62443-4-1 specifically

IEC 62443 is a well-known family of industrial cybersecurity standards. IEC 62443-4-1 is specifically about a secure development lifecycle—how a vendor designs, builds, tests, and maintains products in a disciplined way that reduces vulnerabilities and supports lifecycle security.

This matters because many cyber issues are not “deployment mistakes.” They are supply-chain issues: weak secure development practices, unclear update processes, and poor vulnerability handling.

ISO/IEC 27001 (ISMS)

ISO/IEC 27001 is the global standard for an Information Security Management System (ISMS) at the organisational level. It can be valuable evidence of governance maturity, but it is not automatically a “required maritime equipment certification.” It’s a risk-management and management-system framework.

NIST Cybersecurity Framework (NIST CSF)

A widely used framework that helps organisations structure cybersecurity activities around the functions Identify, Protect, Detect, Respond, and Recover. It can be a useful way to plan and communicate cyber risk controls across stakeholders.

SOLAS and IEC 60945 (why these appear in marine equipment discussions)

SOLAS is a foundational international convention for the safety of life at sea. IEC 60945 is a marine equipment standard often referenced in relation to environmental and EMC requirements. They appear in compliance conversations because cybersecurity does not exist in a vacuum—equipment suitability and safety context still matter.

Who’s who: the stakeholders that shape “compliance” in real projects

Shipowner/operator (and the technical manager)

This is the party ultimately responsible for safe operation and maintaining the SMS. Even when a system is installed by a yard or integrator, the owner/operator inherits the operational risk and must maintain evidence over time: access controls, maintenance procedures, incident response readiness, and supplier management.

Shipyard

In newbuilds, the yard is under intense schedule pressure and must coordinate multiple systems into a coherent architecture that can pass class scrutiny. Yards care about clarity: predictable integration patterns, clean documentation, and equipment that behaves consistently under acceptance testing.

System integrator

Integrators live at the boundary between “a device spec” and “a working ship.” They care about network boundaries, VLANs, routing rules, firewalls, remote access patterns, logging, and how changes are governed. Integrators tend to be the first to ask for evidence packs because they’re the ones who must defend the architecture.

Classification society (class)

Class societies verify that the ship and its systems meet relevant rules. In cyber-related work, class increasingly expects to see that risk is understood and controlled—not just that a vendor claims a feature exists. For customers, class influence often appears as structured documentation requests and “show me how it works” scrutiny during surveys.

Flag State / Recognized Organizations

Depending on the vessel and jurisdiction, Flag State requirements and the actions of recognized organizations shape how cyber risk expectations are interpreted. For end customers, this is another reason why “one universal certification list” is not realistic.

Equipment manufacturers (OEMs)

OEMs influence compliance outcomes because they control product design, secure development practices, patching methods, and vulnerability handling. A device can be technically capable and still create risk if lifecycle security is weak or documentation is unclear.

Connectivity and communications partners

This includes vendors and integrators providing shipboard routers/gateways, cellular/SAT backhaul, VPNs, and remote access mechanisms. These components often sit on critical boundaries—between uncontrolled external networks and onboard operational networks—which means they must support controlled interconnections, auditing, and predictable security behaviour.

The real question: not “what certifications are required?” but “what evidence will we need?”

A useful way to think about maritime cybersecurity compliance is this:

Compliance is an evidence problem.

You’re building a story that can survive scrutiny: “We understand the risks, we designed the right boundaries, we selected credible suppliers, and we can show how this is operated safely over time.”

That evidence usually falls into five areas.

1) Scope and criticality: what does the system touch?

Before choosing standards or suppliers, map the system:

What networks are involved (bridge-adjacent, OT, crew welfare, business IT)?
What data is flowing (navigation, monitoring, maintenance, logs, files)?
What remote access exists (who can access what, from where, under what controls)?
What are the failure modes (safety impact, operational impact, commercial impact)?

This step sounds obvious, but it’s where many projects fail. If you can’t clearly describe what you’re connecting and why, you can’t credibly choose requirements or prove controls.

2) Architecture: where are the boundaries, and how are they enforced?

Cyber resilience in maritime systems is usually achieved by design choices:

segmentation and zoning,
controlled interconnections,
hardening and least-privilege access,
secure remote access patterns (not “always-on” convenience access),
logging and monitoring appropriate to the risk level.

This is where communications equipment plays an outsized role. Gateways and routers are not just “connectivity”—they are boundary enforcement points.

3) Supplier assurance: can your vendors support compliance outcomes?

A supplier should be able to provide more than a datasheet. You want to know:

how the product is built and tested (secure development practices),
how updates are delivered and governed,
how vulnerabilities are handled and communicated,
what documentation exists for secure commissioning and ongoing operations.

This is the difference between a device that “has security features” and a device that can be used as part of a compliance-ready system.

4) Verification: how do you show it works (not just claim it does)?

For higher-risk environments—especially where navigation/radiocommunications networks and controlled interconnections are involved—verification often matters as much as design. Depending on scope, verification can include test evidence, product-level approvals, and repeatable commissioning procedures that ensure the installed configuration matches the intended security design.

5) Operations: can you maintain the posture over time?

Ships are long-lived assets. Compliance expectations increasingly assume lifecycle management:

change control (who changes firewall rules, when, and why),
credential management and access reviews,
patching strategy and update windows,
incident response readiness and recovery planning,
documentation that remains usable after handover.

This is why the “best” cybersecurity approach is usually the one that crews and managers can actually operate consistently.

What end customers should do next: a practical compliance path

If you’re planning a new build, a major retrofit, or a connectivity upgrade, the following sequence keeps teams aligned and reduces surprise rework.

Step 1: Define the system narrative (one page)

Write one page that answers:

What are we connecting?
Why are we connecting it?
What could go wrong?
What boundaries and controls are we relying on?
Who owns ongoing operation and change control?

This becomes the anchor for all later documentation and supplier evaluation.

Step 2: Create a minimum “evidence pack” checklist for suppliers

For communications and gateway suppliers, a strong starting checklist typically includes:

reference architecture diagrams (typical deployment patterns),
secure configuration/hardening guidance,
remote access design guidance (and how it’s controlled),
logging/audit capability overview,
update and vulnerability handling policy summary,
any independent approvals relevant to your scope.

This makes procurement easier: you can compare suppliers on evidence, not marketing.

Step 3: Design for survey and handover

Assume that someone else will inherit your decisions. Build documentation that survives:

yard handover,
integrator handover,
crew rotation,
and audit review.

If your compliance story depends on “tribal knowledge,” it won’t hold.

Step 4: Validate the configuration, not just the product

Even the best product can be undermined by weak commissioning. Build a repeatable commissioning checklist and make it part of acceptance.

Step 5: Plan the lifecycle from day one

Define who owns updates, how often access is reviewed, and how incidents are handled. This is often the difference between “compliance-ready at delivery” and “compliance erosion six months later.”

Robustel’s compliance evidence (independent approvals)

As an end customer, you should expect suppliers to be specific about what they have achieved and equally specific about scope.

Robustel’s maritime cybersecurity and communications portfolio is built to support compliance-driven connectivity where controlled interconnections and auditability matter.

DNV Type Approval referencing IEC 61162-460 (MG460 Gateway)

Robustel’s MG460 Gateway has a DNV Type Approval certificate that references compliance to IEC 61162-460 Edition 3 (2024-04) within the scope defined by the certificate. In practical terms, this is relevant evidence for projects operating in IEC 61162-460 domains where product-level verification and repeatable integration patterns matter.

It’s also important to interpret this correctly: product approvals support a compliance narrative, but vessel-level compliance still depends on the broader architecture and correct installation and configuration.

Secure development lifecycle discipline (IEC 62443-4-1)

Robustel also states certification to IEC 62443-4-1, which is focused on secure development lifecycle practices. For end customers, this matters because cybersecurity risk is strongly shaped by how products are designed, tested, maintained, and supported—especially when devices are deployed at scale and expected to remain in service for years.

If you’re evaluating suppliers for a compliance-sensitive deployment, this is the kind of assurance that reduces long-term risk: not just “security features,” but disciplined product security practices and lifecycle posture.

Final thoughts

Maritime cyber compliance does not reward vague claims. It rewards clarity:

clear scope,
clear architecture,
credible documentation,
and suppliers who can support verification and lifecycle security.

If your project involves secure vessel-to-shore communications, controlled interconnections between networks, or IEC 61162-460 environments, the right partner can materially reduce risk, rework, and procurement friction—by helping you build an evidence-driven compliance story that stands up to scrutiny.

Your next steps with Robustel

If you’re planning a newbuild, major retrofit, or communications upgrade and you need shipboard connectivity that stands up to modern cybersecurity expectations Robustel can help you move from “we think we’re covered” to clear, auditable confidence.

Here’s what to do next:

Share your scope (15 minutes). Tell us what you’re connecting (bridge-adjacent, OT, crew welfare, vessel-to-shore), how remote access is used, and whether class involvement or IEC 61162-460 environments apply.
Get a practical architecture and evidence pack outline. We’ll recommend a deployment approach and the documentation you’ll typically need for yards, integrators, owners, and class—so you’re not guessing late in the project.
Confirm the right solution path. Where appropriate, we’ll map Robustel options (including IEC 61162-460-aligned connectivity using the MG460 to your network boundaries, operational needs, and lifecycle expectations.

Ready to talk?
Reach out to the Robustel maritime team to discuss your vessel architecture, compliance expectations, and the fastest path to a secure, class-friendly communications design.

Contactez-nous