AnonymousSign in
Start from a neutral baseline and add what matters to you. Criteria are labeled by source — the platform baseline is architecture-neutral; buyer-contributed criteria are shown separately.
This evaluation is stored in your browser only. We cannot see it, and it is not tied to any account. Save it to a link or create an account to keep it across devices — you can export it at any time either way.
Signing up adds sharing with your team, sending this as an RFP to vendors, and private document sharing. Nothing above is taken away, and nothing here is sent anywhere until you choose to.
Passive-plus-active discovery with a stated accurate-identification percentage is stronger than a vendor claiming blanket visibility with no number; a large unknown-device bucket is a real red flag.
Firmware-version-specific CVE matching (not just device-model-level) plus a named customer outcome is stronger than a generic risk score with no remediation path.
Automated enforcement (quarantine/restrict) is materially stronger than advisory-only alerting that requires a manual network change.
Passive-only monitoring for OT is the safer, more mature answer; active probing of fragile OT devices is a real operational risk the vendor should acknowledge, not gloss over.
No buyer-contributed criteria yet
Verified buyers can suggest criteria (anonymized before pooling).
Many IoT security tools are detection-only; a vendor that can actually push firmware updates (or integrate with a system that can) is a materially stronger, rarer capability worth verifying with evidence.
A concrete time-to-visibility figure at a stated device-count scale is stronger evidence than a "fast deployment" claim with no numbers.
Named integrations plus a real MTTR figure from a customer is stronger evidence than a generic "integrates with your stack" claim.
Look for explicit decommission-detection logic (e.g., a grace period plus confirmation) rather than every offline device immediately flagged as an incident.
Same tension as other discovery-driven categories: successful IoT discovery inherently increases the counted device population — ask explicitly how pricing handles a large post-onboarding jump in discovered devices.
IoT forensics is genuinely harder than traditional endpoint forensics due to limited on-device logging — ask for a specific network-telemetry-based reconstruction capability and a real customer example.
IoT-specific regulation is a distinct and growing compliance requirement — ask for a specific, named regulatory mapping rather than a generic 'security best practices' claim.
Trend-over-time reporting is a distinct capability from a real-time dashboard — confirm this exists as a maintained, exportable report.
Look for genuine integration into a unified asset view; a standalone IoT dashboard disconnected from the broader asset-inventory picture creates real reconciliation burden.
A vendor should give an honest answer about whether smaller/remote sites get materially weaker coverage — a common real gap for large multi-site organizations.
BYO-IoT on guest networks is a distinct risk category from managed corporate IoT — a vendor should clarify how policy differs for each rather than treating all discovered devices identically.
A compromised building-automation device carries physical-safety and facility-disruption risk that generic IT-style CVSS scoring doesn't capture — ask for a specific answer on facility-impact-aware risk scoring for this device class.