MTSA asset inventory now covers critical IT, OT and vendors

At a glance

What this is: Dragos argues that MTSA asset inventory is the foundational cybersecurity requirement for maritime environments because it now spans critical IT, OT, software, firmware, cloud services and vendor-managed systems.

Why it matters: For IAM and NHI practitioners, the article is a reminder that inventory is not just for devices and software, because delegated vendor control and system ownership also shape governance, accountability and downstream access decisions.

Context

MTSA’s asset inventory mandate is really a governance problem: if you cannot name the systems in scope, you cannot protect them, segment them, or prove they are controlled. In maritime environments, that inventory now extends beyond obvious OT to critical IT, software versions, firmware revisions, cloud-hosted services and vendor-managed assets.

The control also changes the boundary of responsibility. When a system is owned, operated, maintained or controlled by a third party, the organisation still needs to understand its role in the cyber risk picture, because delegated control does not remove operational impact.

Key questions

Q: What breaks when OT asset inventory is incomplete?

A: Incomplete OT asset inventory breaks segmentation, vulnerability prioritisation, and incident response because security teams cannot reliably tell which devices exist, where they are, or what they connect to. In practice, that means legacy systems, vendor access paths, and unmanaged devices can remain outside policy boundaries and become lateral movement routes.

Q: Why does vendor-managed equipment still need to be in the inventory?

A: Vendor-managed equipment still needs to be inventoried because delegated ownership does not remove operational impact. If a supplier controls part of a system that can affect a transportation security incident, the organisation still needs visibility into support status, access paths and criticality. Otherwise, the compliance boundary exists on paper but not in operational reality.

Q: How can security and IT teams tell whether an asset platform is actually working?

A: Look for evidence that ownership, usage, renewal, and retirement data stay synchronized without constant manual correction. If the platform produces reports but cannot support timely action, it is documenting the problem rather than controlling it.

Q: What is the difference between discovering assets and governing them?

A: Discovering assets tells you what is present, while governing them tells you who owns them, what they do, what version they run and whether they remain supportable. Discovery is the starting point, but governance adds criticality, lifecycle status and change control. In regulated environments, that second layer is what turns visibility into defensible security.

Technical breakdown

Why inventory scope now includes critical IT and OT

MTSA treats inventory as more than an equipment list. The relevant unit is any network-connected system that could contribute to a transportation security incident if compromised, including business support systems, software and firmware states, and systems hosted outside the vessel or facility. That broadens the control from asset counting to risk scoping, because the same platform can be low value in one context and critical in another. The practical challenge is that criticality is determined by operational consequence, not by technology label alone. A complete inventory therefore has to capture ownership, function, versioning, and dependency context, not just device presence. See the NHI Lifecycle Management Guide.

Practical implication: Build the inventory around criticality and dependency, not around a hardware spreadsheet alone.

How third-party control changes the inventory model

The regulation explicitly includes systems whose ownership, operation, maintenance or control is delegated in whole or in part to another party. That means a vendor-managed system still sits inside the organisation’s compliance boundary if the Cybersecurity Officer determines it is critical. The governance issue is not just supplier risk, but shared control over assets that may be partially invisible to internal teams. Inventory therefore has to connect asset identity to service ownership, support responsibility, remote access paths and change authority. Without that, organisations can document a system while still failing to control it.

Practical implication: Record vendor-managed systems as in-scope assets with named ownership, support and access paths.

What changes when software, firmware and configuration are treated as inventory data

MTSA’s inventory expectations cover the conditions that make a device vulnerable, not only the device itself. A PLC with outdated firmware, a workstation with an unknown OS build, or a cloud platform running an unmanaged configuration can all create exposure even when the asset is already listed. That is why inventory has to include software versions, firmware revisions and configuration context. In practice, this moves the programme from discovery to lifecycle control. The real question becomes whether the organisation can answer what is deployed, where it runs, what version it is on, and whether it is still supportable.

Practical implication: Track version state and support status for every critical asset, not just presence in the register.

Threat narrative

Attacker objective: The objective is to exploit invisible or poorly governed assets to reach operational systems that should have been controlled, segmented or excluded from trust.

1. Entry occurs through an untracked or stale asset that remains connected to the environment without current ownership or configuration visibility.
2. Escalation follows when the hidden asset has outdated software, missing authentication or unmanaged access paths that broaden the blast radius.
3. Impact emerges when the asset can reach systems that should have been segmented or governed, creating a transport security incident path.

Breaches seen in the wild

• Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.
• CISA Private-CISA GitHub leak 2026: A CISA contractor's public GitHub repo exposed AWS GovCloud admin keys, Artifactory credentials and plaintext passwords for six months.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Asset inventory has become an access-control problem, not a documentation exercise. Once inventory determines what is in scope, it also shapes what is trusted, segmented and monitored. In maritime environments, missing or stale inventory creates the same governance weakness that missing identity inventory creates in IAM: you cannot govern what you have not positively identified. The practitioner conclusion is that inventory quality now directly affects control quality.

The new risk is inventory drift across ownership boundaries. MTSA’s language on delegated control shows that third-party management does not move the asset out of scope. That creates a governance gap when internal teams rely on vendor summaries, contract records or partial CMDB entries instead of reconciling actual system state. The practitioner conclusion is to treat supplier-controlled assets as governed assets, not external exceptions.

Critical IT must be treated like a privileged dependency layer. The article’s scope shift matters because critical IT systems can be just as consequential as OT when they support operations, monitoring or emissions control. This is where asset lifecycle management becomes relevant: the asset record has to follow provisioning, change, support and offboarding, not just initial discovery. The practitioner conclusion is to link criticality decisions to lifecycle governance.

Visibility gaps are now a compliance risk amplifier. A weak inventory slows every downstream activity, from segmentation to cybersecurity planning to incident response. The regulation is effectively saying that governance failures begin before the first technical control is tuned, because the organisation cannot apply the right safeguards to an unknown estate. The practitioner conclusion is to measure inventory completeness as a control outcome, not as an administrative task.

From our research library:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Read next: Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs

What this signals

Visibility debt: In regulated environments, the real problem is not asset sprawl alone, but the gap between what exists and what the organisation can prove it knows about. That gap becomes more dangerous when third-party control, cloud hosting and firmware drift sit outside the same register, because governance decisions then rely on assumptions instead of evidence.

For maritime operators, the inventory has to be a living control, not a spreadsheet export. The article’s emphasis on quarterly checks, annual reconciliation and change-linked updates reflects a broader truth: the farther an asset drifts from its recorded state, the more likely it is to become a blind spot in both compliance and incident response.

For practitioners

• Map criticality before technical controls Classify each network-connected system by whether compromise could create a transportation security incident, then separate critical IT from supporting infrastructure and non-critical assets.
• Build a single master asset register Use one authoritative register for hardware, software versions, firmware revisions, physical location, support status and owner, and keep it aligned to change and decommission events.
• Record third-party systems as in-scope assets Include vendor-managed systems when the vendor owns, operates, maintains or controls part of the service, and document support contacts, access paths and decision authority.
• Verify inventory quality continuously Run quarterly spot checks against 10% to 15% of assets, flag records older than the last verification, and tie management of change to automatic register updates.
• Track version and support exposure Add software baselines, firmware state, patch status and end-of-life or end-of-support flags so the register shows which assets are present and which are still defensible.

Key takeaways

• MTSA turns asset inventory into a prerequisite for every downstream control, which is why incomplete scope now creates both security and compliance exposure.
• The article extends inventory beyond hardware to critical IT, OT, software, firmware, cloud services and third-party-managed systems.
• Teams need a living register with ownership, version state and verification cadence, because static documentation will not satisfy the regulation or the risk it describes.

Related NHI Mgmt Group resources: NHI Lifecycle Management Guide · Ultimate Guide to NHIs: Key Challenges and Risks · OT Asset Visibility Guide

Key terms

• Asset Inventory: An asset inventory is a managed record of the systems, identities, and resources an organisation needs to govern. For NHI security, it becomes the starting point for ownership, exposure analysis, and lifecycle action because you cannot rotate or offboard what you cannot reliably see.
• Criticality: A measure of how much other parts of the environment depend on a component. A highly connected system is not always critical, so criticality helps teams separate visibility or popularity from true operational importance when assessing severity and recovery priorities.
• Configuration Drift: Configuration drift is the gradual divergence between a system's intended secure state and the settings it actually runs with over time. In SaaS, drift often appears when admins change sharing, logging, or access controls under pressure and never return to validate the result.
• Delegated Control: Delegated control is the assignment of limited administrative or approval authority to the teams closest to the system or process. It improves responsiveness while still preserving governance boundaries. In SAP security, it helps compliance and IT teams act on policy without centralising every decision in a bottleneck.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, identity lifecycle and secrets management. It helps practitioners connect identity discipline to the broader control work that complex environments require.