How should security teams implement CAASM when their environment includes IoT, OT, and IoMT devices?

Security teams should start with a unified inventory built from the tools they already run, then add agentless discovery for devices that cannot host agents. The program needs correlation, deduplication, and classification rich enough to identify model, firmware, and exposure. Without that device layer, CAASM will look complete for IT but leave the most operationally sensitive assets outside control.

Build the CAASM program around the asset layer these environments actually have

CAASM works best here when the inventory model is built from the devices and management planes you already own, not from a hope that every endpoint can self-report. For IoT, OT, and IoMT, the first objective is to create one asset record per real device, then enrich it with owner, function, location, model, firmware, and network exposure so the inventory is useful for operations, not just compliance.

That is why Attack Surface Management Guide is relevant here: CAASM and attack surface work overlap once you need to reconcile discovered devices, exposed services, and forgotten assets into a single view. In mixed IT and cyber-physical estates, completeness is less important than trustworthy correlation, because duplicates and stale records are operational blind spots of their own.

For medical environments, the asset layer needs to be detailed enough to support patient safety decisions, not only security reporting. Medical Device Security Guide is a useful companion because IoMT records often need clinical context, lifecycle state, and vulnerability exposure before a team can judge whether a device can be touched, segmented, or replaced.

When teams treat all assets as interchangeable, they miss the practical difference between a workstation and a device that cannot be patched on a normal cadence, cannot host an agent, or must remain available continuously. The inventory model should therefore classify devices by operational constraints as well as technical properties, because that classification determines how discovery, control, and remediation will work later.

Use agentless discovery as the default for unmanaged and constrained devices

In these environments, agent-based collection may be appropriate for some gateways, servers, and management systems, but it cannot be the foundation of the program. Many IoT, OT, and IoMT assets are too constrained, too fragile, or too vendor-controlled to host agents, so security teams need agentless discovery through passive monitoring, existing management consoles, protocol-aware polling where safe, and integration from authoritative sources such as CMDBs, EDR, NAC, EHR-adjacent inventories, and industrial monitoring tools.

OT Asset Visibility Guide fits this problem directly because it focuses on passive and active discovery, protocol-aware inventory, and priority attributes. That matters in CAASM because the point is not merely to observe packets, but to extract enough context to distinguish one PLC, pump, sensor, or controller from another and decide what deserves attention first.

IoT Security Guide is equally useful because IoT fleets often depend on firmware posture, update status, and protocol-specific exposure, all of which must be visible before CAASM can say anything meaningful about risk. For hybrid estates, the best model is usually layered: collect from trusted sources first, then enrich with passive observation where direct probing would create operational risk.

For the industrial side, external references such as NIST SP 800-82 Rev 3 , OT Security Guide and CISA Industrial Control Systems are the right grounding points because they reflect the need for safe discovery, segmentation awareness, and operational context in ICS environments. CAASM should not introduce active scans or normal asset polling into segments where that would be disruptive.

Make correlation, deduplication, and exposure classification the deliverable

Once discovery is in place, the real value of CAASM comes from normalising overlapping records into one authoritative asset view. The program should correlate MAC addresses, hostnames, serial numbers, management IPs, certificates, and vendor identifiers, then deduplicate the records that describe the same physical device. Without that step, teams will overcount coverage, miss stale exposures, and lose the ability to answer simple questions like which device is still reachable from the wrong network.

Exposure classification needs to go beyond “present or absent.” For IoT, OT, and IoMT, the important distinctions are whether the device is internet exposed, reachable from user networks, dependent on default or shared credentials, running obsolete firmware, or embedded in a segment with weak monitoring. That is the difference between a neat inventory and a control system that can support action.

OT Security Platform Buyer’s Guide is relevant because many OT tools help with passive discovery and protocol context, but CAASM still has to consume and reconcile that data rather than treating a single tool as the whole answer. Likewise, Device and IoT Identity Guide is useful when the asset record must include device identity, attestation, and lifecycle trust so that the inventory can distinguish known devices from unmanaged ones.

The most common failure is to stop at “we can see the device” and treat visibility as control. In practice, CAASM only becomes useful when visibility is rich enough to drive ownership, segmentation, remediation priority, and exception handling for devices that cannot be remediated quickly.

Risk and Threat Considerations

Mixed IT and device estates create a control gap when the CAASM program assumes agent coverage, standard scanning, or fast patching that these environments cannot support. The result is a false sense of completeness, with the most sensitive devices least visible and often least changeable.

Failure mechanism: Discovery succeeds for IT assets but fails or degrades for constrained devices, so duplicates, stale records, and unclassified firmware exposure remain hidden behind apparently complete dashboards.

Impact: Teams can miss internet exposure, weak segmentation, unsupported firmware, or unmanaged clinical and industrial devices, which increases the chance of outage, misuse, or delayed containment during an incident.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	IA-9 — Identification and Authentication (Non-Organizational Users)	Covers device and system authentication across constrained non-user assets.
	CM-8 — System Component Inventory	Directly supports authoritative inventory and asset reconciliation across mixed environments.
	CA-7 — Continuous Monitoring	Supports ongoing visibility over asset exposure and posture changes.
Recommendation — Apply IA-9 to authenticate device and workload connections that CAASM inventories. Use CM-8 to maintain a complete, reconciled component inventory for OT, IoT, and IoMT assets. Use CA-7 to continuously monitor device exposure, firmware drift, and ownership changes.
CIS Controls v8	CIS-1 — Inventory and Control of Enterprise Assets	Matches the need to inventory and track all device assets across the estate.
	CIS-2 — Inventory and Control of Software Assets	Supports firmware and software visibility on managed devices and controllers.
	CIS-12 — Network Infrastructure Management	Supports segmentation and management of constrained device networks and paths.
Recommendation — Implement CIS-1 to discover, inventory, and track all device assets in scope. Apply CIS-2 to track firmware and software components that affect device exposure. Use CIS-12 to map and control the network paths that expose device segments.

Practitioner Guidance

What to prioritise: Start with a source-of-truth model that defines which system is authoritative for each device attribute, then decide where passive discovery, protocol-aware collection, or vendor integration is safest. If a device cannot tolerate intrusive checks, treat that constraint as a design requirement, not a temporary exception.

What to verify: Confirm that every device class has a usable enrichment path for model, firmware, ownership, and exposure. If the CAASM output cannot tell you whether a device is known, reachable, and supportable, the inventory is still too thin for operational use.

Practitioner takeaway: In IoT, OT, and IoMT environments, CAASM succeeds when it behaves like an evidence fusion problem, not a scanning project: visibility, correlation, and device context matter more than raw coverage.