Most organisations cannot say how many IoT and OT devices are on their networks, let alone which ones are vulnerable or talking to places they should not. Cameras, building controllers, medical devices, printers and industrial sensors rarely accept endpoint agents, so the usual tools miss them. Two kinds of purchase fix this: an IoT and OT visibility and security platform that discovers, classifies and helps contain devices, and better devices bought on better terms from their manufacturers. This vendor-neutral buyer's guide covers both. It sets out requirements, capability areas, an evaluation table, questions for platform vendors and for device manufacturers (including the UK PSTI regime, the EU Cyber Resilience Act and the US Cyber Trust Mark), red flags and a proof of concept plan. It does not rank vendors.
Key takeaways
- Passive discovery comes first. The platform must identify devices from network traffic without disrupting fragile equipment, then use safe active queries only where you allow them.
- Classification accuracy is the core metric. Make, model, firmware version and function drive every later decision, so measure accuracy against your own known inventory.
- Visibility must lead to enforcement. Look for policy that your existing switches, firewalls and NAC can enforce, not a dashboard that only describes risk.
- Vulnerability context beats CVE counts. Prioritise by exploitation status, exposure and device function rather than raw scores.
- Buy better devices too. Ask every device manufacturer for unique credentials, a vulnerability disclosure policy and a published security support period, which UK law already requires for consumer connectable products.
Define requirements
- Scope: which device families matter (enterprise IoT, building management, medical, industrial OT) and across how many sites?
- Network reality: where can you take traffic (SPAN ports, network TAPs, switch telemetry, wireless controllers, firewalls), and where can you not?
- Safety constraints: are there devices that must never be actively scanned? OT and medical environments usually say yes.
- Enforcement points: which NAC, 802.1X, switch ACL, firewall or SD-WAN controls do you already own?
- Integrations: CMDB, SIEM, SOAR, vulnerability management and ticketing systems the platform must feed.
- Deployment model: on-premises sensors, cloud analytics or air-gapped operation, and data residency rules.
- Regulatory drivers: IEC 62443 for industrial sites, NIST SP 800-213 for US federal buyers, sector rules for healthcare, and the EU Cyber Resilience Act for products you buy or sell in the EU.
The IoT Security Guide and the Device and IoT Identity Guide cover the underlying practices.
Capability areas
| Area | What to look for |
|---|---|
| Passive discovery | Deep packet inspection of IT and industrial protocols from SPAN or TAP feeds; identification without sending traffic to devices; sensor sizing for your busiest links |
| Safe active query | Optional, rate-limited queries using the device's own protocol, with per-subnet controls and an off switch for sensitive zones |
| Asset inventory and classification | Make, model, serial, firmware, function, location and owner; confidence score per attribute; bidirectional CMDB sync |
| Communication mapping | Baseline of who talks to whom, on which ports and protocols; detection of new external destinations |
| Segmentation policy and enforcement | Policy suggested from observed flows, simulated before enforcement, then pushed to NAC, switches or firewalls; support for IETF RFC 8520 Manufacturer Usage Description (MUD) where devices provide it |
| Vulnerability context | CVE matching from firmware versions, exploitation status (for example the CISA Known Exploited Vulnerabilities catalog), default credential detection, end-of-support status, compensating controls |
| Threat detection | Anomaly and signature detection for device behaviour and industrial commands; alerts mapped to MITRE ATT&CK for ICS |
| Integration and response | SIEM, SOAR, ticketing and vulnerability management APIs; quarantine actions through existing enforcement points |
| Platform security | Hardened sensors, SSO and MFA for consoles, role-based access, audit logs, scoped and rotated API tokens |
For identity and certificate management on the devices themselves, see the Identity for IoT Fleets Guide. For control system environments, compare with the OT Security Platform Buyer's Guide.
Evaluation criteria
| Criterion | How to test it | Good result |
|---|---|---|
| Discovery coverage | Compare platform inventory with a known device list for one site | Finds known devices and surfaces unknown ones, with no device disruption |
| Classification accuracy | Sample 50 devices and check make, model and firmware by hand | High accuracy on firmware version, not just device type |
| Segmentation workflow | Generate policy for one device group, simulate, then enforce | Simulation shows what would break; enforcement uses your existing controls |
| Vulnerability prioritisation | Review the top 20 findings | Ranked by exploitation and exposure, with compensating controls when patching is impossible |
| Integration depth | Push assets to CMDB and alerts to SIEM; open a ticket automatically | Documented APIs, field mapping and two-way sync |
| Operational load | Count alerts per day and tuning effort over the trial | Alert volume your team can handle after tuning |
| Platform security | Review architecture, access model and update process | SSO, MFA, least privilege roles, signed sensor updates |
Questions to ask vendors
Visibility and security platform vendors
- Show discovery of a device type we choose, from passive traffic only, and explain how classification reached each attribute.
- Which industrial, medical and building protocols do you parse in depth, and which only by port?
- Exactly what traffic does active query send, and how do we exclude subnets or device types?
- Show a segmentation policy simulated, then enforced through our own NAC or firewall, and how it is rolled back.
- How do you identify firmware versions, and how fast do new vulnerabilities and exploitation status reach the platform?
- Can the platform run fully on-premises or air-gapped, and what data leaves our network otherwise?
- How are console accounts, API tokens and sensor credentials protected, and can tokens be scoped and rotated?
Device manufacturers
- Does every device ship with a unique password or require one to be set? ETSI EN 303 645 provision 5.1-1 and the UK PSTI regime (in effect since 29 April 2024) both rule out universal default passwords.
- Where is your vulnerability disclosure policy, and what are your timescales for acknowledging reports and giving status updates?
- What is the defined security support period for this model, with an end date? PSTI requires it to be published for consumer connectable products.
- How will you meet EU Cyber Resilience Act obligations: reporting of actively exploited vulnerabilities from 11 September 2026 and full requirements from 11 December 2027? Is the product classed as important or critical, and what conformity assessment will it have?
- Does the device have a unique cryptographic identity, signed firmware and a secure update and rollback mechanism, in line with the NIST IR 8259A core baseline?
- Will you provide a software bill of materials, and does the device publish a MUD file?
- Do you hold IEC 62443-4-1 or 4-2 certification for industrial products?
- For US consumer products, are you pursuing the FCC Cyber Trust Mark? The programme was still being set up in 2026: its first Lead Administrator withdrew in December 2025 and the FCC selected a replacement in April 2026, so ask for current status rather than assume a label exists.
Red flags
- Discovery that depends on active scanning, or that cannot be fully disabled for sensitive zones.
- Classification that reports device type but not firmware version.
- Segmentation features that recommend policy but cannot simulate or enforce it through your controls.
- Vulnerability lists sorted only by CVSS, with no exploitation or exposure context.
- Platform consoles without SSO and MFA, or long-lived API tokens that cannot be scoped.
- Device manufacturers with no published support period or vulnerability disclosure policy.
- Cloud-managed devices whose vendor support or administrator access is not controlled; the Verkada camera breach showed how exposed administrator credentials at a vendor can open customer cameras.
Proof of concept
- Pick one representative site with IT, IoT and, where relevant, OT or medical segments, and agree success criteria in advance.
- Deploy sensors on SPAN or TAP feeds in passive mode only for the first two weeks and compare the inventory with your known list.
- Hand-check classification for a 50-device sample, including firmware versions.
- Enable safe active query on one non-critical subnet and confirm no device impact.
- Generate, simulate and enforce a segmentation policy for one device group, then test rollback.
- Integrate with your SIEM, CMDB and ticketing, and measure alert volume and tuning effort.
- Score each vendor against the evaluation table and the device manufacturer answers you collected.
How NHI Mgmt Group can help
We provide independent requirements and evaluation support for device identity, IoT and OT security programmes. Browse vendors in our products directory or contact us.
Related NHI Mgmt Group resources: IoT Security Guide · OT Asset Visibility Guide · Medical Device Security Guide · Network Segmentation Guide