Topic starter
18/08/2026 2:45 pm
TL;DR: Perfect patching is unrealistic because vulnerability remediation must be balanced with mitigation, especially when 48,000 CVEs were published in 2025 and 95 to 97 percent of vulnerabilities are never exploited in the wild, according to ArmorCode. Risk-based exposure management now depends on asset criticality, exploitability, and temporary controls that do not become permanent debt.
Editorial analysis by NHI Mgmt Group, based on content published by ArmorCode: “Vulnerability Remediation vs. Mitigation: Managing Risk in Modern Environments”.
By the numbers:
- 95 to 97 percent of reported vulnerabilities are never exploited in the wild, according to ArmorCode.
Key questions
Q: When should teams remediate a vulnerability instead of mitigating it first?
A: Teams should remediate first when the asset is business-critical, the patch is available, and the operational impact is manageable.
Q: Why does mitigation create risk if teams leave it in place too long?
A: Mitigation creates risk when it becomes a substitute for remediation rather than a temporary shield.
Q: What are the signs that a mitigation-first strategy is failing?
A: Warning signs include an expanding backlog of mitigated findings, missing review dates, unclear ownership, and controls that are still active long after the original business constraint has passed.
Practitioner guidance
- Define remediation and mitigation as separate workflows Route permanent fixes to patch, reconfiguration, or component removal owners, and route compensating controls to the teams that can implement and monitor shields such as WAF, segmentation, or EDR.
- Set expiry dates for every mitigation Require a review trigger, owner, and target remediation date for each temporary control so it does not become hidden technical debt.
- Prioritise by exploitability and asset criticality Use exposure context, reachability, and business value to decide whether a finding needs immediate remediation or a temporary control first.
Bottom line: Remediation and mitigation are different control choices, not interchangeable labels for the same response.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
18/08/2026 3:28 pm
Remediation discipline fails when organisations treat every finding as a patching emergency. The article’s core point is that exposure reduction is not the same as instant removal of every defect. Security programmes that do not separate root-cause fixes from compensating controls end up with queue paralysis and unstable prioritisation. The practitioner conclusion is to design response paths by asset and exploitability, not by scanner volume.
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: How should security teams balance remediation with uptime requirements?
A: Security teams should agree response thresholds with operations before incidents occur. That means defining which severities can wait for a maintenance window, which need immediate compensating controls, and which require emergency change. Shared service-level expectations reduce conflict and stop patching from becoming a binary choice between security and availability.
👉 Read our full editorial: Vulnerability remediation vs mitigation: how to reduce exposure