NIST Now Counts Ships as OT — An E26 Practitioner Reads SP 800-82r4 Section 2.5.4
NIST's new OT guide now has a section on ships. It explains well why vessels are hard to secure. What it leaves out is who is responsible over the ship's life, the criteria for design decisions, and the link to safety.
- LinkedIn : https://www.linkedin.com/in/abysstoinfinity
In August 2026, the US Coast Guard (USCG) and the FBI boarded US-bound tankers to assess their OT. A month later, on 21 September, NIST released the initial public draft of SP 800-82 Rev.4 with a vessel section for the first time: 2.5.4 Maritime/Vessels. In the same season that regulators stepped aboard, the US standards body wrote ships into its OT guide.
I coordinate IACS UR E26/E27 compliance on newbuildings from the owner's side. These are my notes from reading the draft in that role: what stood out, what bothered me, and what I would like to say before comments close on 30 November. Treat them as field impressions rather than answers.
1. The regulators came aboard
A few years ago I often heard "it won't reach OT" in meeting rooms. I hear it much less now. My sense is that ransomware is moving from shore-side ship management systems toward the ship itself, and regulators are moving from document review to on-board inspection. Three scenes from recent years stand out to me.
| When | What happened | Key point |
|---|---|---|
| Aug 2026 | Two US-bound tankers, including VL Prosperity, suspected compromised | Iran's Mehr news agency reported about 30 hours of lost communications while transiting the Strait of Gibraltar (not confirmed by US officials). USCG and FBI boarded in the Gulf of Mexico on 21 and 24 August to assess OT and IT |
| From Jul 2025 | USCG cyber rule for the Marine Transportation System takes effect | Immediate incident reporting; stricter PSC cyber scrutiny signalled for foreign-flag ships |
| Jan 2023 | DNV ShipManager ransomware | Per DNV, 70 customers and about 1,000 vessels affected. Two months later, work to restore the full service was still ongoing |
What the tanker boardings made me think about
Reading the Industrial Cyber report, what caught my eye was who went aboard. According to the USCG statement on the 21 August boarding, the team included USCG law enforcement personnel, a USCG Cyber Protection Team (CPT), a vessel inspector and an FBI Cyber Action Team. The purpose was to assess the ship's OT and IT systems. No operational disruption or environmental impact was reported.
Whether this was ransomware, and who was behind it, has not been confirmed. Even the 30-hour communications loss comes from Mehr, and the same report made quite specific claims, such as reduced engine cooling flow, that have not been verified. A communications outage can also have mundane causes, such as a satellite link or equipment fault, so a plain communications failure is still possible. I think it is too early to cite this as a case of ship OT ransomware.
Still, it left me with a different question. If an inspector comes aboard and says "show me the logs for this system" or "who approved this remote session", can we answer with the E26 documents we produced at delivery? We have drawings and test reports, but who holds the material that explains the actual state of the ship six months into operation? I do not have a clear answer yet.
The USCG rule is not just about US-flag ships
At first I set it aside: our ships are not US-flagged. The USCG final rule was published on 17 January 2025 and took effect on 16 July 2025, and it applies to US-flagged vessels, Outer Continental Shelf (OCS) facilities and MTSA-regulated facilities. Looking at the implementation timeline again, though, it was not something to set aside.
In the final rule, USCG requested comment on a possible two-to-five-year delay for US-flagged vessels, but as of September 2026 no delay has been adopted.
In the same notice, USCG said it would scrutinise foreign-flag vessels more closely at port state control (PSC) for poor cyber management linked to ISM Code implementation. It lists deficiencies, detention, denial of entry and movement controls by the Captain of the Port (COTP) as possible outcomes. For ships trading to the US, whatever their flag, I expect the same questions sooner or later.
2. What 800-82r4 Section 2.5.4 says
Section 2.5.4 runs to about three pages. In my own words, it treats the ship as mobile OT whose responsibilities are spread across many parties, and then describes functional zones, architectural characteristics, and maritime-specific challenges and recommendations in turn. It includes one example architecture for a cargo vessel (Fig. 12).
The draft announcement partly explains why it appears now. The first listed change in this revision is an expanded introduction to OT sectors, and maritime vessels came in alongside BACS, water and wastewater, food and agriculture, freight rail, and IIoT and cloud convergence. NIST did not single out shipping. The ship got a seat as Rev.3's ICS-centred text was broadened sector by sector. Even so, as far as I know this is the first US federal technical document to describe ship OT in CSF 2.0 terms, and that felt like no small change.
One thing bothered me, though. The section cites no sources at all. There is no E26/E27, no IMO document, and no source for Fig. 12. Among the sector sections, only water and wastewater cites anything (SP 1800-45); the rest have no citations. Appendix D does link to the IMO guidelines, but to Rev.3, even though Rev.4 was already out in May 2026. The substantive difference between Rev.3 and Rev.4 is small (a second IAPH guideline added to the reference list, and paragraph 3.1 now cross-refers to the definition in 2.1 instead of repeating it), but not pointing to the current edition is a signal in itself. The content reads as if someone who knows ships wrote it, which made it all the more frustrating that I could not trace the basis.
Functional zones
| Zone | Main components |
|---|---|
| Bridge/Navigation | AIS, ECDIS, GPS/GNSS, radar, weather data, VDR |
| Propulsion and machinery | Engine control, cooling, fuel management, boilers, thrusters, power management |
| Safety and security | Fire and gas detection, watertight door control, CCTV, PACS, PA/GA |
| Cargo, ballast and power | Loading computer, tank level gauging, ballast water management, power generation and distribution |
| Engine control room | Automation servers, historians, HMIs, workstations |
| Shipboard business network | Administrative PCs, maintenance systems, passenger support, crew welfare |
| Ship-to-shore | Ship-to-shore communication such as GMDSS |
Architectural characteristics
Maritime-specific challenges and recommendations
The passage I was most glad to see was the one on crew rotation. Accounts have to be created and removed every rotation, the ship may lack central identity management or rely on shared accounts, and so the draft recommends role-based access aligned to shipboard positions and cyber turnover briefings at crew change. That is hard to write unless you have sailed or watched a crew change up close. I had not seen it in other OT documents, and it made me curious who wrote it.
3. Where it overlaps with E26/E27, and where it is empty
Anyone working on E26 who reads 2.5.4 keeps thinking "this is about us": zone segmentation, untrusted networks, remote access, USB, many OEMs on one ship. Yet E26/E27 appear nowhere in the body. They are only links in the resource list in Appendix D, and that appendix is due to move to the web in the final version. After that, no link will remain. In the table below I also look at E27, the system-level requirements.
The two documents are, of course, different in nature. E26 is an IACS Unified Requirement (UR) that each class society writes into its own rules, applying in principle to ships contracted for construction on or after 1 July 2024 (the exact scope and timing vary by society and ship type). 800-82r4 is voluntary guidance. One says "prove this"; the other says "here is why it is hard and how to think about it". So I put the overlaps and gaps into a table in my own way.
| What 2.5.4 says | Corresponding E26/E27 requirement | Alignment |
|---|---|---|
| Functional zones, segmentation of mixed-criticality systems | E26 security zones and network segmentation, zone and conduit design | High, but 2.5.4 has no criteria for zone boundaries and no conduit concept |
| Interfacing with untrusted systems | E26 boundary protection for untrusted networks | High, though the term is not defined |
| Dependency on remote access | E26 remote access control, E27 security capabilities for remote sessions | Medium. 2.5.4 only acknowledges the need; the level of control is left to the general text in 4.2.1.8 (Remote Access Controls) |
| Insider threat, USB limits | E26 control of mobile and portable devices, physical access | High |
| Crew rotation, position-based RBAC | E26 user accounts and access control, handover to operation | 2.5.4 is more concrete about operational reality |
| Maritime protocols without authentication or encryption | E27 communication integrity, authentication and other system security capabilities | 2.5.4 only names the problem; E27 requires suppliers to solve it |
| (none) | E26 CBS categories (Category I–III per UR E22), asset inventory, deliverables by design, testing and delivery phase | Not covered in 2.5.4 |
| (none) | E26 Respond: local independent control, fallback to a minimal risk condition | Linked only conceptually to the analog backup and resilience design in 5.4 |
Two thoughts came after building the table. First, as a piece that argues why ships are hard, 2.5.4 is quite good. I would hand it to an owner's IT team or a shipyard design team meeting E26 for the first time, as background. Second, if US stakeholders start making demands on the basis of 800-82, then every time we answer with E26 deliverables we will have to interpret afresh, because there is no clause-to-clause mapping. Who should build that mapping, I cannot say yet.
4. The space the document leaves empty
Section 2.5.4 explains well why ships are hard. I covered the formal problem of missing sources above, so here I look only at content. What remained after reading was not "a few items are missing" but "a whole layer is missing", three times over.
No time axis
Section 2.5.4 draws the ship in operation as a single snapshot. But a ship moves through design, construction, HAT, sea trials, delivery, operation and modification, and responsibility passes from the shipyard to the owner, then to the manager and rotating crews. The crew-change problem the document raises, and the handover of accounts, asset inventory and security settings at delivery, which is where things most often go wrong in practice, are both gaps created by the missing time axis. Without saying who is responsible for what, and until when, "shared responsibility model" stays a declaration.
No decision criteria
The document goes as far as "strongly segment", "separate from untrusted systems" and "remote access is unavoidable". It gives no criteria for where to cut a zone, under what conditions to allow remote access, or what counts as sufficient segmentation. There is description, but no basis for judgement. In a design review, practitioners need criteria, not direction, and those criteria will differ between a cargo ship, a cruise ship and an LNG carrier. That the only example is a cargo ship is, in the end, the same problem.
No link to safety
The last question for ship OT is "does the ship still get there safely if it is compromised?" Keeping steering and propulsion under manual control during a cyber incident is the core of E26 Respond, and 800-82r4 itself talks about a consequence-driven defence mindset in 2.3 and analog backups in 5.4. Yet 2.5.4 connects to neither. For me, the biggest gap is that the vessel section is not tied to the safety principles in its own document.
Section 2.5.4 explains why ships are hard. It does not say who is responsible over the ship's life, by what criteria to decide, or how it keeps the ship safe.
5. What documents should come next
These gaps cannot be filled by editing 2.5.4. They need documents at a different layer. Matching the three layers above, what I picture also has three parts.
6. How this might unfold
This is closer to imagination, though not imagination without grounds. In its 2017 draft NVIC, USCG mentioned both NIST CSF and SP 800-82. The final NVIC 01-20 of 2020 dropped the enclosure that contained 800-82 and kept only the recommendation of NIST CSF. It covered MTSA-regulated facilities, and it said vessels were outside its scope, leaving them for later consideration. Section 2.5.4 now sits on top of that empty space.
So the sequence I picture is this.
There is one scenario I watch for: the documents keep growing without referring to one another. If USCG asks for a CSF-structured plan, class for E26 deliverables and the flag for IMO documents, the same ship ends up producing three sets of evidence. Section 2.5.4 itself names "fragmented governance" as a problem. The outcome I most want to avoid is the document becoming one more fragment.
7. Closing
My first reaction on reading 2.5.4 was relief. The things we had to explain in every meeting, that ships move, links drop, people change and vendors are many, have been written down by the US standards body. It is a three-page section, but we can now say "NIST sees it the same way".
At the same time, as I have argued throughout, the gaps are clear. There are no sources, nothing after delivery, and no bridge to E26. NIST cannot fill these alone. They get filled when the people who design, build, survey and operate ships say what is missing.
A draft is a document with a fixed window for saying so. Comments are open until 30 November 2026, at sp800-82rev4@nist.gov. I plan to send mine. If others doing the same work write even one line, the next edition may carry a little more of our story.
Sources
This article reflects the author's personal reading of a public draft and does not represent the views of any employer, class society or authority. Check the primary documents before relying on any statement here.
Owner-side maritime cybersecurity advisor covering IACS UR E26/E27 compliance, zone and conduit design, and OT/IT security architecture for commercial vessels — working across LR, ClassNK, DNV, ABS, and BV newbuilding projects.
🌐 More Articles ↗⚓ Join the ShipPaulJobs Community
Join →
This is an important shift in perspective.
ReplyDeleteWhen ships are treated as OT environments, cybersecurity must go beyond IT protection and address operational continuity, safety, asset visibility, network segmentation, and lifecycle management.
The convergence of NIST OT guidance and IACS UR E26/E27 shows that maritime cybersecurity is becoming an integral part of ship design, operation, and safety — not simply an IT issue.
This is a conversation our maritime community needs to keep having.