MTSA device security: what happens when no one owns the asset?

TL;DR: MTSA device security fails in practice when owners cannot produce an accurate inventory, approved software list, or network map, as illustrated by fifteen forgotten Raspberry Pis on a flat network and the wider drift between paper controls and live OT environments, according to Dragos research. The governance gap is not visibility alone, but enforcement of asset ownership, change tracking, and segmentation discipline across both critical IT and OT.

Editorial analysis by NHI Mgmt Group, based on content published by Dragos: “No Devices Adrift: MTSA’s Device Security Requirement”.

Key questions

Q: What breaks when device security is only documented on paper?

A: Paper-only device security breaks because inventory, code execution control, and network mapping drift away from the live environment.

Q: Why do unowned devices create compliance and operational risk?

A: Unowned devices create risk because nothing forces their review, retirement, or reclassification when business use ends.

Q: What are the signs that device security controls are failing in OT environments?

A: Common warning signs include devices no one can explain, network paths that are missing from the diagram, inventory lists that have not changed in years, and allowlisting that exists only in audit mode.

Practitioner guidance

• Build an asset-class approved list Define the approved hardware, firmware, and software baseline by asset class, then reconcile it against live inventory so undocumented variants are flagged immediately.
• Separate critical IT from generic IT oversight Include domain controllers, jump servers, historians, and engineering workstations in the same device governance scope as plant-floor systems.
• Run code controls in audit mode before enforcement Use native OS allowlisting and script logging to see what would execute before turning enforcement on, then graduate only the systems that need it most.

Bottom line: MTSA device security is not just an inventory exercise. It is a control over what devices are allowed to exist, run code, and talk to the network.

Explore further

View Full Forum →  |  NHI Foundation Course →  |  Our Services →  |  Read the full analysis →