This is the sixth post in our MTSA cybersecurity series. In the first post, we introduced the crawl, walk, run approach we’re using to work through the regulation. In the second, third, fourth, and fifth posts, we covered asset inventory, network segmentation, resilience, and routine maintenance. This post picks up with device security, the first of two technical control requirements under 33 CFR 101.650: device security under 101.650(b), and account security, the subject of the next post, under 101.650(a).
Fifteen Raspberry Pis, still plugged in, still powered on, sitting on a flat network with a straight shot to the internet. Installed years earlier to run a bank of smart TVs that don’t exist anymore. Not one patch since the day they went in. In a room of fifteen staff during the assessment, exactly one person remembered they were there at all, and the best they could offer was “something to do with making smart TVs.” Nobody owned them. Nobody had touched them. Nobody had written them down anywhere. They went into the final report as a formal finding, and the client tore out all fifteen.
That’s what a device security program looks like when it exists on paper and nowhere else. It’s also, almost word for word, why 33 CFR 101.650(b) exists.
Nobody writes a rule this specific for no reason. The marine transportation system runs on the same tired mix of legacy OT, bolted-on IT, and third-party equipment that’s made every other critical infrastructure sector a target. Marsh McLennan and Dragos put annual global OT cyber risk at $31.1 billion in 2025; IBM’s Cost of a Data Breach Report the same year found a meaningful share of breached organizations took an operational hit because of it. Ask most owners and operators what’s actually on their network right now, what’s approved to be there, and what it’s configured to do, and you won’t get a straight answer, and the Pis above are exactly what that blind spot looks like in practice. Get it wrong, and a U.S.-flagged vessel doesn’t just fly a flag, it gets flagged.
Device security measures land in Section 6 of the Cybersecurity Plan. Each owner or operator, or the designated CySO, has to have four things in place, documented, and ready to hand over the moment the Coast Guard asks: an approved hardware, firmware, and software list; executable code disabled by default on critical IT and OT systems; an accurate inventory of network-connected systems, with critical IT and OT specifically called out; and a network map and OT device configuration documentation. Nobody builds any of these in one pass, so each one gets a crawl, a walk, and a run.
Crawl: get an honest baseline of what’s installed, running, and connected
Approved hardware, firmware, and software list: Read literally, “nothing gets installed unless it’s on the list” sounds like enumerating every hardware model, firmware revision, and software version on the network, a fool’s errand in a fleet with twenty years of vintage sitting on it. Pull what’s actually installed, host by host, and check it against the baseline by hand. Anything that doesn’t map to an asset-class baseline gets flagged.
<!-- Enumerate inventory on Windows with the following in PowerShell -->
<!-- Note: only sees MSI-installed software, and can trigger a repair/reconfigure of installed packages -->
Get-WmiObject -Class Win32_Product | Select Name, Version
<!-- For a faster pull that also catches non-MSI and per-user installs, use the following in PowerShell -->
Get-ItemProperty @(
'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*',
'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*',
'HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*'
) -ErrorAction SilentlyContinue |
Where-Object { $_.DisplayName } |
Select-Object DisplayName, DisplayVersion, Publisher, InstallDate |
Sort-Object DisplayName
<!-- On Linux, enumerate with the following: -->
<!-- Debian -->
dpkg-query -W -f='${Package}\t${Version}\n'
<!-- RHEL -->
rpm -qa --qf '%{NAME}\t%{VERSION}\n\n'Executable code controls: This isn’t OT-only. PowerShell on a domain controller and unrestricted scripting on an engineering workstation are the same problem in the Coast Guard’s eyes, and the rule treats the critical IT side no differently than the OT side. Turn on native OS allowlisting in audit mode first, don’t touch enforcement yet, and see what actually tries to run. On Windows, AppLocker or WDAC in audit-only mode, then check the results in Microsoft-Windows-CodeIntegrity/Operational (WDAC) or the AppLocker log under Applications and Services Logs.
Confirm the posture in PowerShell or Linux by using the following:
<!-- Check PowerShell execution policy -->
Get-ExecutionPolicy -List
<!-- Pull PowerShell script-block logging activity (Event ID 4104) -->
Get-WinEvent -LogName "Microsoft-Windows-PowerShell/Operational" | Where-Object {$_.Id -eq 4104}
<!-- On Linux, check what's actually allowed to run -->
<!-- SELinux -->
sestatus
<!-- AppArmor -->
aa-status
<!-- Pull SUID binaries as a starting exception list -->
find / -perm -4000 -type f 2>/dev/nullNetwork inventory: It’s easy to read this as an OT asset inventory with an IT footnote. It isn’t. Critical IT systems, domain controllers, jump servers, historian databases, need the same rigor as the PLCs. We covered the mechanics of building this inventory, ARP pulls, passive discovery, the tools you likely already have, in depth in the second post in this series. The device security angle is narrower: reconcile that same inventory against whatever asset-class baseline and approved list exists, including the critical IT side, domain controllers, jump servers, historians, not just the plant floor, and flag anything that doesn’t map to it. OT-CERT’s free Asset Management Toolkit is a decent place to start one from zero if you haven’t already.
Network map and configuration documentation: This turns a device list into an understanding of how systems actually talk, where segmentation really is, and what normal looks like. Export the running configuration from every firewall and switch, show running-config on most Cisco-style CLIs, the equivalent export function on anything else, and manually trace every allowed path between zones against the network diagram, rule by rule. Anything that lets an OT zone talk to the DMZ or corporate that isn’t on the diagram gets flagged on the spot.
Walk: turn that baseline into a scheduled, ticketed process
Approved hardware, firmware, and software list: Script that same pull as a scheduled task or cron job across every host on the critical asset list, dump the output to a file, and diff it against last month’s. New entries get a ticket and either an approval or a removal, not a shrug.
Executable code controls: Flip enforcement on for the systems that matter, domain controllers, jump servers, engineering workstations with a path into OT, push the policy through whatever config management is already in the shop, and confirm it actually landed by re-running the same audit-log query fleet-wide instead of trusting the one test box. Every carve-out gets a ticket, a business reason, and a review date.
Network inventory: Script the ARP pull across every network device on a schedule, SSH into each device, dump show arp output, diff it against last week’s, and flag any MAC address that’s never been seen before instead of finding out about it during an assessment.
Network map and configuration documentation: Script the config pull on a schedule, SSH or API export from every firewall and switch, automatically diff it against last quarter’s baseline, and flag any new rule that opens cross-zone traffic before it sits there unnoticed for a year.
Run: make an unapproved change a same-day alert, not next year’s finding
Approved hardware, firmware, and software list: Feed live network discovery, what’s actually talking on the wire, into the same baseline automatically, so a firmware revision or an installed package nobody approved shows up as a delta within a day, not a finding a year later. Every open port, whether it’s on a switch or a pier, is an invitation, and adversaries don’t need a pilot’s license to dock at one.
Executable code controls: Wire the code-integrity and PowerShell operational logs into whatever’s already ingesting logs (SIEM, syslog, a script that emails someone) so an unauthorized execution attempt on a critical asset is an alert within minutes, not a forensic artifact somebody finds three months later.
Network inventory: Passive taps feed live traffic into an automated asset-matching process, so a new MAC address on the wire triggers an alert the same day, and active collection fills in what passive traffic won’t surface, firmware version, OS, patch level. A collection management framework (CMF) documents, asset class by asset class, what log answers what question, so nobody’s guessing mid-incident. Think of it as the ship’s log for your cyber environment. OT-CERT’s free CMF template and the original CMF whitepaper both cover how to build one.
Network map and configuration documentation: Parse every firewall, router, and switch config change as it happens, syslog output or a config-change webhook feeding an automated diff, and flag an unapproved cross-zone path in real time instead of at the next scheduled review. Call it a network map or call it a chart, either way, sailing by an old one is how you run aground.
Strip the legal language and it’s one thing: know what’s on your network, what’s supposed to be there, what it’s configured to do, and how it talks to everything else. Visibility problem first, paperwork problem second.
The approved list gets built once and never touched again. It goes into the Cybersecurity Plan submission and sits there while the environment changes underneath it. Try to log every unique hardware and firmware combination instead of building at the asset-class level, and the list gets too big for anyone to actually check before installing something new.
Everyone treats this as an OT exercise and forgets the “critical IT” half. The rule says critical IT and OT in the same breath, twice, and most teams still walk in assuming device security is a plant-floor problem. Skip the domain controller or the jump server because IT owns it, and that’s not an oversight the Coast Guard is likely to shrug off.
Nobody’s assigned to notice when a device stops mattering. Fifteen smart-TV Pis don’t turn into a finding because someone’s careless. They turn into a finding because nobody owns the job of asking whether a device installed five years ago for a purpose that no longer exists should still be plugged in.
Network maps describe the network you designed, not the one you have. Segmentation drifts, firewall rules pick up exceptions nobody remembers granting, and a diagram from commissioning rarely matches what the configs actually allow years later. This isn’t unique to maritime. Across other regulated environments where the requirement is to list every asset crossing the OT boundary into a DMZ or corporate network, Dragos finds unlisted assets sitting on that boundary in roughly 40% of engagements at regulated organizations, and in about 80% of engagements at organizations with no regulatory requirement to look at all. Workstations, PLCs, servers, whatever got plugged in over the years and never wrote itself down. Manufacturing is the worst offender by a wide margin. Dragos won’t tell a client whether that puts them out of compliance, that call belongs to their compliance and legal team, but the standard advice is to go check before an actual auditor finds it first. The Coast Guard’s own Small Entity Compliance Guide walks through these same four requirements in plain language, worth checking your own approach against before that auditor shows up.
Forty percent. Eighty percent. Read that again. Most networks in this country, regulated or not, would fail this requirement today if someone checked, and most of them haven’t been checked. The Coast Guard is about to start checking. Section 6 isn’t asking for a plan on paper; it’s asking whether anyone actually knows what’s plugged into their network. Right now, for most owners and operators, the honest answer is no.
Device security only works if you know what’s plugged in. But knowing what a device is doesn’t tell you who’s allowed to touch it, or from where. That’s account security, the identity and access control requirements the Coast Guard paired with device security to form the technical core of the rule, and it’s the subject of the next post in this series.
Most maritime operators would fail this requirement today if audited. See where you actually stand before the Coast Guard does.
