Topic starter
23/10/2026 12:46 am
TL;DR: Segmentation stalls when vulnerability findings are not ranked by real exploitability and network context, according to Asimily. Policy works better when isolation decisions follow what is reachable, exploitable, and worth containing.
Editorial analysis by NHI Mgmt Group, based on content published by Asimily: “Why Segmentation Stalls Without Risk-Based Prioritization”.
By the numbers:
- 87% describe their current approach as still needing improvement, according to Asimily.
Key questions
Q: Why do severity scores mislead segmentation teams?
A: Severity scores describe a flaw in isolation, not the device, topology, or reachable path around it.
Q: How do security teams know if segmentation is actually reducing risk?
A: Teams know segmentation is working when unnecessary workload communications disappear, exception volume falls, and policy changes are validated continuously rather than assumed.
Q: What breaks when segmentation is built from unprioritized vulnerability lists?
A: Segmentation breaks when teams try to isolate everything or isolate the wrong things.
Practitioner guidance
- Build a continuous risk baseline Maintain an always-current inventory of connected IoT, OT, and IoMT assets, and tie each device to function, ownership, and observed communications before making isolation decisions.
- Prioritise by exploitability and reachability Rank vulnerabilities by whether an attacker can actually reach and use them in the current topology, then isolate the smallest set of assets that reduces the most risk.
- Use segmentation simulation before enforcement Test proposed policy changes against real traffic and device-to-device paths so the team can see whether a rule blocks dangerous exposure or breaks essential operations.
Bottom line: Segmentation fails when teams treat every vulnerability as equally important instead of ranking what is actually reachable and exploitable.
Glossary terms: Risk Segmentation, Blast Radius, Lateral Movement, Reachability analysis
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 6 days ago by NHI Mgmt Group
23/10/2026 9:49 am
Risk-based segmentation fails when teams confuse vulnerability volume with exposure. A long scan output is not a segmentation strategy, because the control question is not which flaws exist but which ones can actually be reached and used. That distinction is central to modern device-heavy environments, where operational consequences come from pathing, adjacency, and asset criticality. Practitioners should treat prioritisation as the governance layer that turns inventory into enforceable isolation.
A few things that frame the scale:
- The average time to mitigate a leaked secret is 36 hours, highlighting the operational burden of manual remediation processes, according to the 2024 State of Secrets Management Survey.
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to the State of Secrets in AppSec.
A question worth separating out:
Q: What should teams do when vulnerability ranking and segmentation enforcement are handled separately?
A: They should merge the prioritisation and policy workflows so the same risk model drives both isolation decisions and enforcement rules. When those functions are split, handoffs degrade, exceptions multiply, and the final policy often reflects team boundaries rather than actual exposure.
👉 Read our full editorial: Risk-based prioritization is the missing layer for segmentation
This post was modified 6 days ago by NHI Mgmt Group