TL;DR: CVSS-based vulnerability queues systematically mis-rank risk in IoT, OT, IoMT, and IT environments because severity scores ignore device context, exploitability, and network topology, according to Asimily. Its ATT&CK Analysis prioritises only vulnerabilities with a realistic path to exploitation, which shifts exposure management from abstract scoring to environment-specific decision-making.
At a glance
What this is: Asimily says CVSS alone is the wrong prioritisation model for connected devices because it does not account for exploitability in a specific environment.
Why it matters: This matters because vulnerability teams need to decide which exposed devices to isolate, remediate, or monitor first, and that choice affects operational continuity as much as security outcomes.
Context
Connected device vulnerability management fails when teams treat severity as a proxy for exploitability. IoT, OT, and IoMT environments depend on topology, firmware state, and communication paths, so a high-scoring CVE may be irrelevant while a lower-scoring issue creates immediate exposure. The core problem is prioritisation, not vulnerability discovery.
That makes this topic relevant to identity and access governance as well as exposure management. When devices, services, and operational networks cannot be reliably segmented or authenticated in the abstract, defenders need context-aware controls that reduce real attack paths rather than expand queues of theoretical issues.
Key questions
Q: Why does CVSS mis-rank vulnerabilities in IoT and OT environments?
A: CVSS measures severity in isolation, but connected-device risk depends on whether the vulnerable asset is reachable, which firmware version is running, and whether the network path enables exploitation. In OT and IoMT estates, that means a lower-scoring issue on an exposed, reachable device can be more urgent than a high-scoring issue on an isolated one. Prioritisation must be environment-specific.
Q: What breaks when vulnerability prioritisation ignores network topology?
A: The queue becomes misleading. Teams end up isolating or patching devices that are not realistically exploitable while leaving the genuine attack paths untouched. In connected environments, topology determines whether a vulnerability matters, so ignoring it turns exposure management into guesswork and weakens both remediation and segmentation decisions.
Q: How should security teams decide which connected devices to remediate first?
A: They should prioritise devices where exploitability is confirmed by the combination of asset profile, firmware version, exploit availability, and network reachability. That approach reduces the queue to a defensible short list and aligns limited remediation capacity with actual operational exposure instead of paper severity.
Q: How do security teams know if exploitation-based prioritisation is working?
A: Look for a shorter must-fix list, fewer exposed KEV items, faster closure of actively exploited CVEs, and clearer ownership for the devices or applications that stay open longest. Good prioritisation reduces the number of exceptions that survive month to month. If the queue still grows without changing which items get fixed first, the model is not working.
Technical breakdown
Why CVSS breaks down for connected devices
CVSS standardises severity, but it does not model whether the affected device is reachable, whether the firmware in your environment is actually vulnerable, or whether network conditions make exploitation realistic. That is why a 9.8 score can be a false alarm while a mid-range issue on a reachable SCADA-connected device is the real priority. In IoT and OT, topology is part of the vulnerability story, not an afterthought.
Practical implication: stop using CVSS as the last word on remediation order for connected devices.
How ATT&CK-style exploitability analysis changes prioritisation
Device-specific exploitability analysis combines asset attributes, attack requirements, exploit availability, and network reachability into one decision model. Instead of asking whether a CVE is severe in isolation, it asks whether an attacker has a practical path from a realistic entry point to successful exploitation. That produces a ranked queue based on evidence, not generic scoring, and it is especially useful where agents cannot be installed and scanners miss protocol details.
Practical implication: prioritise remediation only when reachability, firmware version, and exploit evidence align.
Why segmentation needs exploitability context
Segmentation is only as good as the policy decisions behind it. If teams do not know which devices are genuinely exploitable, they either over-isolate operations or leave real attack paths open. Context-aware prioritisation makes segmentation defensible because it identifies which assets need tighter isolation and which communication paths matter most. Without that context, network controls become guesswork.
Practical implication: use exploitability evidence to drive segmentation rules instead of isolating everything uniformly.
Threat narrative
Attacker objective: The attacker’s objective is to reach and abuse a real operational device path, not merely exploit a high-severity CVE in the abstract.
- Entry occurs through a vulnerability that may look severe on paper but is only exploitable when the device is reachable in the specific environment.
- Escalation depends on whether the attacker can reach the exact firmware version and network path the exploit requires, not on the CVSS score alone.
- Impact follows when the vulnerable device sits on a communication path that lets the attacker influence adjacent operational systems or monitoring flows.
Breaches seen in the wild
- Schneider Electric Jira breach 2024: Credentials linked to a Lumma infostealer infection gave Hellcat access to Schneider Electric's Jira; 40GB and 400,000 user rows claimed.
- Verkada camera breach 2021: Admin credentials on Verkada's exposed Jenkins support server let hackers into a support interface and customer cameras at 97 customers.
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
Severity-first vulnerability queues create exposure blindness: organisations that sort connected-device findings by CVSS alone are not managing operational risk, they are managing spreadsheet order. A severity score describes the vulnerability in isolation, while connected-device risk depends on reachability, firmware specificity, and network position. For IoT, OT, and IoMT, that difference is the difference between noise and exposure.
Exploitability, not volume, should be the governance unit: the central mistake in connected-device programmes is assuming that more findings equals better control. In practice, the team needs a smaller queue with documented rationale for each item, because boards, regulators, and insurers care about why an asset was prioritised, not how many CVEs were collected. The governance standard is explainable prioritisation.
Context-aware prioritisation is a segmentation problem as much as a vulnerability problem: the article’s real contribution is the idea that risk scoring must feed enforcement decisions, not sit beside them. When exploitability data is accurate, segmentation can target the paths that matter instead of applying blunt isolation. That is the difference between exposure management and operational disruption.
Connected-device governance needs a named concept: exploitability-aware exposure management: this is the practice of prioritising vulnerabilities only when device state, exploit availability, and network reachability line up. It replaces abstract severity with environment-specific evidence and gives security leaders a defensible way to allocate remediation effort. Practitioners should treat this as the control objective for IoT and OT vulnerability governance.
ATT&CK-aligned analysis strengthens the identity of the asset, not just the vulnerability: by tying a finding to device model, firmware, and communication path, the analysis creates a stronger control narrative for machine identity and segmented access. That matters because connected devices behave more like governed endpoints than generic hosts, and unmanaged reachability is often the real failure mode. Practitioners should align exposure workflows with asset identity and path control.
What this signals
Exploitability-aware exposure management: connected-device teams need a governance model that ranks vulnerabilities by realistic reachability, not by severity alone. That shift changes remediation from catalog management to attack-path management, which is the only way to make segmentation and patching decisions defensible in OT and IoMT estates.
For practitioners, the main signal is that vulnerability workflows must absorb asset identity and network context before they trigger action. A queue that cannot explain why an item matters will always overstate some risks and miss others, so the control objective is precision, not volume.
For practitioners
- Replace CVSS-only queues with exploitability-based triage Rank connected-device vulnerabilities by device model, firmware version, exploit availability, and network reachability, then suppress findings that lack a realistic attack path.
- Use topology data to drive remediation order Map which devices can actually be reached from likely entry points before assigning work, so the queue reflects operational exposure rather than generic severity.
- Tie segmentation rules to confirmed attack paths Write isolation policies around devices and flows that have demonstrated exploitability in your environment, not around every high-scoring CVE.
- Document the rationale for each priority asset Keep an audit trail showing why a device moved into the top tier, including exposure path, firmware evidence, and observed exploit relevance.
Key takeaways
- Connected-device vulnerability queues fail when severity is treated as a substitute for exploitability.
- The practical issue is not how many CVEs exist, but which ones have a realistic path to a specific device in a specific network.
- Security teams need prioritisation models that combine firmware, reachability, and exploit evidence before they commit remediation effort.
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, CIS Controls v8 and NIST CSF 2.0 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | The article centres on exploitability, attacker reach, and movement through connected-device paths. |
| Recommendation — Map exploitable device paths to credential access and lateral movement techniques, then prioritise the reachable assets first. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | The article is fundamentally about deciding which vulnerabilities deserve action in an operational queue. |
| Recommendation — Use continuous vulnerability management to rank findings by real exposure, not severity alone. | ||
| NIST CSF 2.0 | ID.RA-01 — Asset vulnerabilities are identified and documented | The analysis depends on identifying vulnerable assets in their actual operating context. |
| PR.DS-01 — Data-at-rest is protected | Connected-device exposure often affects systems that support sensitive operational data flows. | |
| Recommendation — Document asset vulnerabilities together with reachability and environment context before assigning remediation priority. Protect sensitive operational data flows when exposure decisions are made around connected devices. | ||
| ISO/IEC 27001:2022 | A.8.8 — Management of technical vulnerabilities | The article is a direct example of managing technical vulnerabilities with environment-specific context. |
| Recommendation — Apply technical vulnerability management to connected devices using exploitability and reachability evidence. | ||
Key terms
- Exploitability context: Exploitability context is the evidence used to decide whether a vulnerability matters in a specific environment. It includes reachability, code path exposure, compensating controls, and product-specific advisories, and it turns raw scan data into a decision that can be defended.
- Attack path: A sequence of identities, permissions, systems, and data stores that an attacker can traverse after obtaining trusted access. In practice, attack paths matter more than single accounts because they show how a low-risk identity can become a route to high-value exposure.
- Connected Device Exposure: Connected device exposure is the practical risk created when a device is reachable, vulnerable, and positioned in a network where misuse can affect operations. It is a context-dependent measure, which is why generic severity scores often mislead defenders.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is designed for security leaders who need to connect identity control to broader operational risk.
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