SECURITY PROGRAM | VULNERABILITY MANAGEMENT

July 10, 202612 min read

Security Technical Debt: How to Quantify It, Prioritize It, and Actually Pay It Down

Sources:Gartner: Managing Security Technical Debt|SANS: Prioritizing Security Remediation Backlogs|CISA Known Exploited Vulnerabilities Catalog

Eric Bang

Founder & Cybersecurity Evangelist

57%

of security professionals say their organization has more known security issues than they can remediate — Ponemon 2025

6 years

median age of unpatched vulnerabilities in enterprise environments that have been confirmed exploitable

of CVEs with a CVSS Critical score are actually exploited in the wild — meaning 96% of 'critical' vulnerabilities are not being actively targeted

KEV catalog

CISA's Known Exploited Vulnerabilities catalog — the highest-signal prioritization source for what actually gets exploited and requires immediate attention

Step 1: Inventory your security debt

You cannot manage what you have not catalogued. Security debt exists in several categories that are usually tracked in separate systems with no unified view.

Vulnerability scanner findings

Your vulnerability scanner (Tenable, Qualys, Rapid7) produces findings continuously. Extract the current open finding count by severity (Critical, High, Medium, Low), by age in backlog (findings older than 90 days, 180 days, 1 year, 2+ years), and by asset criticality. Aging data reveals your actual remediation rate — if your high-severity finding count is growing month over month, you are producing debt faster than you are paying it down.

End-of-life systems and software

Systems running end-of-life operating systems (Windows Server 2012, older RHEL versions), end-of-life software (unsupported application versions, deprecated libraries), and end-of-support databases that no longer receive security patches. These are permanent vulnerabilities — no patch will be released — and must be tracked separately from patchable vulnerabilities because the remediation path is migration or replacement, not patching.

Configuration gaps

Known-bad configurations that have not been corrected: systems not covered by your EDR, MFA gaps for privileged accounts, applications not sending logs to your SIEM, backup jobs that have been failing silently, legacy authentication protocols (NTLM, basic auth) still in use. These are typically identified by compliance scans, pen tests, or security reviews and live in spreadsheets and audit reports rather than vulnerability scanners.

Architectural debt

Design-level weaknesses that cannot be patched away: network segments with insufficient isolation, applications without authentication at internal service calls, admin interfaces accessible from the production network, or legacy application architectures that make code injection vulnerabilities structurally likely. Architectural debt is the most expensive to address and the least visible — it rarely appears in scanner output.

Subscribe to unlock Remediation & Mitigation steps

Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.

Step 2: Prioritize by actual exploitation risk, not CVSS score

CVSS scores are severity assessments, not risk assessments. A CVSS 9.8 vulnerability on an internal system that is not reachable from the internet and requires authenticated access has lower actual risk than a CVSS 7.0 vulnerability that is actively being exploited in the wild against internet-exposed services in your industry.

Prioritization criteria that correlate with actual breach risk:

CISA KEV catalog membership

The CISA Known Exploited Vulnerabilities catalog lists CVEs that have confirmed active exploitation evidence. KEV membership is the single highest-signal filter — a CVE in the KEV catalog is being actively exploited by real attackers against real organizations. Apply KEV membership as your first filter: any open finding that matches a KEV CVE is immediately elevated to the top of your remediation queue regardless of CVSS score.

EPSS score (Exploit Prediction Scoring System)

EPSS provides a probability score (0-100%) for exploitation of a given CVE within the next 30 days, based on exploitation patterns, public proof-of-concept availability, and threat actor targeting. CVEs with high EPSS scores are more likely to be exploited than CVEs with high CVSS scores. Cross-referencing your backlog against EPSS scores (available via first.org) converts the prioritization from theoretical severity to empirical exploitation probability.

Asset criticality and exposure

A critical vulnerability on an internet-exposed, unauthenticated service has higher priority than the same vulnerability on an internal, authenticated, non-critical development system. Map each open finding to the criticality tier of the affected asset (tier 1: internet-exposed production, tier 2: internal production, tier 3: internal non-production) and the authentication requirement to reach the vulnerable component. This produces a risk score that reflects actual exploitation difficulty.

Active threat actor targeting in your sector

Threat intelligence on which vulnerability classes are being actively targeted against your industry vertical elevates the priority of matching findings. If your threat intelligence indicates that a specific CVE is being exploited in campaigns against financial services firms and you are a financial services firm with that CVE open, that is higher priority than a more severe CVE that is not in active exploitation against your sector.

Subscribe to unlock Remediation & Mitigation steps

Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.

Free daily briefing

Briefings like this, every morning before 9am.

Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.

Step 3: Build a debt reduction program, not a debt inventory

Most security teams have the inventory. Few have the program to actually reduce it. The difference is resourcing, deadlines, and accountability — not more scanning.

Set a debt reduction target, not a remediation rate target

Measuring remediation rate (we closed 500 vulnerabilities this quarter) is misleading if the scanner is producing 600 new findings per quarter — you are accumulating debt at 100 findings per quarter with a positive-sounding metric. Measure debt reduction: is the total count of open high-severity findings going down or up over time? Set a target: reduce high-severity finding count by 20% per quarter until reaching a steady-state maintenance level.

Separate maintenance patching from backlog clearance

Your security team's capacity gets consumed by ongoing patching of new vulnerabilities, leaving nothing for the historical backlog. Separate these tracks: routine patching cadence (monthly, quarterly) handles new findings; a dedicated backlog sprint allocation handles historical debt. Without explicit allocation, historical debt never gets addressed because routine work fills all available capacity.

