Topic starter
23/10/2026 12:46 am
TL;DR: Fifteen forgotten Raspberry Pis on a flat network show MTSA device security breaks down when asset ownership, approved software, and network maps fall out of sync, according to Dragos. Device security only becomes real when baselines are reconciled with what is actually installed and connected.
Editorial analysis by NHI Mgmt Group, based on content published by Dragos: “No Devices Adrift: MTSA’s Device Security Requirement”.
Key questions
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.
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.
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.
Glossary terms: Approved Asset Baseline, Configuration Drift, Execution Allowlist, Visibility-to-Assurance Gap
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 6 days ago by NHI Mgmt Group
23/10/2026 9:49 am
Device security is really lifecycle governance for equipment, not a checklist of installed parts. The article shows that a control written for maritime compliance still collapses if nobody owns discovery, approval, review, and retirement as a single process. That is the same failure pattern NHIMG sees in identity programmes when service accounts or devices are tracked only at creation time and never retired with the environment. Practitioners should treat device inventory as a lifecycle control, not a one-time survey.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: How should teams govern device security alongside segmentation and account controls?
A: Treat device security, segmentation, and account security as one governance chain. Devices need approved baselines, trusted network placement, and controlled access paths, because an isolated inventory does not stop misuse if credentials or network routes remain open. The control set only works when discovery, access, and configuration review are aligned.
👉 Read our full editorial: MTSA device security exposes the cost of unknown assets
This post was modified 6 days ago by NHI Mgmt Group