Maritime Cybersecurity in 2026: What Ship Managers Actually Need to Know
Maritime cyber incidents surged 103% in 2025. With USCG deadlines approaching, TMSA 3 Element 13 now mandatory, and IMO guidelines upgraded to NIST v2.0, here is what every ship manager needs to know about cybersecurity — and what to demand from your software vendors.

In 2025, the maritime industry recorded 828 cyber incidents — a 103% increase over the 408 recorded in 2024, according to the CYTUR annual maritime threat report. Ransomware cases more than doubled to 372.
Attacks on maritime operational technology surged 150%. GPS spoofing incidents reached about 1,000 disruptions per day, affecting over 40,000 vessels worldwide.
The average cost per maritime cyber attack now exceeds USD 550,000. These are not projections or threat scenarios. They are last year's numbers.
At the same time, five major regulatory frameworks are converging on the same demand. Prove that you manage cyber risk, or face consequences. The USCG's MTSA Cyber Regulations are now in effect.
TMSA 3 Element 13 makes cybersecurity a formal assessment criterion for tanker operators. IMO's revised guidelines align with NIST Cybersecurity Framework v2.0.
IACS Unified Requirements E26 and E27 impose design-level security on newbuilds. And the EU's NIS2 Directive classifies maritime shipping as critical infrastructure. Penalties reach EUR 10 million.
None of these regulations exist in isolation. They overlap, reinforce each other, and together remove the option of doing nothing.
This article is a practical briefing for ship managers. It covers what has changed, what is now required, and what to demand from their technology partners. It is not a general overview or a high-level awareness piece.
It covers specific regulations with specific deadlines, real incidents with documented impacts, and a concrete list of security questions. Any software vendor should be able to answer them. If you manage vessels, approve software procurement, or oversee compliance, this is the information you need in front of you right now.
The Threat Landscape Has Changed Fundamentally
For years, maritime cybersecurity discussions centered on hypothetical scenarios. They asked what could happen if an attacker targeted a ship's navigation system or encrypted a fleet operator's databases. That era is over.
The 2025 CYTUR report documented 828 maritime-specific cyber incidents, up from 408 in 2024 and just 64 in 2020. This is not gradual growth. It is exponential acceleration.
Ransomware accounts for the largest share: 372 cases in 2025, up from 156 the previous year. Attackers have learned that maritime companies are willing to pay. The alternative is losing visibility over their fleet for weeks or months. This is especially true of those running legacy server infrastructure.
The economics are simple. Encrypt a ship manager's servers, and they lose the ability to manage crew changes, procurement, certificates, and maintenance across their entire fleet. The pressure to pay is enormous.
Attacks on maritime operational technology (OT) surged 150% in 2025. OT means the systems that control physical equipment like engines, navigation, ballast, and cargo handling. These are not data theft operations.
They target the systems that keep vessels safe and operational. The distinction matters. IT attacks steal or lock data. OT attacks can cause physical harm.
GPS spoofing has reached industrial scale. About 1,000 disruption incidents occur per day, affecting over 40,000 vessels.
In May 2025, the container ship MSC Antonia ran aground after GPS spoofing corrupted its navigation data. In June 2025, over 3,000 vessels were disrupted in the Persian Gulf in under two weeks.
Marlink is one of the largest maritime connectivity providers. It reported receiving over 150 calls in a single day from vessels experiencing GPS anomalies. These are not isolated incidents. They show a systematic capability that state and non-state actors now deploy routinely.
The human dimension confirms the scale. A DNV survey published in late 2024 found that 31% of maritime professionals reported their organization had experienced a cyber attack in the preceding 12 months.
One in three. And that figure likely understates reality. Organizations that suffered attacks have strong incentives not to disclose them.
Perhaps most concerning is the emergence of AI-driven attacks. The GTG-1002 research demonstration showed AI agents autonomously performing 90% of a complete cyber attack lifecycle. That ran from reconnaissance through exploitation to data exfiltration.
The implication is clear. Attack tooling is becoming cheaper, faster, and more accessible. The barrier to launching a sophisticated maritime cyber attack is falling, while the potential payoff rises.
The average cost per maritime cyber incident now exceeds USD 550,000. That figure covers direct costs only. It does not include reputational damage, lost charter hire during system outages, elevated insurance premiums, or the regulatory consequences that now follow a breach.
For a mid-sized ship management company operating 30-50 vessels, a single successful ransomware attack can represent a seven-figure loss.
- 828Cyber incidentsIn 2025, up 103% from 408 in 2024 and 64 in 2020.
- 372Ransomware casesMore than doubled in 2025.
- 150%OT attacksIncrease in attacks on maritime operational technology in 2025.
- More than USD 550,000Average attack costAverage direct cost per maritime cyber attack.
Source: CYTUR annual maritime threat report
The DNV ShipManager Ransomware — A Defining Moment
On January 7, 2023, a ransomware attack struck the servers hosting DNV's ShipManager software. This is one of the most widely used ship management platforms in the world. The attack, first reported by TechCrunch and subsequently confirmed by DNV, affected 70 customers and approximately 1,000 vessels out of ShipManager's total base of around 300 customers and 7,000 vessels.
DNV shut down ShipManager servers immediately upon detection. The entire server environment had to be rebuilt from scratch.
Full service was not restored for about two months. During that period, shore-side management was effectively blind. These are the people responsible for overseeing vessel operations, compliance, procurement, and crew management.
They could not access crew records, maintenance histories, certificates, or procurement data through the platform.
Vessels themselves continued to operate because ShipManager's onboard components functioned offline. This design choice proved invaluable under crisis. But the core promise of a ship management platform was broken for two months across a thousand vessels. That promise is connecting ship and shore into a unified operational picture.
The significance of this incident extends beyond its immediate impact. This was not an attack on a port, a terminal, or an individual vessel's navigation system.
It was an attack on the software platform that connects ship and shore. It is the system that ship managers rely on daily to run their operations. It demonstrated that ship management software is not a peripheral tool. It is critical infrastructure.
And it proved that when that platform goes down, the consequences cascade across each vessel, each department, and each compliance obligation.
The Regulatory Tsunami
The maritime industry is not facing a single new cybersecurity regulation. It is facing five at once. Each is from a different authority. Each has its own scope and deadlines. All reinforce the same central message: cyber risk management is no longer optional.
Understanding which regulations apply to your operations, and where they overlap, is essential to avoiding compliance gaps.
| IMO MSC.428(98) | USCG MTSA Cyber | TMSA 3 Element 13 | IACS UR E26/E27 | EU NIS2 | |
|---|---|---|---|---|---|
| Timing | Effective 1 January 2021 | Effective 16 July 2025 | Introduced in TMSA 3 | Mandatory for contracts from 1 July 2024 | Effective 18 October 2024 |
| Scope | Shipping companies under the ISM Code | U.S.-flagged vessels and MTSA facilities | Tanker operators; wider use across vessel types | Newbuilds; reference point for existing vessels | Maritime companies in European waters or under EU flags |
| Key requirements | Cyber risks in the Safety Management System | Report incidents; train personnel; appoint a CySO; submit a plan | Risk assessments and cyber security plans at four levels | Ship and equipment cyber resilience by design | Risk management, reporting, accountability and supply chain checks |
| Framework or benchmark | Guidelines align with NIST CSF v2.0 | NIST CSF v2.0 | OCIMF TMSA assessments | Five NIST functions | NIS2 |
| Consequences | ISM audit non-conformities or Document of Compliance suspension | Vessel detentions, civil penalties or denial of U.S. port entry | Weak scores can affect oil major charters | Class survey reference, especially after upgrades | Up to EUR 10 million or 2% of global annual revenue |
Source: IMO; USCG Federal Register; OCIMF; IACS; EU NIS2 Directive
IMO MSC.428(98) — The Foundation
Everything in maritime cybersecurity traces back to IMO Resolution MSC.428(98), adopted in June 2017 and effective from January 1, 2021. This resolution made cyber risk management a mandatory component of the International Safety Management (ISM) Code.
In practical terms, each shipping company's Safety Management System must now address cyber risks, and auditors verify this during ISM compliance audits.
The resolution is supported by guidelines document MSC-FAL.1/Circ.3, which has been revised multiple times, most recently to Rev.3 in April 2025. The resolution itself is brief. Yet it set the legal foundation for everything that followed.
If your Safety Management System does not explicitly address cyber risks, you are already non-compliant with the ISM Code.
USCG MTSA Cyber Regulations
The United States Coast Guard published its final rule on cybersecurity in the Marine Transportation System on January 17, 2025, in the Federal Register. The rule became effective July 16, 2025.
It is the most prescriptive maritime cybersecurity regulation to date. It applies to all U.S.-flagged vessels and MTSA-regulated facilities.
The compliance timeline is staggered and demanding:
- July 16, 2025: All reportable cyber incidents must be reported to the National Response Center immediately upon discovery. This is already in effect.
- January 16, 2026: All personnel must complete cybersecurity training. This deadline has already passed.
- July 16, 2027: Designate a Cybersecurity Officer (CySO), conduct a comprehensive cybersecurity assessment, and submit a cybersecurity plan to the USCG for approval.
- Every 5 years: Plan renewal with fresh penetration testing.
The cybersecurity plan must address these requirements:
- Account security
- Device protection
- Data safeguarding
- Supply chain risk management
- Penetration testing
- Network segmentation
- Multi-factor authentication
- Continuous monitoring
- Patch management
Two things stand out. First, the training deadline of January 2026 has already passed. If your personnel have not completed cybersecurity training, you are already behind.
Second, the July 2027 deadline for plan submission is closer than it appears. Four tasks must be done: conducting a proper cybersecurity assessment, designating a CySO, drafting a plan that meets USCG standards, and preparing for approval. Together they take 12 to 18 months for most organizations. That means the work needs to start now.
- Incident reporting starts
- Training deadline
- CySO and plan due
- Plan renewal
Source: Federal Register, USCG Maritime Commons
TMSA 3 Element 13 — Maritime Security
The Tanker Management and Self Assessment program, published by OCIMF (Oil Companies International Marine Forum), is the de facto standard for tanker operators. It is increasingly referenced across all vessel types. TMSA 3 introduced Element 13, Maritime Security, with explicit cybersecurity requirements.
Element 13 defines four achievement levels, from basic threat identification at Level 1 through to innovative cyber risk methods at Level 4. At each level, formal risk assessments and documented cybersecurity plans are required. They cover vessels, shore operations, and, critically, ship-shore communications.
Elements 7 (Management of Change) and 13 together create a comprehensive requirement for cybersecurity planning that survives SIRE 2.0 inspections.
For tanker operators, TMSA compliance is not optional. It directly affects your ability to secure charters with oil majors. A weak Element 13 score can cost you business.
TMSA assessments are self-reported but verified through SIRE inspections. So the consequences of inadequate cybersecurity documentation are tangible and commercial.
IMO MSC-FAL.1/Circ.3/Rev.3 (April 2025)
The latest revision of IMO's Guidelines on Maritime Cyber Risk Management, published in April 2025, is a significant upgrade from previous versions. The most important change is that the guidelines now align with NIST Cybersecurity Framework v2.0, replacing the earlier alignment with NIST v1.0.
This is not a cosmetic update. Rev.3 now requires asset inventories. That is a documented list of each system, device, and connection between ship and shore.
It requires zone maps showing network segmentation. It mandates both incident response and recovery plans (previous versions focused primarily on response).
It introduces mandatory annual crew cybersecurity training. And it expands scope to explicitly cover shore-side links, port interfaces, and supply chains. This acknowledges that maritime cyber risk extends far beyond the vessel itself.
These guidelines support the mandatory requirements of MSC.428(98). So they effectively set the standard that ISM auditors will use when evaluating your Safety Management System's cyber risk provisions. Ignoring Rev.3 is ignoring the current audit benchmark.
IACS UR E26 and E27
The International Association of Classification Societies (IACS) published two Unified Requirements on cyber resilience. They became mandatory for vessels contracted for construction on or after July 1, 2024.
UR E26 — Cyber Resilience of Ships. It addresses the vessel as a complete system. It mandates network segmentation, access control, and a critical requirement: no IP exposure from onboard systems to untrusted networks.
Navigation and communication systems cannot share a network zone with other systems. This is a design-level security requirement that must be met at the shipyard.
UR E27 — Cyber Resilience of On-Board Systems and Equipment. It goes deeper, imposing component-level security requirements on individual systems. These are sensors, programmable logic controllers (PLCs), human-machine interfaces (HMIs), and other OT devices. Both URs are structured around the five NIST functions (Identify, Protect, Detect, Respond, Recover).
E26 and E27 apply primarily to newbuilds. Even so, they are setting the security baseline that the entire industry will eventually be measured against. Classification societies are already using them as reference points in surveys of existing vessels, particularly when systems are upgraded or replaced.
EU NIS2 Directive
The EU's Network and Information Security Directive 2 (NIS2) came into effect on October 18, 2024. It classifies maritime shipping as essential infrastructure. That places it alongside energy, water, and healthcare in terms of regulatory priority.
The consequences of non-compliance are severe: penalties up to EUR 10 million or 2% of global annual revenue, whichever is higher. NIS2 requires stronger risk management practices and stricter incident reporting timelines. It also requires clearer accountability structures (including personal liability for management) and supply chain security assessments.
For any maritime company operating in European waters or under EU member state flags, NIS2 applies. And it has teeth.
Your Ship Management Software Is Your Attack Surface
Discussions about maritime cybersecurity tend to focus on navigation systems, ECDIS workstations, and engine control rooms. These are valid concerns.
But for a ship management company, the most critical piece of technology is the ship management platform itself. This software connects ship and shore, stores crew records, tracks maintenance, manages procurement, holds certificates, and documents compliance.
The DNV ShipManager incident made this explicit. The attacker did not target a single vessel.
They targeted the platform. All companies using it lost access at the same time. When your ship management software goes down, you lose visibility over:
- Crew certifications
- Overdue maintenance
- Pending purchases
- Regulatory submissions
- Operational planning
This is not about one system on one ship. It is about the central nervous system of your entire fleet.
The architecture of that platform determines your exposure. That means how it is built, where it runs, and how it handles authentication and data storage. Legacy platforms running on on-premise servers are the primary ransomware target in maritime.
These servers sit on company networks, behind VPNs of varying quality. Their patch levels depend on manual IT processes. They are physical machines in physical offices.
An attacker who breaches the network can reach them, encrypt them, and hold the entire operation hostage.
Cloud-native platforms eliminate this attack vector entirely. There is no server in your office to encrypt.
There is no VPN to breach. The software runs on infrastructure that is professionally managed, continuously monitored, and automatically patched. Teams whose sole responsibility is security do this work.
This is not a minor advantage. It removes the number one method by which maritime companies are currently being attacked.
Cloud-Native Security Is Not Marketing — It Is Architecture
There is a meaningful distinction between a platform that was born in the cloud and one that was migrated there. A cloud-native application is one designed from its first line of code to run as a multi-tenant SaaS platform. It inherits its infrastructure provider's security controls at a foundational level. A legacy application moved onto a cloud virtual machine inherits very little.
Consider what a genuinely cloud-native ship management platform provides at the infrastructure level:
- Infrastructure certifications: SOC 2 Type 2, ISO 27001:2022, PCI DSS v4.0 — these are maintained by the hosting provider and apply to the platform by default. No separate certification effort is required by the ship management company.
- Encryption in transit: TLS 1.3 for all communications between client and server. No unencrypted channels, no fallback to weaker protocols.
- Encryption at rest: AES-256 encryption for stored data. Even if an attacker gained physical access to storage media, the data would be unreadable.
- Stateless session architecture: JWT (JSON Web Token) based authentication eliminates server-side sessions. There are no sessions stored on a server to hijack. This removes an entire class of attack.
- Multi-tenant isolation: Customer data is logically isolated. A breach in one customer's account cannot cascade to another. This is unlike single-tenant server installations, where a single compromise exposes everything.
- DDoS absorption: Auto-scaling infrastructure absorbs denial-of-service attacks without service degradation. An on-premise server has finite capacity. Cloud infrastructure scales automatically.
This is not about being "in the cloud". Plenty of cloud deployments are just as vulnerable as on-premise installations. A legacy application running on a cloud VM still has the same software vulnerabilities. It has the same session management weaknesses. It has the same architectural limitations it had on premise.
The distinction is cloud-native: designed from the ground up with these security properties built into the architecture, not bolted on after the fact.
The NIST Cybersecurity Framework v2.0 — A Maritime Perspective
The NIST Cybersecurity Framework v2.0, released in February 2024, is now the backbone of both the IMO's Rev.3 guidelines and the USCG's MTSA Cyber Regulations. If you understand NIST v2.0, you understand the structure that regulators and auditors will use to evaluate your cybersecurity posture.
The framework defines six core functions. That is up from five in v1.0, with the addition of "Govern" as a new top-level priority.
| Maritime focus | Software evidence | |
|---|---|---|
| Govern | Strategy, risk appetite, roles, policies and oversight | Named cyber risk owner and security governance |
| Identify | Every system, connection and ship–shore data flow | Asset inventory, data flow diagram and integrations list |
| Protect | Safeguards for critical services and data | Encryption, access control, Content Security Policy and input validation |
| Detect | Activities to identify cyber security events | Audit trails, login anomaly detection and access monitoring |
| Respond | Actions after a detected cyber security incident | Tested incident response plan with timelines and escalation |
| Recover | Restoring services impaired by an incident | Backup and disaster recovery architecture |
Each row is one NIST function applied to ship management software. Source: NIST Cybersecurity Framework v2.0
Govern — The New Priority
The "Govern" function is entirely new in v2.0 and sits above the other five. It establishes the organizational context for cybersecurity: strategy, risk appetite, roles and responsibilities, policies, and oversight.
NIST elevated governance because decades of incidents demonstrated that technical controls fail when the organizational structure around them is unclear.
For maritime companies, the governance question is pointed. Who in your organization owns cyber risk? Is it the Designated Person Ashore (DPA)?
The IT manager? A shore-based security officer?
Under the USCG regulations, you will need to designate a Cybersecurity Officer (CySO) by July 2027. But the Govern function asks a broader question. Is cybersecurity treated as a strategic business risk managed at the leadership level? Or is it treated as an IT problem delegated to a technician?
The software implication is direct. Your ship management vendor should be able to articulate their own governance structure. Who is responsible for security in their organization?
How do they make decisions about security investments? If they cannot answer, their security posture is likely reactive rather than strategic.
Identify, Protect, Detect, Respond, Recover
The five operational functions remain the core of the framework. Here is what each means in a maritime context, and what it implies for your ship management software.
Identify. Know each system, connection, and data flow between ship and shore.
Asset inventories are now mandatory under both Rev.3 and the USCG regulations. For your software platform, this means asking four things. Do you know what data the platform holds? Do you know where it is stored, who has access, and how it moves between ship and shore?
Your vendor should be able to provide a data flow diagram and a clear inventory of integrations.
Protect. Implement safeguards to ensure delivery of critical services. In software terms, this means:
- Encryption — AES-256 at rest, TLS in transit
- Role-based access control with fine-grained permissions at company, fleet, and vessel levels
- Content Security Policy headers to prevent cross-site scripting
- Input validation on every user-facing endpoint
Detect. Develop activities to identify cybersecurity events. For a ship management platform, this includes:
- Comprehensive audit trails — who accessed what, when, and from where
- Login anomaly detection — unexpected locations, unusual hours, multiple failed attempts
- Monitoring of data access patterns for signs of exfiltration
Respond. Take action regarding a detected cybersecurity incident.
Your vendor's incident response plan should have defined timelines, communication procedures, containment strategies, and escalation paths. Ask when they last tested it, not when they last wrote it.
Recover. Restore capabilities or services impaired by an incident.
This is where architecture matters most. The DNV ShipManager recovery took two months.
A cloud-native platform with proper backup and disaster recovery architecture can restore service in minutes to hours, not weeks to months. The difference is architectural, not procedural.
Ten Questions to Ask Your Ship Management Software Vendor
Cybersecurity claims are easy to make and difficult to verify. Each vendor will tell you their platform is secure.
The following ten questions are designed to move past general assurances and into verifiable specifics. They are the questions we believe any ship management software vendor should be able to answer precisely. That includes ourselves.
- What encryption algorithm do you use for data at rest? Look for AES-256 with proper initialization vector (IV) generation. If the vendor says "encrypted" without specifying the algorithm and key management approach, the answer is incomplete.
- Is your platform SOC 2 Type 2 attested? By whom, and when was the last audit? SOC 2 Type 2 is an independent audit. It verifies that security controls are not just designed but operating effectively over a sustained period. Type 1 is a point-in-time check. Type 2 covers a continuous period (typically 6-12 months). The distinction matters.
- Do you hold ISO 27001 certification — your organization, not just your cloud provider? Many vendors claim ISO 27001 compliance because their hosting provider (AWS, Azure, Google Cloud) holds the certification. That covers the infrastructure, not the application. Ask specifically whether the vendor's own organization is certified.
- How do you handle session management? Stateless JWT-based authentication is architecturally superior to server-side sessions because there is no session state to hijack. If the vendor uses server-side sessions, ask about session timeout policies, session fixation protections, and secure cookie attributes.
- What is your RBAC model? Can permissions be set at company, fleet, and individual vessel level? Role-Based Access Control (RBAC) determines who can see and do what within the platform. In maritime operations, access often needs to be granular. A superintendent should see their fleet, not the entire company. A chief engineer should see their vessel's maintenance, not procurement across all vessels. Ask for specifics.
- Is crew personal data encrypted separately from operational data? Crew records include passport numbers, medical certificates, bank details, and next-of-kin information. Under GDPR and most flag state data protection laws, personal data requires heightened protection. A dedicated encryption service for crew data — separate from general operational data encryption — demonstrates mature data classification.
- What Content Security Policy headers do you deploy? Content Security Policy (CSP) is an HTTP header. It tells the browser which scripts, styles, and resources are allowed to load on a page. A strong CSP prevents cross-site scripting (XSS) attacks. These are among the most common web vulnerabilities. If the vendor has not heard of CSP, that is a significant red flag.
- Where is my data physically stored? Can you guarantee data residency for flag state compliance? Some flag states and charterers require data to be stored in specific geographic regions. Your vendor should be able to tell you the exact data center region(s) where your data resides. They should also say whether they can accommodate data residency requirements.
- What is your incident response timeline? When was the last time you tested it? An incident response plan that has never been tested is a document, not a capability. Ask for the date of the last tabletop exercise or simulated incident. Ask how quickly they commit to notifying affected customers. Under NIS2 and the USCG regulations, reporting timelines are measured in hours, not days.
- Can you provide your penetration testing results or summary? When was the last test? Penetration testing is where professional security researchers attempt to break into the system. It is the gold standard for validating security claims. Any serious vendor conducts regular pen tests and should be willing to share at least a summary of findings and remediation status. Annual testing is the minimum. Quarterly is better.
Suppose your vendor cannot answer these questions specifically, with algorithm names, certification bodies, and dates. That tells you everything you need to know about where cybersecurity sits in their priorities. Vague answers like "we take security very seriously" or "our data is encrypted" without technical specifics are not answers. They are marketing.
- Data-at-rest encryption What encryption algorithm is used for data at rest?
- SOC 2 Type 2 attestation Is the platform attested, by whom, and when was the last audit?
- ISO 27001 certification Is the vendor’s own organisation certified, not just the cloud provider?
- Session management How are sessions handled and protected?
- Role-based access control model Can permissions be set at company, fleet and vessel level?
- Crew data encryption Is crew personal data encrypted separately from operational data?
- Content Security Policy headers What Content Security Policy headers are deployed?
- Data residency Where is data physically stored, and can residency be guaranteed?
- Incident response What is the response timeline, and when was it last tested?
- Penetration testing Can the vendor provide test results or a summary, and the last test date?
Ask for specifics such as algorithm names, certification bodies and dates.
How Navatom Approaches Maritime Cybersecurity
Rather than treating security as a compliance checkbox, Navatom's approach starts with architecture. The platform was designed from day one as a cloud-native, multi-tenant SaaS application, not a legacy system migrated to the cloud. This is a foundational distinction that shapes each security decision downstream.
We apply the same standard to ourselves that we outlined above. Here are specifics:
- AES encryption with secure random IV generation for data at rest. Each encryption operation generates a unique initialization vector using a cryptographically secure random number generator. This prevents pattern analysis even when the same plaintext is encrypted multiple times.
- Google Tink AEAD for configuration file encryption. Tink is Google's open-source cryptographic library, designed to make it difficult to misuse cryptographic primitives. AEAD (Authenticated Encryption with Associated Data) provides both confidentiality and integrity. That means configuration data cannot be tampered with without detection.
- JWT (HMAC-SHA512) stateless authentication. No server-side sessions. Tokens are signed with HMAC-SHA512. This is a 512-bit hash-based message authentication code. There is no session store to compromise, no session fixation vulnerability, and no risk of session hijacking through stolen session IDs.
- Fine-grained RBAC at company, fleet, and vessel level. Access permissions are enforced server-side on every request, not just at the UI level. A user with vessel-level access cannot retrieve fleet-level data by manipulating API calls.
- Comprehensive Content Security Policy headers. CSP headers restrict which scripts, styles, fonts, and connections the browser will accept. This mitigates cross-site scripting attacks by preventing the injection of unauthorized code.
- Dedicated crew data encryption service. Crew personal data — passport numbers, medical records, bank details — is encrypted through a dedicated service separate from general operational data encryption. This reflects proper data classification and ensures that crew PII receives the heightened protection it requires under GDPR and maritime labor regulations.
- Multi-tenant isolation with customer-level validation. Each data access request is validated against the authenticated customer's tenant. There is no shared data space, no cross-tenant query path, and no administrative backdoor that bypasses tenant boundaries.
- Hosted on infrastructure with SOC 2 Type 2 and ISO 27001:2022 certification. Navatom's hosting infrastructure maintains these certifications. We want to be transparent: these certifications belong to the infrastructure provider, not to Navatom as an organization. We are working toward our own organizational certifications, but we will not claim what we do not yet hold.
This is not an exhaustive list. We are the first to acknowledge that cybersecurity is a moving target. New vulnerabilities emerge constantly.
Attack techniques evolve. Regulatory requirements expand.
But the foundation is cloud-native architecture with encryption-first design. This addresses entire categories of attack at the architectural level. Examples are ransomware on local servers, session hijacking, and cross-tenant data leakage. It does so before a single line of security-specific code is written.
We welcome specific, technical security questions. If you want to discuss Navatom's security architecture in detail, contact our team and we will arrange a conversation with our security-focused engineering leads.
Building a Cybersecurity Culture on Board and Ashore
Technology and regulation form only part of the cybersecurity equation. The USCG training mandate that took effect in January 2026 reflects a broader truth. Most successful cyber attacks exploit human behavior, not technical vulnerabilities.
Phishing remains the most common initial attack vector in maritime. A crew member or shore-based employee clicks a link, enters credentials on a spoofed page, or opens an attachment that deploys malware.
Effective cybersecurity training is not a one-time slideshow. It must be ongoing, role-specific, and grounded in realistic scenarios.
A master and a chief engineer face different cyber risks than a procurement officer or a crewing manager. Vessel-based personnel need to recognize GPS anomalies, suspicious USB devices, and phishing emails arriving via crew welfare internet.
Shore-based personnel need to understand social engineering, credential management, and the risks of shadow IT. That means unauthorized software or services used outside of official channels.
The USCG regulation requires all personnel to be trained, but it does not prescribe a specific curriculum. This is both a flexibility and a risk. It is a flexibility because organizations can tailor training to their operations. It is a risk because "trained" can be interpreted loosely.
Our recommendation: document everything. Record attendance, content covered, assessment results, and training frequency.
When auditors ask, you want to show a systematic program, not a folder of sign-off sheets.
Ship management software plays a role here as well. Consider a platform that enforces strong passwords and displays session information (last login time and location). It provides clear access logs and makes it easy to report suspicious activity. Such a platform contributes to a security-aware culture.
Conversely, a platform with weak password policies, no login auditing, and opaque access controls undermines every training effort.
Supply Chain and Third-Party Risk
Both the USCG regulations and NIS2 explicitly require supply chain risk management. Your security is only as strong as the weakest link. And in maritime, that chain is extensive:
- Classification societies
- P&I clubs
- Flag state administrations
- Port authorities
- Manning agents
- Equipment suppliers
- Chandlers
- Software vendors
A mature cybersecurity program assesses each of these partners. Do they encrypt data in transit?
Do they support multi-factor authentication? Have they been independently audited?
The DNV incident is again instructive. DNV was not a small, negligent operator. They are one of the largest and most respected maritime service providers in the world.
Yet their ShipManager platform was successfully attacked. The impact cascaded to 70 customer organizations. This is what supply chain risk looks like in practice. You can do everything right internally and still be compromised through a trusted partner.
When evaluating software vendors, look beyond their product features. Ask about their own vendor management. Who provides their infrastructure? What security requirements do they impose on subcontractors? How do they vet third-party libraries and dependencies?
In the modern software supply chain, a vulnerability in an open-source library can propagate to thousands of applications overnight. Vendors who actively manage dependency security (automated scanning, rapid patching, minimal dependency surfaces) are demonstrably more secure than those who do not.
Insurance Implications
Marine insurers and P&I clubs are paying close attention to cybersecurity. Cyber exclusion clauses have become standard in hull and machinery policies, and standalone maritime cyber insurance is a growing market.
Insurers are increasingly requiring evidence of cyber risk management. This is not a formality. It is a condition of coverage.
What this means in practice: your cybersecurity posture directly affects your insurance costs and coverage. An organization that can demonstrate compliance with NIST v2.0, IMO guidelines, and applicable regulations will receive better terms than one that cannot. Its proof is documented cybersecurity plans, training records, and vendor security assessments.
Conversely, an organization that suffers a cyber incident and cannot demonstrate reasonable security measures may find claims disputed or coverage limited.
The connection to ship management software is direct. If your platform vendor can provide evidence of their security architecture, you can include this in your own risk documentation. That evidence covers encryption standards, access controls, certification status, and penetration testing results.
If they cannot, you are carrying that risk yourself, and your insurer will eventually notice.
Key Takeaways
- Maritime cyber incidents surged 103% in 2025 to 828 reported cases. This is not a future problem. It is a current one.
- Five major regulations now require cybersecurity action: IMO MSC.428(98), USCG MTSA Cyber Regulations, TMSA 3 Element 13, IACS UR E26/E27, and the EU NIS2 Directive.
- The USCG training deadline has already passed (January 2026). The CySO designation and plan submission deadline is July 2027. Preparation should be underway now.
- Your ship management software is your primary attack surface. The DNV ShipManager incident proved that platform compromises cascade across every vessel and every department.
- Cloud-native architecture provides inherent security advantages over on-premise or lift-and-shift deployments. But "cloud" alone is not enough. The distinction between cloud-native and cloud-hosted matters.
- Ask the ten questions. Each ship management software vendor should be able to answer them with specifics. These are algorithm names, certification bodies, and dates.
- Cybersecurity is not solely a technology problem. It calls for governance, training, supply chain management, and organizational commitment at the leadership level.
If you want to discuss your organization's cybersecurity posture, evaluate your current software platform's security, or understand how Navatom approaches these challenges, get in touch with our team. You can also explore our full product overview to see how our platform is structured across 40+ integrated modules.
Frequently Asked Questions
What is maritime cybersecurity?
Maritime cybersecurity is the protection of digital systems, networks, and data used in maritime operations. This includes ship management software, navigation systems, communication equipment, and port infrastructure. Since IMO Resolution MSC.428(98) in 2017, cyber risk management has been a mandatory component of each shipping company's Safety Management System under the ISM Code.
The scope has expanded significantly since then. Modern maritime cybersecurity covers everything from vessel OT systems (ECDIS, AIS, engine controllers) to shore-side IT platforms (ship management software, ERP systems, email). It also covers the communication links between them (VSAT, Starlink, cellular). It is no longer a niche IT concern. It is an operational and regulatory imperative that affects vessel safety, commercial viability, and legal compliance.
Who needs a ship cyber security management plan?
The USCG MTSA Cyber Regulations took effect in July 2025. They require all U.S.-flagged vessels and MTSA-regulated facilities to have a cybersecurity plan approved by the Coast Guard by July 16, 2027. For tanker operators, TMSA 3 Element 13 requires cybersecurity planning at all four achievement levels. Oil majors use TMSA scores in chartering decisions. So this is commercially binding even where not legally mandated.
The EU NIS2 Directive extends requirements to all maritime entities operating in European waters. Under the ISM Code, every shipping company worldwide must address cyber risks in their Safety Management System. In practice, this means having a documented cybersecurity plan.
In summary: any company operating commercial vessels internationally needs a formal, documented cybersecurity plan. The question is not whether you need one, but which regulatory framework(s) set the standard for your specific operations.
How does cloud-native software improve maritime cybersecurity?
Cloud-native platforms eliminate the primary ransomware target in maritime operations: on-premise servers. Instead of maintaining your own servers, the software runs on infrastructure with enterprise-grade certifications (SOC 2 Type 2, ISO 27001). Servers of your own need patching, physical security, network configuration, and backup management.
Stateless JWT-based authentication removes the risk of session hijacking. Multi-tenant isolation with server-side tenant validation prevents cross-customer data breaches. Auto-scaling infrastructure absorbs denial-of-service attacks that would overwhelm a fixed-capacity on-premise server.
The key distinction is "cloud-native" versus "cloud-hosted." A legacy application moved onto a cloud virtual machine is still fundamentally the same application. It retains its original session management, access control model, and architectural limitations. It inherits very few of the cloud provider's security benefits.
A cloud-native platform, designed from the ground up for multi-tenancy and stateless operation, benefits from these properties inherently. When evaluating vendors, ask specifically whether the platform was built for the cloud or migrated to it. The security implications are substantially different.
What are the penalties for maritime cybersecurity non-compliance?
Penalties vary by regulatory framework. Under the EU NIS2 Directive, fines can reach EUR 10 million or 2% of global annual revenue, whichever is higher. NIS2 also introduces personal liability for management.
Under the USCG MTSA regulations, non-compliance can result in vessel detentions, civil penalties, and denial of entry to U.S. ports. For ISM Code compliance, failure to address cyber risks in your Safety Management System can result in major non-conformities during audits. These can potentially lead to suspension of your Document of Compliance.
For tanker operators, poor TMSA Element 13 scores directly affect the ability to secure charters with oil majors. This is a commercial penalty that can be more immediately painful than a regulatory fine. The financial, operational, and commercial consequences of non-compliance are now substantial. The cost of implementing proper cybersecurity measures is almost certainly lower than the cost of not doing so.
What is a Cybersecurity Officer (CySO) and when do I need one?
Under the USCG MTSA Cyber Regulations, each regulated entity must designate a Cybersecurity Officer (CySO) by July 16, 2027. The CySO is responsible for developing and maintaining the organization's cybersecurity plan and coordinating cybersecurity assessments. The CySO also manages incident response and serves as the primary point of contact for cybersecurity matters with the Coast Guard.
The role is analogous to the Company Security Officer (CSO) required under the ISPS Code, but focused specifically on cyber risks. The regulation does not mandate that the CySO be a dedicated position. It can be assigned to an existing role such as the DPA or IT manager. But the person designated must have appropriate training and authority.
The role has a broad set of responsibilities. So organizations with larger fleets or more complex operations may find a dedicated CySO more practical. The alternative is adding the role to an already full plate.


