USCG details maritime cybersecurity assessments and the waiver and equivalency process

The US Coast Guard has issued two guidance documents for its maritime cyber rule: how to scope the required cybersecurity assessment, and how to request waivers and equivalencies.

This article is also available in French.

Two guidance documents in early June

In the first week of June 2026, the US Coast Guard issued two documents supporting its maritime cyber rule. The first, Policy Letter 01-26, signed on June 2 by Captain Robert C. Compher (COMDT CG-5PC), covers the initial scoping and process of the Cybersecurity Assessment (CSA). The second, signed on June 3 by C. N. Parham, Chief of the Office of Maritime Cybersecurity Policy (CG-MCP), is a work instruction (reference MCP-WI-002) on waivers and equivalencies. Both are advisory. They add no new obligation and explain how to meet the ones already set out in 33 CFR Part 101, Subpart F.

These documents extend the path opened by the final rule, “Cybersecurity in the Marine Transportation System”, published on January 17, 2025 and effective July 16, 2025. Codified at 33 CFR Part 101, Subpart F, it requires US-flagged vessels, port facilities, and Outer Continental Shelf facilities regulated under MTSA to designate a Cybersecurity Officer (CySO), conduct an assessment, and then produce a Cybersecurity Plan (CSP). After Policy Letter 01-25 of October 2025 on training and NVIC 02-24 CH1 on incident reporting, the two June notes address the upstream end of the system: how to set the boundaries of the assessment the plan flows from, and how to request relief when a requirement does not fit.

Scoping the assessment as a risk filter

The core contribution of the scoping note is a reversal of method. Rather than starting from the systems an organisation already considers critical, the Coast Guard asks operators to inventory every system, dependency, and interface first, then filter that perimeter by risk. The stated reasoning is that too narrow a view wastes resources and leaves unrecognised attack paths in place, while a broad inventory lets an entity confirm or discard its initial assumptions about what actually matters.

The text also defuses a common worry among operators. A wide perimeter does not oblige an entity to address every result with a heavy measure in the first plan. The assessment serves as the basis for aligning the risk management strategy with the regulatory requirements, with annual revalidation that the plan still matches current threats, vulnerabilities, and the organisation’s risk tolerance. The initial assessment is described as the first step in a continuous maturity process, fed by updates, audits, and exercises.

Internal, external, interfaces: a map that accepts dependencies

To structure the inventory, the note sets out three categories of assets. Internal networks are the systems an entity owns and controls technically, where it holds the administrative rights to patch and configure: onboard administrative workstations, cargo control systems, ECDIS, physical access control, CCTV, down to integrated artificial intelligence tools. External networks are the dependencies an operator uses without controlling them, as a subscriber or user: internet service provider, shore power, satellite navigation and communications, cloud software, supply-chain platforms, bring-your-own-device, and again AI tools and models. Interfaces are the points where systems connect and exchange information, whether digital (VPN, remote access), physical (Ethernet ports, USB-connected laptops), wireless (Wi-Fi, Bluetooth), or human (shared accounts, visiting vendor technicians).

Two drafting choices deserve a maritime reader’s attention. Naming satellite communications and navigation explicitly as external dependencies brings GNSS jamming and spoofing into the assessment perimeter without any detour. And the fact that the Coast Guard does not regulate vendor networks does not let the operator off the hook: where a third-party service can lead to an incident, an operational disruption, or a Transportation Security Incident (TSI), the assessment has to analyse that dependency and the plan has to address it.

A qualitative and technical exercise

The annexed guide runs through a staged progression. Preparation sets a shared frame (common understanding, risk tolerance, assumptions, and constraints), lists the functions the entity needs to operate, then builds and categorises the asset inventory. The conduct phase analyses, for each asset, the threat sources, the technical and procedural vulnerabilities, the likelihood, and the impact, in order to derive a level of risk, identify priority assets, and classify the critical systems. On that last point the note takes a cautious stance: where the loss of confidentiality, integrity, or availability of a system could “maybe” cause a TSI, the asset must be designated as critical and examined in depth. The final phase records the results in a report kept with the plan and handled as Security Sensitive Information under 49 CFR 1520.

The text sets a bar that is far from trivial. A complete assessment must combine qualitative and technical analysis and cannot rest on a visual check or a cursory review. That dual nature calls for real competence, which the note ties to the CySO role and to the operator’s duty to bring in the expertise needed. The scoping rests on NIST references (the Cybersecurity Framework and the SP 800-30, 800-53, 800-37, and IR 8286 series) while leaving entities free to use another standard of equal rigour, provided they name it in the report.

Waivers, equivalencies, and temporary deviations

The MCP-WI-002 instruction organises three routes under 33 CFR 101.665. A waiver grants relief from a requirement the operator considers unnecessary given the nature or operating conditions of the entity, with the requirement then lifted. An equivalency keeps the requirement in place but allows a substitute measure whose effectiveness meets or exceeds what the regulation prescribes. A temporary deviation covers a short-lived inability to comply, allowing operations to continue while the entity returns to compliance.

What ties the three routes together runs through the whole scheme: the cybersecurity assessment must be complete before any request, because it forms the evidentiary basis, including where it concludes that there is nothing to assess. The guide draws a distinction that matters in practice: a requirement that does not apply, for want of the system concerned, is not waived but recorded as “Not Applicable” in the plan, with a written explanation. The example given is multi-factor authentication required for remote access to operational technology (OT): a vessel with no remote OT access does not seek a waiver, it records the requirement as not applicable.

The text also closes several doors. A request cannot rest on cost, staffing, convenience, or a vendor’s reluctance alone; it has to be grounded in technical, architectural, or operational constraints and to set out the risk accepted. Pre-emptive waivers, sought for hypothetical future architectures, are ruled out. An equivalency, by contrast, may rest on compliance with a classification society standard or a recognised cybersecurity framework, provided the operator supplies a crosswalk showing that the sections relied on meet or exceed the intent of the regulatory requirements, together with proof of certification. Waiver requests for vessels and facilities go to the Commandant (CG-5P), those concerning Outer Continental Shelf facilities to the cognizant District Commander, and the instruction provides an annexed simplified letter template for entities with minimal or no technology, typically those running fully manual operations.

A method worth reading beyond US waters

These documents apply only to entities under US jurisdiction, yet their value for European players lies in the method they make explicit rather than in their binding reach. The logic of a full inventory followed by a risk filter, the attention paid to satellite and cloud dependencies, and the bar that rules out a purely visual audit all line up with the approaches already supported in France by ANSSI around EBIOS Risk Manager, and with the sector obligations that the NIS2 directive is gradually bringing into the daily work of ports and shipowners. The equivalency route, open to classification society standards and recognised frameworks, offers a concrete hook: an operator already certified or aligned with a cyber-resilience standard can put that work forward instead of redoing it, as long as it establishes the match with the requirements at issue. The building blocks exist on both sides of the Atlantic, and the question shifts to putting them to work: having the analytical competence, genuinely bringing the supply chain and third-party services into the perimeter, and keeping up the annual reassessment. At European level, convergence of scoping references, supported by ENISA and by exchanges between port authorities, would spare each member state rebuilding its own inventory granularity and would let operators working under several regimes build on a single analysis rather than duplicating it.