Quantify debt in business risk terms for resource discussions

A list of 2,000 open vulnerabilities does not secure remediation resources from executive leadership. A risk-adjusted quantification does: 'We have 23 systems running end-of-life software that cannot receive patches for critical vulnerabilities currently being exploited in our sector. Breach probability on these systems is materially higher than our patched systems. The estimated cost to migrate these systems is $X. The average cost of a breach attributed to unpatched vulnerabilities in our sector is $Y.' This is the language that secures resource allocation.

Track EOL systems to a documented migration plan

End-of-life systems cannot be patched and tend to remain in backlogs indefinitely because migration requires significant effort. Every EOL system in your environment should have a documented state: migrating by [date], compensating controls in place (network isolation, enhanced monitoring), or accepted risk with documented business justification. 'Unknown' is not an acceptable state for systems that cannot receive security patches.

Subscribe to unlock Remediation & Mitigation steps

Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.

Compensating controls for debt you cannot pay down immediately

Not all security debt can be remediated immediately. For high-risk debt items where remediation is delayed (due to cost, business disruption, or technical complexity), compensating controls reduce the risk while the primary fix is being planned.

Network isolation for EOL systems

EOL systems that cannot be migrated immediately should be isolated to dedicated network segments with strict inbound and outbound firewall rules — only the specific traffic required for their function. This limits the blast radius if the EOL system is compromised: it cannot be used as a pivot to reach other systems in the same network segment.

Enhanced monitoring for known-vulnerable assets

Assets with known open critical vulnerabilities — especially those in the CISA KEV catalog — should have enhanced logging and monitoring applied immediately while remediation is being planned. This at minimum ensures you would detect exploitation if it occurs, even if you cannot prevent it.

Formal risk acceptance for deferred items

Security debt that has been deliberately deferred with compensating controls should be formally accepted through your risk management process: documented, signed by the appropriate risk owner, with a review date. Informal deferral ('we'll get to it') is how technical debt becomes a permanent fixture. Formal acceptance with a review date creates accountability for revisiting the decision.

Subscribe to unlock Remediation & Mitigation steps

Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.

The bottom line

Security technical debt grows through inaction and shrinks only through deliberate program investment. The organizations with the cleanest backlogs are not those that never accumulated debt — it is those that built a consistent program to reduce it: CISA KEV and EPSS-prioritized remediation, a dedicated backlog reduction track separate from routine patching, and executive-level visibility into debt as a business risk rather than a vulnerability count. Converting the backlog from a security team problem into a business risk discussion is what drives the resource allocation needed to pay it down.

Frequently asked questions

What is the difference between vulnerability management and security technical debt management?

Vulnerability management focuses on the ongoing cycle of scan, identify, patch, and verify for new vulnerabilities as they are disclosed and discovered. Security technical debt management addresses the accumulated backlog of known issues that did not get fixed — EOL systems, configuration gaps, architectural weaknesses, and findings that were repeatedly deferred. The two require different processes: vulnerability management is operational and cyclical; debt management is programmatic and requires separate resource allocation to make progress.

How do I get executive buy-in to address security technical debt?

Translate findings into business risk language: what breach scenario does this debt enable, what is the estimated cost of that scenario, what is the cost to remediate versus the expected risk reduction? Use concrete examples from your sector: 'The Colonial Pipeline attack exploited a vulnerability similar to the ones in our EOL system category — the downtime cost was $X.' Risk-adjusted ROI framing is more effective than vulnerability counts. Also show trend data: if your debt is growing quarter over quarter, this is a measurable deteriorating risk posture that represents a decision being made by inaction.

Should every finding in the backlog eventually be fixed?

No. The correct disposition for security findings is one of: remediate, mitigate with compensating controls, or accept with documented risk rationale. Acceptance is a legitimate outcome for low-probability, low-impact risks where mitigation cost exceeds expected risk reduction. The problem is when acceptance happens by default (we just never got to it) rather than by deliberate decision. Every finding should have an explicit disposition with a date, an owner, and a review trigger.

Sources & references

Free resources

Free download

Critical CVE Reference Card 2025–2026

25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.

Free download

Ransomware Incident Response Playbook

Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.

Free newsletter

Get threat intel before your inbox does.

50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.

Unsubscribe anytime. We never sell your data.

Author

Eric BangCISSP

Founder & Cybersecurity Evangelist, Decryption Digest

Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.

View profile →LinkedIn

Back to all briefings

Subscribe for Updates

security technical debt security backlog remediation legacy system security deferred security work security debt quantification security program management vulnerability backlog prioritization security debt framework 2026

Black Hat Giveaway

Win a $2,495 Black Hat pass.

Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.

Security Technical Debt: How to Quantify It, Prioritize It, and Actually Pay It Down

Step 1: Inventory your security debt

Step 2: Prioritize by actual exploitation risk, not CVSS score

Step 3: Build a debt reduction program, not a debt inventory

Compensating controls for debt you cannot pay down immediately

The bottom line

Frequently asked questions

What is the difference between vulnerability management and security technical debt management?

How do I get executive buy-in to address security technical debt?

Should every finding in the backlog eventually be fixed?

Sources & references

Critical CVE Reference Card 2025–2026

Ransomware Incident Response Playbook

Get threat intel before your inbox does.

Subscribe to enter the giveaway