A yacht management company in Florida called me last spring. Not about a ransomware note, for once. Their problem was a question on a new charter broker's due diligence form: "Provide your CMMC Level 2 attestation or equivalent NIST SP 800-171 System Security Plan." The broker's client base had shifted. More defense-adjacent families, a few serving government executives whose security requirements were flowing down to the vessels carrying them. The management company's IT team had never heard of CMMC. Their general counsel had, and he was not happy about the answer.
The question I get asked most often by yacht owners and their operations teams is some variant of: "Do we actually have to comply with this?" The honest answer is: it depends on factors most maritime operators have never mapped. This post gives you that map, and then explains why you should build to these standards even when the legal obligation is ambiguous.
What CMMC and NIST 800-171 Actually Are
The Cybersecurity Maturity Model Certification (CMMC) is a U.S. Department of Defense program that requires companies in the defense supply chain to demonstrate they have implemented specific cybersecurity controls before they can win or retain DoD contracts. The final rule came into effect in November 2025, rolling out in phases over approximately three years.
CMMC 2.0 has three levels. Level 1 covers fifteen basic safeguards drawn from FAR 52.204-21, satisfied by annual self-assessment. Level 2 requires full compliance with NIST SP 800-171 Revision 2, which is 110 requirements across 14 control families, and for most companies involves a third-party assessment. Level 3 adds enhanced requirements from NIST SP 800-172 and is reserved for the most sensitive programs.
NIST SP 800-171 is not a DoD-exclusive standard. The National Institute of Standards and Technology published it to give non-federal organizations a consistent set of requirements for protecting Controlled Unclassified Information (CUI) on their systems. A defense subcontractor uses it. A university with a federal research contract uses it. A maritime logistics firm with a Navy support contract uses it. The standard itself is publicly available, framework-agnostic, and well-documented.
For most private superyachts, CMMC does not apply directly. You are not in the defense industrial base. You are not formally handling Federal Contract Information or CUI. But "not directly applicable" is not the same as "irrelevant," and the distinction matters more than it sounds.
Where Superyachts Actually Sit in the Regulatory Landscape
If CMMC does not apply, what does? The answer depends on three variables: your flag state, your vessel's gross tonnage, and whether you operate commercially.
IMO Resolution MSC.428(98) came into effect in January 2021. It requires ship owners to address cyber risk in their Safety Management System (SMS), which is the management framework mandated by the ISM Code. The catch is scope: the ISM Code applies to commercial vessels of 500 gross tons or more on international voyages, and to passenger ships regardless of size. A 45-meter private yacht on a leisure voyage is not in scope. A 70-meter commercial superyacht operated for charter revenue, depending on its classification society and flag state, may be. The operational guidelines that sit beneath MSC.428(98), the MSC-FAL.1/Circ.3 Rev.3 circular approved by MSC 108 in May 2024, are non-binding but widely adopted as the practical baseline by DNV, Lloyd's, and Bureau Veritas.
The USCG's final maritime cybersecurity rule, codified at 33 CFR 101 Subpart F and in effect since July 16, 2025, applies to owners and operators of U.S.-flagged vessels required to have a security plan under 33 CFR Part 104. That covers MTSA-regulated commercial vessels. Foreign-flagged vessels are explicitly excluded from the rule. Most private superyachts, whether flying Cayman Islands, Marshall Islands, or another flag of choice, fall outside it. A U.S.-flagged commercial vessel meeting the MTSA thresholds is a different matter. The rule mandates a designated Cybersecurity Officer, annual cybersecurity assessments, a written cybersecurity plan, and crew training completed by January 12, 2026. Full compliance is due by July 2027.
GDPR is a different animal entirely. It applies to the personal data of EU citizens regardless of where that data is processed, regardless of the vessel's flag, and regardless of whether the operating company is headquartered in Europe. If you run charter operations and your guests include European nationals (and they will), you are processing passport data, payment information, health and dietary preferences, and travel itineraries that fall squarely within GDPR's scope. Maximum fines run to €20 million or 4 percent of global annual turnover, whichever is higher. For a yacht management company operating a fleet of eight vessels at typical superyacht charter rates, that exposure is not theoretical. I have seen GDPR become the leading compliance concern for operators who assumed it was a European business problem rather than a data-processing problem.
The NIST 800-171 Control Families, and the Four That Break at Sea
Even when a superyacht is not formally in CMMC scope, NIST 800-171's structure is worth understanding because it is the most rigorous publicly available framework for protecting sensitive information on non-federal systems, and it maps almost precisely onto the threat model of a working vessel.
The 14 control families in Revision 2 are: Access Control (22 requirements), Awareness and Training (3), Audit and Accountability (9), Configuration Management (9), Identification and Authentication (11), Incident Response (3), Maintenance (6), Media Protection (9), Personnel Security (2), Physical Protection (6), Risk Assessment (3), Security Assessment (4), System and Communications Protection (16), and System and Information Integrity (7). Total: 110 requirements.
In a shore-side office, most of these are straightforward to implement. On a moving vessel with rotating crew, multiple visiting vendor technicians, port authority inspections, and a charter guest population that changes every two weeks, four of these families require deliberate rethinking.
Physical Protection (6 requirements) assumes a fixed facility with controlled access points, cameras, and badge readers. On a vessel, the "facility" moves. Crew rotate on and off at every port. The engine room housing your compute stack is accessed by marine engineers, third-party maintenance technicians, and, in some jurisdictions, customs inspectors with broad authority. Physical protection on a vessel means: access logs for the server space become a manual sign-in procedure verified against crew and contractor manifests; camera coverage of compute infrastructure gets built into the vessel CCTV plan; and media disposal (decommissioning a drive) has to happen against a procedure rather than being handed to the nearest IT recycling service.
Maintenance (6 requirements) requires that all maintenance of organizational systems be performed by authorized individuals and that remote maintenance sessions be logged and controlled. On a vessel, remote maintenance almost always means a shore-side vendor connecting over the satellite link to diagnose a fault in the entertainment system, the vessel management system, or the AI compute stack. If that session is not logged, if its credentials are not revoked when the session ends, and if the session is not supervised, you have an open channel into your internal network that nobody is watching. I have seen this exact configuration persist on vessels for months after the vendor work was complete.
Incident Response (3 requirements) requires an operational IR capability, testing of that capability, and tracking and reporting of incidents. The challenge at sea is that your IR plan needs to function when your only connectivity is a degraded VSAT link, a single Iridium data channel, or nothing at all. Most maritime IR plans I have reviewed were written by compliance consultants who assumed broadband throughout. They specify steps like "contact your managed security provider" and "engage your cloud SIEM" without acknowledging that at anchor in the Maldives at 2am, neither of those is an option. A vessel IR plan has to work with the resources physically present on the vessel, full stop.
System and Communications Protection (16 requirements) covers network segmentation, encrypted communications, and denial of unauthorized connections. A superyacht typically runs four or five distinct network segments: guest Wi-Fi, crew network, operational technology (navigation, propulsion, HVAC), management network, and any AI compute infrastructure. The requirement to keep those segments separated and traffic encrypted across all of them is solvable, but it requires a network architecture that most vessels have never designed deliberately. I covered the threat this creates in more detail in my recent commentary on AI-driven zero-day discovery. The short version: if a compromised guest device on your guest Wi-Fi can reach your operational technology network, a navigation-system breach is a matter of when.
GDPR: The Charter Operator's Real Exposure
I spend more time on GDPR than on CMMC with most superyacht clients, because the exposure is more immediate, more quantifiable, and closer to a real business consequence.
Charter operators process EU citizen data in multiple categories simultaneously. Passport and nationality data for visa and port clearance. Payment card data for charter fees and provisioning. Medical and dietary information from guest preference sheets. Biometric data in cases where yachts use fingerprint-based cabin access or safe controls. Under GDPR, the categories covering health information and biometrics are "special category" data carrying heightened obligations: explicit consent, specific purpose limitation, and appropriate technical safeguards.
The operational problem is that most of this data is processed on systems designed for hospitality, not for privacy compliance. Booking platforms, provisioning systems, crew management software. These are rarely configured for data minimization, retention limits, or right-to-erasure workflows. When a charter guest submits a deletion request (they are entitled to do so under Article 17), most yacht management companies have no coherent answer for where that guest's data actually lives across their systems. That is a GDPR audit finding waiting to happen, and after a breach, it becomes an aggravating factor in the penalty calculation.
The practical answer for charter operators is a data inventory conducted before anything else. Where does guest PII live? Which third-party processors receive it? How long does it persist, and can you actually execute a deletion? An on-vessel system that processes guest data locally, rather than syncing it to a cloud platform with its own retention schedule and sub-processor chain, gives you substantially more control over that lifecycle.
The Threat Model at Sea Is Not Your Office's Threat Model
Most cybersecurity frameworks were written for fixed organizations with full-time IT staff, broadband connectivity, and a physical perimeter that does not change weekly. The superyacht threat model has three characteristics that do not fit those assumptions.
First, the attack surface changes with every port of call. New vendor devices connect to diagnose engines, calibrate entertainment systems, and service medical equipment. Each of those is a potential ingress point, and your network perimeter in Monaco is different from what it was in Palma.
Second, response capability is geographically constrained. If a breach is detected at 3am in the South Pacific, there is no forensics team to dispatch. Your incident response is whatever is physically on the vessel and whatever your crew can execute without external support. As I covered in Why Cloud AI Doesn't Work at Sea, this constraint applies to security tooling exactly as it applies to AI inference: anything that depends on an external service will fail at the moment you need it most.
Third, the satellite connectivity link is itself an attack surface. As the team has documented in detail in the satellite connectivity analysis, the uplink is a narrow channel managed by third-party providers with their own security posture. Traffic traversing that link is exposed to interception and manipulation at the provider level and at any transit point. Systems that send sensitive data over satellite are accepting risks that a shore-side organization would never accept from a commercial ISP.
How On-Vessel AI Changes the Compliance Math
This is where the knowledge-ark model becomes a compliance asset rather than purely a resilience argument.
A superyacht running AI inference locally, with models and data entirely on-vessel, has a materially smaller attack surface than one routing inference requests to a cloud provider over a satellite link. Every NIST 800-171 control related to System and Communications Protection is easier to satisfy when sensitive data does not leave the network boundary. Encryption in transit, session logging, network segmentation: all of these requirements still apply, but they apply to an internal network rather than to an internet-exposed API endpoint traversing infrastructure you do not control.
The GDPR equation shifts for the same reason. Guest preference data used to personalize the on-vessel concierge experience, dietary restrictions, cabin temperature settings, language preferences, never needs to touch a third-party cloud platform. You process it locally, govern it locally, and when the charter ends and the guest exercises their right to erasure, you can execute that deletion comprehensively. The sovereign AI posture is not only about operational resilience when the satellite link goes down. It is about keeping your data inside your hull, where your policies actually govern it, and where a breach in a cloud provider's infrastructure cannot expose your guests' passports.
Building Your Vessel Security Posture: Where to Start
If you have gotten this far and are wondering what to actually do, the answer is not to hire a CMMC assessor and work through 110 requirements line by line. That is overkill for a private vessel not in the defense supply chain.
The practical approach is to treat NIST 800-171 as a diagnostic rather than a mandate. Read through the 14 control families. For each one, ask a single question: do we have a documented, testable practice that addresses this? Where the answer is no, or we think so, that is your gap list. Prioritize by consequence: Incident Response first, because an untested plan at sea is worse than no plan when 3am comes. Physical Protection second, because the compute stack is the hardest asset to replace if it is physically compromised or stolen. System and Communications Protection third, because network segmentation is what prevents a guest Wi-Fi incident from cascading into a navigation-system event.
For charter operators, start with a GDPR data inventory before anything else. Know where the data lives. Know who your processors are. Know whether you can actually execute a deletion request. That single exercise surfaces the most immediate exposure and is the most defensible thing you can show a regulator or an insurer if something goes wrong.
The compliance burden at sea is fragmented and flag-specific. There is no single checklist that works for every vessel. But the frameworks exist, the controls are well-documented, and the threat model, when you map it honestly, tells you most of what you need to know about where to start.
When you are ready to build a vessel security posture that actually works at sea rather than on paper, reach out to ShipboardAI. The compliance questions are always specific to the vessel, the flag state, the charter model, and the owner's risk tolerance. That is where the real work begins.