This is the second post in our MTSA cybersecurity series. In the first post, we broke down what the regulation actually requires and introduced the crawl, walk, run approach we’re using to work through it. That framework starts here, with the requirement everything else depends on.
With a regulation as sprawling as the Maritime Transportation Security Act (MTSA) cybersecurity requirements, prioritization isn’t just helpful; it’s essential. The logical first step is Asset Inventory, codified under Device Security Measures at 33 CFR 101.650(b)(3):
Maintain an accurate inventory of network-connected systems, including designation of critical IT and OT systems.
Simple sentence. Deep Waters.
You can’t protect what you can’t see, and for OT and critical IT systems, that starts with knowing they exist.
For years, the conversation around critical systems in maritime environments has been dominated, understandably, by Operational Technology (OT). OT makes the things move, load, and drain. It’s tangible. When it fails, people notice immediately.
But the MTSA’s explicit inclusion of critical IT systems alongside OT is a meaningful shift. There are IT systems quietly underpinning operations that, if compromised, could trigger consequences just as severe as an OT failure. Think enterprise resource management systems, emissions control platforms, environmental monitoring systems, and a host of others that don’t fit neatly into the “OT = critical” mental model.
The regulation defines the scope clearly:
Critical Information Technology (IT) or Operational Technology (OT) systems means any IT or OT system used by the vessel, facility, or Outer Continental Shelf (OCS) facility that, if compromised or exploited, could result in a transportation security incident (TSI), as determined by the Cybersecurity Officer (CySO) in the Cybersecurity Plan. Critical IT or OT systems include those business support services that, if compromised or exploited, could result in a TSI. This term includes systems whose ownership, operation, maintenance, or control is delegated wholly or in part to any other party.
That last sentence deserves its own beacon.
”...delegated wholly or in part to any other party.”
This is where regulation starts to go beyond your organization’s boundaries. If a third-party vendor owns, manages, maintains, or controls a system that your Cybersecurity Officer marks as critical, that system, and by extension, the vendor relationship, becomes subject to regulatory oversight. Historically, third-party and vendor risk management was often neglected by many security protocols. However, under MTSA’s framework, this approach is no longer acceptable. If their system is vital to your operations, their security posture now impacts your compliance as well. The asset inventory isn’t just a spreadsheet task; it’s the anchor for everything else and the first thing regulators will investigate.
Your asset inventory isn’t just a list of hardware. MTSA’s asset inventory expectations extend to software versions, firmware revisions, and configurations. These are the little details that determine whether a device is vulnerable. A PLC in your inventory running firmware from 2017 with a known CVE is not managed; it is just documented. If you use cloud-hosted platforms or services, the CySO may determine that they meet your threshold for criticality, in which case, they need to be on your asset inventory list. The server’s physical location is irrelevant.
MTSA cybersecurity requirements have phased implementation dates based on vessel and facility type. The asset inventory is the logical starting point because everything else, including network segmentation, the Cybersecurity Plan, and CIRP, depends on it being complete. Organizations that put off creating a complete asset inventory will delay every other downstream requirement as well.
Here’s an example from an engagement one of the authors experienced, illustrating its importance: During network traffic monitoring at a client’s site, Dragos consultants detected a workstation running an outdated operating system. That device was attempting to connect to an antivirus server belonging to the entity that owned the facility before any of the OT team’s subject-matter experts were employed. There was no anti-virus software supposed to be on that network. The domain associated with the antivirus was no longer owned by the previous owner and was now linked to a foreign gambling website. After 2.5 hours of searching and contacting plant managers, we located the affected system. Not only was the workstation connected to the gambling site, but it also lacked a password.
A proper asset inventory would have done four things:
- Pointed us directly to the asset in question
- Helped the customer identify End-of-Life Operating Systems
- Identified the anti-virus software and version
- Locate the system owner and understand the system’s necessity
Building an asset inventory follows the same crawl, walk, run progression introduced in the first post: crawl establishes awareness of what you have, walk turns that awareness into a documented, repeatable process, and run makes it continuous and automated. Here’s what that looks like applied to asset inventory specifically.
Crawl: get the baseline down
Start with what you can find fast, and document it consistently.
Hardware: full route survey of all OT assets; identify IP and non-IP devices; document physical locations; log make, model, and serial number.
Software: software inventory via WMI/SNMP; OS versions for Windows-based OT; firmware versions where accessible; installed application list.
Analytics and support: Dragos Platform passive discovery; SIEM log source inventory; firewall/NGFW rule review for asset references.
Deliverable: a single master spreadsheet (Excel or CSV) with every OT asset. This is the required export, regardless of phase.
Walk: make it structured and current
Hardware: map IP addressing to physical zones; document all remote access paths; assign criticality tiers; record vendor and support contacts.
Software: software baseline per device type; patch status against vendor-published releases; license and support status; end-of-life/end-of-support flagging.
Analytics and support: active queries against your CMDB; integrate asset data with vulnerability management; cross-reference against known CVEs.
Deliverable: documented RTOs/RPOs; a criticality-tiered asset register; a patch baseline per asset class.
Run: keep it continuous
Hardware: continuous passive asset discovery; change detection alerts; vendor portal integration; physical and logical inventory kept in sync.
Software: automated software delta alerts; continuous patch gap tracking; supply chain risk tracked per vendor; digital twins for critical assets.
Analytics and support: Dragos Platform asset intelligence; threat intel enrichment per asset; auto-generated board-level risk summaries.
Deliverable: an automated asset register; a real-time vulnerability gap report; a board-ready risk dashboard.
Tools You Likely Already Have
You don’t need to buy anything to start. Most of this data already exists somewhere in your environment.
Network (Crawl): ARP tables (arp -a) give you IP-to-MAC mappings for every device that has communicated on the subnet, a fast first pass at live devices. Router and switch CAM tables provide port-level device discovery, showing what’s physically connected to each switch port, including unmanaged devices. DHCP server logs capture hostname, IP, MAC, and lease history, often including OT devices that pull dynamic addresses. DNS records map hostnames to IPs, revealing named OT endpoints such as HMIs, historians, and engineering workstations.
IT/AD (Walk): Active Directory shows Windows-based OT devices, HMIs, historians, and engineering PCs, joined to the domain, including OS version and last-seen data. Your endpoint management platform holds software inventory, patch status, and hardware specs for every managed Windows endpoint in the OT network. Group Policy (GPO) logs reveal which OT machines are AD-joined and what software and configuration policies apply to them.
OT/ICS (Crawl and Walk): PLC programming software, vendor-supplied engineering tools, holds device lists, firmware versions, and I/O configuration per PLC. SCADA/HMI project files contain tag databases that reference every field device, with historian configs listing connected data sources by IP or name. DCS engineering tools have built-in asset browsers that export device lists with firmware and I/O module details. Engineering workstation (EWS) file shares name ladder logic and configuration files by device, so directory listings reveal asset names, types, and versions.
Maintenance (Walk): CMMS work order history references an asset tag on every work order; cross-reference against physical tags to find undocumented devices. Procurement and ERP records show purchase orders for OT hardware, revealing make, model, serial, and purchase date, often more accurate than a manual survey. Vendor service reports list device serial numbers, firmware versions updated, and parts replaced.
Security (Walk and Run): Firewall/NGFW rule bases expose source and destination IPs in OT zone rules, device addresses that aren’t visible from the IT side. SIEM log sources make any device sending syslog or Windows events discoverable by source IP, cross-referenced against known assets. Vulnerability scanners, run in IT-safe passive mode on IT-adjacent OT segments like the DMZ and data historians, but never as an active scan against the OT network itself.
An asset inventory is only as good as the day it was last updated. A few disciplines keep it accurate over time:
Change management: no new device is installed without a record being created; decommissions trigger an archive, not a delete; management of change (MOC) is linked directly to the asset register.
Governance: assign a named owner for the asset register; run quarterly spot-check audits covering 10-15% of assets; complete an annual full reconciliation walk-down.
Warranty and contract hygiene: flag out-of-warranty assets in critical roles; keep a centralized contract register instead of scattered email threads; document approved third-party repair vendors.
Data quality signals: track the percentage of assets with complete records (target 95%+); track the percentage of warranties and contracts with known expiry; track the age of the last verification per asset.
Dragos’s OT-CERT provides free resources for asset inventory, including a how-to and template.
An asset inventory tells you what’s on your network. It doesn’t tell you what those assets can reach, or what can reach them, and that’s exactly where the next layer of risk lives. The next post in this series covers network segmentation: how to structure your OT environment so a contained incident stays contained.
Related Resources
- Download the OT Asset Inventory Framework to see how to build your inventory in phases, with clear deliverables at every stage.
- Explore the full list of tools you likely already have and how to put them to work across every phase of your OT asset inventory.
Ready to build a more secure OT environment?
