- Threat and Vulnerability Management (TVM) is a continuous, intelligence-driven process that identifies, prioritises, and remediates security weaknesses using real-time threat data, not just severity scores.
- It combines two disciplines: vulnerability management (finding weaknesses) and threat intelligence (understanding who is exploiting what, right now).
- The critical difference from traditional VM: TVM uses EPSS, CISA KEV, and live threat intelligence to rank vulnerabilities by actual exploitation risk, not just CVSS scores.
- Security researchers publish thousands of new CVEs every month. Only a small fraction are ever actively weaponised. TVM finds those and deprioritises the rest.
- The TVM lifecycle has seven phases: asset discovery, vulnerability identification, threat intelligence enrichment, risk-based prioritisation, remediation and mitigation, validation, and reporting.
- In 2026, TVM must cover cloud-native environments: ephemeral containers, infrastructure-as-code, and multi-cloud deployments require agentless discovery and shift-left scanning.
The problem is not a lack of vulnerability data. It is the impossibility of acting on all of it. Security teams cannot patch 40,000 CVEs per year. They need to know which ones matter right now, which ones attackers are actively weaponising, and which ones can wait.
That is what Threat and Vulnerability Management is for. This guide explains what TVM is, how it differs from traditional vulnerability management, how the process works, and what it means for security teams operating in 2026.
What is threat and vulnerability management?
Threat and Vulnerability Management (TVM) is a continuous, intelligence-driven security discipline that combines vulnerability assessment with real-time threat intelligence to identify, prioritise, and remediate security weaknesses based on actual exploitation risk rather than theoretical severity.
Understanding TVM starts with separating its two foundational concepts:
- A vulnerability is a technical weakness in a system: unpatched software, misconfigured cloud resources, weak access controls, or a known CVE. It is a potential entry point.
- A threat is an actor, campaign, or event actively exploiting weaknesses. It transforms a vulnerability from theoretical exposure to active risk.
Traditional vulnerability management handles the first without the second. It scans for weaknesses and assigns CVSS severity scores. TVM adds the threat layer: which of these vulnerabilities are threat actors using right now? Which ones have public exploit code? Which ones appear on the CISA Known Exploited Vulnerabilities catalogue? That context transforms a list of findings into a prioritised action plan.
TVM vs. traditional vulnerability management: what changed
| Traditional vulnerability management | Threat and vulnerability management (TVM) | |
|---|---|---|
| Scanning | Periodic scans (weekly, monthly, quarterly) | Continuous monitoring across all asset types |
| Prioritisation | CVSS score alone | CVSS + EPSS + CISA KEV + real-time threat intelligence |
| Threat context | None. Vulnerability data treated in isolation. | Active exploitation data enriches every finding |
| Remediation | Patch everything high or critical. No targeting. | Fix what is being weaponised now. Risk-based triage. |
| Asset discovery | Known assets only. Agent or scan-based. | Continuous discovery including cloud, containers, IoT, shadow IT |
| Output | CVE list with severity scores | Risk-ranked remediation queue mapped to attacker activity |
The shift from VM to TVM is not a tool change. It is a methodology change. Traditional vulnerability management was built for a world where new CVEs numbered in the thousands per year and organisations could realistically attempt to patch everything critical. That world no longer exists.
In 2026, the EPSS score for a CVE, combined with its presence or absence on the CISA KEV catalogue and active threat intelligence data, is a more actionable prioritisation signal than CVSS alone. Organisations using layered prioritisation methods reduce remediation waste and focus engineering effort on the vulnerabilities that actually get organisations breached.
The 7-phase TVM lifecycle
| Phase | Name | What happens | Key output |
|---|---|---|---|
| 1 | Asset discovery | Continuous inventory of all assets: endpoints, servers, cloud, containers, IoT, APIs | Complete, real-time asset inventory |
| 2 | Vulnerability identification | Automated scanning, agent-based detection, SAST/DAST, cloud posture scanning | Vulnerability list mapped to assets |
| 3 | Threat intelligence enrichment | Enrich findings with EPSS, CISA KEV, threat actor TTP data, active exploitation reports | Risk-weighted vulnerability list |
| 4 | Risk-based prioritisation | Score each vulnerability against exploitability, asset criticality, business context, and compensating controls | Ranked remediation queue |
| 5 | Remediation and mitigation | Patch, reconfigure, apply compensating controls, or formally accept risk with documentation | Closed vulnerabilities, tracked exceptions |
| 6 | Validation and verification | Re-scan and test to confirm fixes work and did not introduce new issues | Verified closure evidence |
| 7 | Reporting and metrics | Track MTTD, MTTR, vulnerability age, remediation rates, compliance posture over time | Programme dashboards, audit evidence, board metrics |
1 Asset discovery
You cannot protect what you cannot see. Asset discovery is the prerequisite for every subsequent TVM activity. A complete, continuously updated inventory of all assets, including hardware, software, cloud resources, containers, serverless functions, IoT devices, and shadow IT, forms the foundation of the programme.
Cloud-native environments have made this harder. Ephemeral containers spin up and down in seconds. Infrastructure-as-code creates and destroys resources automatically. Serverless functions have no persistent endpoint. TVM programmes in 2026 require agentless discovery that captures these short-lived resources alongside traditional endpoints and servers.
2 Vulnerability identification
Systematic identification of weaknesses across the discovered asset inventory. This combines multiple scanning approaches because no single method provides complete coverage:
- Authenticated network scanning: Logs into target systems to enumerate installed software, patch levels, and configuration settings
- Agent-based scanning: Lightweight agents on endpoints provide continuous real-time visibility without network access dependency
- Cloud security posture management (CSPM): Scans cloud configurations for misconfigurations, overpermissioned IAM roles, and exposed storage
- Container and CI/CD scanning: Analyses container images and infrastructure-as-code before deployment (shift-left)
- Web application scanning (DAST): Tests running web applications for injection flaws, authentication weaknesses, and access control issues
3 Threat intelligence enrichment
This is the phase that distinguishes TVM from traditional vulnerability management. Every identified vulnerability is enriched with real-world threat context before it reaches the prioritisation queue. Enrichment sources include:
- CISA KEV catalogue: The U.S. government’s authoritative list of CVEs confirmed to be actively exploited in the wild. If a CVE is on the KEV catalogue, it is being actively used by real attackers right now.
- EPSS (Exploit Prediction Scoring System): A probability score from 0 to 1 that estimates the likelihood of a CVE being exploited in the next 30 days based on historical exploitation patterns. Developed by FIRST.
- Threat intelligence feeds: Data from vendors, ISACs, government agencies, and dark web sources about which CVEs threat actor groups are actively incorporating into their toolkits.
- Vendor security advisories: Vendor-specific context about exploitability, affected configurations, and patch availability.
4 Risk-based prioritisation
Enriched vulnerability data is scored against organisational context to produce a prioritised remediation queue. Risk-based prioritisation considers:
- Exploitability: EPSS score, presence on CISA KEV, availability of public exploit code
- Asset criticality: Does this vulnerability affect a production database, a payment processing system, or a test environment? The same CVE carries different risk weight on different assets.
- Business context: What data does the affected system hold? What regulatory obligations apply? What is the blast radius if this system is compromised?
- Compensating controls: Does a network segmentation control, a WAF rule, or an authentication requirement already reduce exploitability in this environment?
The output is not a severity list. It is a ranked remediation queue that tells the engineering team exactly which vulnerabilities to fix today, which to schedule this week, and which can be formally deferred with documented risk acceptance.
5 Remediation and mitigation
Three possible responses to each prioritised vulnerability:
- Remediation: Full resolution. Applying a software patch, correcting a misconfiguration, or retiring a vulnerable system. The preferred outcome where feasible.
- Mitigation: Reducing exploitability without fully resolving the underlying weakness. Network segmentation, WAF rules, or enforcing MFA on a vulnerable authentication endpoint. Used when patching is not immediately possible due to vendor dependency, compatibility issues, or legacy systems.
- Risk acceptance: Formally documenting that a vulnerability will not be remediated or mitigated, stating the business justification and the residual risk accepted. Not a passive choice. A documented decision made at the appropriate authority level with a defined review date.
6 Validation and verification
Closing a ticket is not the same as fixing a vulnerability. Validation confirms that remediation was implemented correctly, that it actually addresses the vulnerability, and that it did not introduce new weaknesses. Re-scanning the asset after patching, running targeted penetration tests on previously vulnerable systems, and reviewing compensating controls for continued effectiveness are all part of this phase.
7 Reporting and metrics
TVM programmes generate evidence and metrics that serve multiple audiences: security teams need operational metrics for programme improvement, compliance teams need audit evidence, and executives need business-risk framing. Key metrics that mature TVM programmes track:
- Mean Time to Detect (MTTD): How long between a vulnerability being introduced and being identified
- Mean Time to Remediate (MTTR): How long between identification and confirmed closure, tracked by severity tier
- Vulnerability age distribution: What percentage of open vulnerabilities have been open for more than 30, 60, 90 days
- Remediation rate: What percentage of identified vulnerabilities are closed per cycle
- KEV coverage: What percentage of CISA KEV catalogue vulnerabilities affecting your environment have been remediated
A very small subset of disclosed vulnerabilities are simultaneously remotely exploitable and actively weaponised. Layering CVSS, EPSS, CISA KEV, and threat intelligence sharply narrows the urgent prioritisation workload. Organisations that apply this layered approach reduce alert fatigue and focus remediation effort on the vulnerabilities that actually drive breaches.
TVM in cloud-native environments: the 2026 challenge
Traditional TVM was designed for environments with stable, persistent assets: servers with fixed IP addresses, workstations with installed agents, applications with defined deployment schedules. Cloud-native environments break most of these assumptions.
- Ephemeral containers: Spin up and down in seconds. Agent-based scanning cannot keep pace. Container image scanning in CI/CD pipelines (shift-left) and runtime detection are required instead.
- Infrastructure-as-code (IaC): Security misconfigurations can be caught before resources are provisioned by scanning Terraform, CloudFormation, and Pulumi templates in the development pipeline.
- Multi-cloud deployments: AWS, Azure, and GCP each have different native log formats, IAM models, and security services. TVM programmes need unified visibility across all three without separate tools for each.
- Serverless and API exposure: Serverless functions have no persistent endpoint to scan. API security scanning and runtime behavioural monitoring are the coverage methods.
TVM tools and technology
| Tool category | Example platforms | What it covers | TVM phase |
|---|---|---|---|
| Vulnerability scanner | Nessus, Qualys, Rapid7 | Network, endpoint, and application vulnerability scanning | Identification |
| CSPM | Prisma Cloud, Defender for Cloud, AWS Security Hub | Cloud misconfiguration, IAM, container security | Discovery and identification |
| Threat intelligence | Recorded Future, MISP, OpenCTI | Active exploitation data, adversary TTPs, IOCs | Enrichment and prioritisation |
| EPSS and KEV tools | FIRST EPSS, CISA KEV, Kenna Security | Exploit probability and known exploited vulnerability tracking | Prioritisation |
| Patch management | WSUS, Intune, Tanium, BigFix | Automated patch deployment and compliance tracking | Remediation |
| GRC platform | ServiceNow GRC, Archer, Drata | Risk documentation, exception management, compliance reporting | Reporting and exceptions |
| SIEM / SOAR | Splunk, Microsoft Sentinel, XSOAR | Detection correlation and automated response to active exploitation | Continuous monitoring |
No single tool covers all seven TVM phases. Mature programmes integrate multiple tools through a common data layer, typically a GRC platform or SIEM that aggregates findings, tracks remediation, and produces reporting. The integration architecture is as important as the individual tools.
Who runs TVM and what qualifications do they need?
TVM sits at the intersection of security operations, threat intelligence, and risk management. In most organisations, it is owned by a vulnerability management analyst, a security engineer, or a dedicated TVM team within the security operations function.
The role requires:
- Technical skills: Vulnerability scanner operation (Nessus, Qualys), SIEM query proficiency, cloud security platform familiarity, scripting for automation (Python, PowerShell)
- Analytical skills: Threat intelligence interpretation, risk quantification, prioritisation framework application, data correlation across multiple sources
- Communication skills: Translating vulnerability data into business risk language for non-technical stakeholders, producing executive-level metrics, working cross-functionally with IT operations and development teams
- Relevant certifications: CompTIA Security+, CompTIA CySA+, GIAC GWAPT, Certified Vulnerability Assessor (CVA), or cloud-specific security certifications depending on environment focus
Explore Metana’s Cybersecurity Bootcamp
Covers the foundational skills for a TVM-focused career: network security, threat detection, vulnerability assessment, incident response, and compliance frameworks. Job guaranteed or tuition back within 180 days.
Explore at metana.io/cybersecurity-bootcamp →FAQ
What is threat and vulnerability management?
Threat and Vulnerability Management (TVM) is a continuous, intelligence-driven security process that identifies, prioritises, and remediates security weaknesses using real-time threat data. It combines vulnerability scanning with threat intelligence enrichment to rank vulnerabilities by actual exploitation risk rather than theoretical severity scores, enabling security teams to focus remediation effort on the weaknesses most likely to be exploited.
What is the difference between vulnerability management and threat and vulnerability management?
Traditional vulnerability management identifies weaknesses and assigns CVSS severity scores. TVM adds threat intelligence context to that data: which vulnerabilities are actively being exploited, which have public exploit code, and which appear on the CISA Known Exploited Vulnerabilities catalogue. TVM produces a risk-ranked remediation queue tied to real attacker activity. Traditional VM produces a severity list with no exploitation context.
What is CVSS and why is it not enough for prioritisation?
CVSS (Common Vulnerability Scoring System) is a standardised severity score from 0 to 10 that assesses the theoretical exploitability and impact of a vulnerability. It does not account for whether anyone is actually exploiting it. A CVSS 9.8 vulnerability that has never been used in an attack can be less urgent than a CVSS 7.5 vulnerability that ransomware groups are actively deploying. EPSS and the CISA KEV catalogue provide the exploitation probability and active use data that CVSS lacks.
What is the CISA KEV catalogue?
The CISA Known Exploited Vulnerabilities catalogue is the U.S. Cybersecurity and Infrastructure Security Agency’s authoritative list of CVEs confirmed to be actively exploited in the wild. Federal agencies are required to remediate KEV-listed vulnerabilities within defined timelines. For all organisations, KEV catalogue presence is the most reliable signal that a vulnerability is being used by real attackers right now and should be treated as highest priority regardless of CVSS score.
What does TVM mean for cloud-native environments?
Cloud-native environments require a fundamentally different TVM approach. Ephemeral containers cannot be scanned with agents. Infrastructure-as-code should be scanned before provisioning (shift-left). Multi-cloud environments need unified visibility across AWS, Azure, and GCP. Serverless functions require API security scanning and runtime behavioural detection rather than endpoint-based vulnerability assessment. NIST SP 800-228 (updated March 2026) provides the current authoritative framework for cloud-native TVM.
