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.
At a glance
What this is: This is a practitioner analysis of MTSA device security requirements and the finding that paper controls collapse when organisations cannot track what is actually installed, connected, and approved.
Why it matters: It matters because identity and access governance for critical infrastructure starts with knowing which devices exist, who owns them, and whether they still belong in the environment.
Context
MTSA device security is fundamentally a governance problem disguised as an inventory exercise. The control only works when organisations can prove what assets are installed, what code is allowed to run, what is connected to the network, and how those devices are configured in practice, not just on paper.
The article shows how quickly that model breaks down when forgotten systems remain powered on, undocumented, and unowned. In critical environments, the identity angle is real: devices, service accounts, and administrative access paths must be governed as a connected control set, or inventory becomes theatre rather than assurance.
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. Once ownership is unclear, forgotten devices stay powered on, unapproved paths remain open, and compliance evidence stops reflecting operational reality. The result is not just weaker security but false assurance when the environment changes faster than the control evidence.
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. They continue to consume trust, sit on live networks, and escape change control until an assessor or incident response team finds them. In regulated environments, that gap turns asset drift into audit failure and potential operational exposure.
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. When critical IT systems are excluded from scope or approved lists are not reconciled with live discovery, the control is already failing.
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.
Technical breakdown
Approved hardware and software baselines are asset-class controls, not one-off lists
An approved hardware, firmware, and software list is only useful when it is built at the asset-class level and continuously reconciled against what is actually deployed. In mixed OT and IT environments, per-device enumeration becomes unmanageable because firmware revisions, model drift, and legacy exceptions multiply faster than manual review can keep up. The technical control is therefore baseline governance, not static documentation. The list has to answer whether a device family is allowed, whether an installed package is expected, and whether an unapproved revision has appeared since the last review.
Practical implication: Treat approved lists as living baselines and diff them against discovery outputs on a schedule.
Executable code controls depend on enforcement and telemetry together
Executable code security in this context means native OS allowlisting, script controls, and logging that prove which code was permitted to run. Audit mode is the starting point because it reveals what would break before enforcement is turned on, but the actual control only exists once enforcement and log review are linked. That matters on both engineering workstations and critical IT systems such as domain controllers and jump servers, because the rule does not distinguish between them. Without code-integrity logs, organisations only discover unauthorized execution after the fact, when the system is already part of the incident timeline.
Practical implication: Enable allowlisting in audit first, then move to enforcement where code can reach critical systems.
Network maps fail when configuration drift is treated as normal
A network map is not a diagram from commissioning, it is a statement about current allowed paths. In maritime and OT environments, segmentation drifts as firewall exceptions accumulate, switch rules change, and undocumented cross-zone connectivity appears over time. The real control is configuration documentation that stays aligned to running state, because a stale map cannot prove whether OT devices are isolated from DMZ or corporate zones. This is where visibility and governance converge: if the environment changes faster than the diagram, the diagram stops being evidence.
Practical implication: Automate config diffs and compare live paths against the approved network map, not the original design.
Threat narrative
Attacker objective: The objective is to exploit unmanaged device presence and flat connectivity to create a durable foothold in an environment that assumes its assets are known and governed.
- Entry begins with an undocumented device or exposed management path that remains on the network long after its business purpose has ended.
- Credential or configuration abuse follows when the device is still reachable, still trusted, and not covered by current approval or review processes.
- Escalation occurs as that unmanaged device sits on a flat or weakly segmented network where it can be used to reach other critical systems.
- Impact is loss of compliance, loss of assurance, and potentially expanded operational exposure across the OT and critical IT estate.
Breaches seen in the wild
- 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
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.
Unowned infrastructure is a governance gap, not just an asset management gap. Fifteen forgotten Raspberry Pis are not interesting because they are rare, but because they reveal how easily permanent blind spots form when asset ownership is unclear. In identity terms, this is the same problem as a privileged account with no accountable owner: when no one is responsible for decommissioning, risk persists by default. The practical conclusion is that ownership metadata matters as much as technical discovery.
MTSA device security exposes the difference between documentation and assurance. A compliant-looking list can exist while the live network drifts away from it, which means the control objective is continuous reconciliation, not paperwork submission. That is the named concept here: visibility-to-assurance gap, the distance between what an organisation says is installed and what the environment actually permits. Practitioners should close that gap with evidence-backed baseline checks, not annual attestations.
Critical IT must be governed with the same discipline as OT because adversaries do not respect organisational silos. The article is explicit that domain controllers, jump servers, and historians belong in scope alongside PLCs. In broader identity and access governance, that is a reminder that privileged paths into operational environments are part of the attack surface, even when the system being managed is not itself a human identity system. Teams should align asset governance and access governance instead of treating them as separate programmes.
MTSA-style device security is only effective when change management and detection are linked. The strongest operational pattern in the article is scheduled discovery, diff-based review, and same-day alerting for unapproved changes. That is the model security teams should prefer wherever device drift or machine identity sprawl can expand silently. Practitioners should move from periodic audits to continuous evidence collection and exception handling.
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: NHI Lifecycle Management Guide
What this signals
Visibility-to-assurance gap: MTSA device security shows that compliance fails when discovery, approval, and retirement live in different processes. A device can be physically present, technically reachable, and still absent from the governance record, which is why continuous reconciliation matters more than a one-time inventory.
The same pattern appears across identity governance whenever teams confuse existence with control. When ownership and review are weak, operational environments accumulate trusted objects that nobody can explain, and that is the point at which security evidence becomes stale rather than useful.
For practitioners
- 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.
- Automate network-map reconciliation Diff firewall, router, and switch configurations against the current network map so cross-zone paths are flagged when they appear, not at the next assessment.
- Assign retirement ownership for forgotten devices Give a named owner responsibility for reviewing devices that no longer have a business purpose, because unowned assets persist by default.
Key takeaways
- 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.
- The article shows that forgotten assets and stale network maps are common enough to create real compliance exposure, especially when critical IT is ignored alongside OT.
- Continuous reconciliation between approved baselines, live discovery, and configuration change is the practical control that turns device security from paperwork into assurance.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack surface, NIST CSF 2.0 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.AM-01 — Physical devices and systems are inventoried | The article centres on knowing what devices exist and where they sit in the environment. |
| PR.AA-05 — Access Permissions, Entitlements and Authorizations | Device security and account security are linked to who can reach critical systems and from where. | |
| Recommendation — Maintain a continuously reconciled inventory of devices and systems so unapproved assets are visible before assessment. Restrict access paths to critical devices and review entitlements whenever the asset baseline changes. | ||
| CIS Controls v8 | CIS-1 — Inventory and Control of Enterprise Assets | The post is fundamentally about finding and governing assets that should not be adrift. |
| CIS-4 — Secure Configuration of Enterprise Assets and Software | Approved software baselines and code-integrity controls are central to the requirement. | |
| Recommendation — Use asset discovery and approval workflows to remove unknown or unowned devices from active service. Enforce secure configuration baselines and log deviations from approved device software states. | ||
| ISO/IEC 27001:2022 | A.8.9 — Configuration management | The article depends on current configuration evidence, not static documentation. |
| A.8.16 — Monitoring activities | Continuous reconciliation and alerting are required to detect drift and unapproved changes. | |
| Recommendation — Keep device configurations under change control and verify that documentation matches the running state. Monitor device changes and cross-zone connections so drift is detected before the next review cycle. | ||
| MITRE ATT&CK | TA0007;TA0008;TA0040 — Discovery; Lateral Movement; Impact | Unmanaged devices expand the paths adversaries can discover, traverse, and use to affect operations. |
| Recommendation — Map unmanaged device exposure to discovery, lateral movement, and impact scenarios in your threat models. | ||
Key terms
- Approved Asset Baseline: An approved asset baseline is the controlled list of hardware, firmware, and software versions that are allowed in an environment. It turns asset management into a governance control by defining what belongs, what does not, and what must be removed or reviewed when drift appears.
- 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.
- Execution Allowlist: An execution allowlist is a control that only permits approved commands or actions to run. The weakness is that shells and runtimes can transform a command after validation, so a string that looks safe may still do unsafe things. That is why runtime-aware policy matters in agent environments.
- Visibility-to-Assurance Gap: The visibility-to-assurance gap is the distance between seeing assets in an environment and being able to prove they are governed correctly. It appears when inventory, ownership, configuration, and access review sit in separate processes and the organisation cannot turn discovery into reliable control evidence.
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 security practitioners connect asset, identity, and access controls into one operating model.
Published by the NHIMG editorial team on October 16, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org