“We already manage our vulnerabilities; we perform regular security scans.”
If you’re a CIO or CISO, you may have said this before. And it’s a valid point: your tools are likely in place, your analysis cycles are scheduled, and your dashboards are filling up. On the surface, everything seems under control.
The problem is that between scans, your attack surface continues to evolve. And your assets, once considered secure, may no longer be so.
The challenge is therefore no longer just to detect your vulnerabilities at regular intervals, but to manage your exposure in real time, based on threats, your context, and your actual remediation capabilities.
This is exactly what CTEM (Continuous Threat Exposure Management) promises: moving from a periodic control approach to continuous, structured risk management.
In this article, we’ll break down this now-essential approach, understand how it redefines vulnerability management, and explain how Cyberwatch enables you to integrate it into your practices.
CTEM: A New Approach to the Limitations of Traditional Vulnerability Management
For years, vulnerability management (VM) and information system security relied on periodic audits: a monthly scan, a quarterly penetration test, an annual compliance audit.
But this approach is no longer in step with the reality of modern information systems. And this is for several reasons:
1) Increasingly dynamic and ephemeral infrastructures
The traditional vulnerability management model is based on a simple principle: taking a snapshot of the information system’s security status at a given moment, analyzing the results, and then fixing the identified issues.
But here’s the thing: in the age of the cloud and continuous deployments, that snapshot becomes outdated the moment it’s taken.
Imagine a monthly scan cycle that runs on the 1st of the month. On the 3rd, your DevOps team deploys a microservice with a vulnerable dependency. On the 7th, a critical CVE is published for a component present in 30% of your infrastructure. On the 15th, an intern launches an EC2 instance to test a POC and forgets to deactivate it.
Your next scan will uncover these issues 2 to 4 weeks later, at best.
This scenario is not hypothetical. In modern architectures, with hybrid multi-cloud environments, thousands of microservices, Kubernetes-orchestrated containers, serverless functions, and publicly exposed APIs, your attack surface is effectively multiplied, and changes to your infrastructure are constant.
The consequence is immediate: the asset inventory on which your analysis relies quickly becomes obsolete, and some assets slip through the cracks.
2) An exploding volume of vulnerabilities
Beyond these blind spots in asset monitoring, the volume of vulnerabilities to address is increasing at an unprecedented rate.
According to figures from FIRST (Forum of Incident Response and Security Teams), nearly 50,000 CVEs were recorded in 2025. This represents an increase of approximately 21% year-over-year, following a rise already estimated at +39% between 2023 and 2024.
Added to this avalanche of vulnerabilities is a shortening of exploitation timelines: attackers are now industrializing the exploitation of critical flaws, and for the most high-profile vulnerabilities (such as Log4Shell a few years ago), the time between disclosure and the first attacks sometimes drops to less than 24 hours.
The result: the remediation window is shrinking drastically, further widening the gap with periodic analysis cycles.
3) Prioritization that remains too disconnected from actual risk
In this context, you can no longer address everything: you need to know what to fix first, and by when.
However, in traditional approaches, prioritization still relies heavily on generic technical scores (CVSS), without taking into account:
- The asset’s actual exposure,
- Its business criticality,
- The existence of active exploits,
- Or your operational capacity to remediate.
The result: your teams accumulate thousands of vulnerabilities without being able to clearly identify which ones need to be addressed first.
Several weeks (sometimes several months) can therefore elapse between the detection of a critical vulnerability and its effective remediation.
This delay is all the more problematic as regulatory pressure intensifies. The NIS2 Directive (effective since October 2024) imposes stricter cyber risk management obligations, with penalties of up to 2% of global revenue.
To address all these challenges, it is no longer enough to improve scans: a new approach is needed. This is the very purpose of CTEM.
CTEM Under the Microscope: Definition and Key Principles of Continuous Threat Exposure Management
A concept popularized by Gartner
The term CTEM (Continuous Threat Exposure Management) was introduced by the research and consulting firm Gartner in 2022, in its work on “exposure management.”
Gartner defines it as a set of processes and capabilities organized into five phases (which we will detail shortly), enabling the continuous assessment of the accessibility, exposure, and exploitability of digital and physical assets.
Two elements are essential to this definition:
- First, the CTEM is not merely a tool. It is a comprehensive methodological framework that structures how an organization measures its actual exposure, prioritizes its security actions, and tangibly reduces the risk of compromise.
- Second, the approach is firmly focused on exploitability and business impact, rather than solely on vulnerability detection. The goal is no longer merely to determine how many vulnerabilities exist in the information system, but which ones can actually be exploited, on which critical assets, and with what consequences for the organization.
The objective is clear: to systematically and measurably reduce exposure to threats through a continuous cycle.
The 5 phases of the CTEM framework
The CTEM framework is structured around five phases:
- Discovery: It all starts with a reliable, up-to-date view of the attack surface. This phase involves identifying assets, exposed services, identities, and cloud resources—including those that fall outside traditional inventories.
- Scoping: Once this visibility is achieved, the challenge is to define the scope that truly takes priority. The analysis focuses on critical assets and compromise scenarios with a significant business impact, rather than treating the entire IT infrastructure uniformly.
- Prioritization: In a context where not everything can be fixed immediately, this step allows vulnerabilities to be ranked according to actual risk. Unlike traditional approaches based solely on the CVSS score, prioritization here incorporates contextual criteria: the existence of active exploits, the probability of exploitation (via scores such as the EPSS), or the level of network exposure of the asset in question.
- Validation: Before mobilizing teams, it is essential to confirm that the risk is real. Attack path analysis or simulations help identify vulnerabilities that can actually be exploited and rule out those that do not pose an immediate threat.
- Mobilization: The final phase transforms prioritization into planned, time-bound remediation actions, taking into account operational constraints and the teams’ actual capacity to address the issues.
These five phases form a continuous loop, and this is precisely what sets them apart from a traditional sequence of security actions.
This leaves one key question: how can you industrialize this cycle and truly integrate it into your security operations?
This is where Cyberwatch comes in, our vulnerability and compliance management platform: not as just another component in your security stack, but as the platform that operationalizes every step of the CTEM cycle.
Implementing CTEM with Cyberwatch, step by step
1) Discovery: Build a reliable, dynamic inventory of your assets
Without a comprehensive and up-to-date inventory, CTEM is impossible.
That’s why Cyberwatch leverages a wide range of discovery mechanisms to automatically identify the assets in your infrastructure, whether they’re on-premises, in the cloud, containerized, or external.
Key discovery mechanisms:
- On-premises infrastructure: network scans and targeted discovery to detect unregistered machines, followed by integration (possible in agentless mode), organization into groups, and ongoing monitoring via recurring scans.
- Cloud (AWS, Azure, GCP, OpenStack…): API queries to map VMs and associated resources (e.g., Microsoft Entra ID), with multi-project/multi-region coverage and recurring updates.
- Docker & Kubernetes (EKS/AKS/OpenShift…): image inventory (registries and/or images actually deployed) with automatic addition for analysis.
- External Exposure (IP / DNS / WHOIS / Certificate Transparency): IP range scanning and domain inventory, detection of related domains (brands, subsidiaries, forgotten domains), and identification of subdomains via public TLS certificate logs (Certificate Transparency), including those that evade traditional DNS approaches.
Ultimately, every newly detected asset is automatically integrated, and decommissioned assets are removed from the inventory: you have a continuously reliable view of your exposure surface.
2) Scoping: defining a scope aligned with your business priorities
Once the inventory has been validated through the discovery phase, the challenge is no longer to analyze everything in the same way, but to adapt the level of scrutiny to the level of risk.
A critical asset, such as an ERP server exposed to the Internet, must, for example, be monitored as a priority, while a low-exposure asset, such as an isolated development environment, is a lower priority.
Scoping involves organizing your attack surface into coherent scopes to eliminate noise and focus your efforts where the business impact is real.
With Cyberwatch, this approach is implemented by organizing assets intoprojects or groups corresponding to your environments (Production, DMZ, web servers, testing, etc.).
Each perimeter can then have its own rules: scan frequency, alert thresholds, prioritization criteria, or access rights.
For example:
“Production” Project
├─ Scan frequency: daily
├─ Alert threshold: CVSS ≥ 9.0 (immediate notification)
└─ Access: CIO + CISO
It is also possible to precisely define the IP ranges to be monitored and to distinguish exposed assets from internal systems.
This segmentation prevents the overestimation of unrealistic risks while applying a higher level of scrutiny to critical resources.
3) Prioritization: Moving from CVE volume to actual critical risk
Once the inventory is under control and the scope defined, the challenge becomes clear: determining what needs to be fixed first.
In practical terms, this involves transforming a list of thousands of vulnerabilities into a short, contextualized queue aligned with your business priorities.
In Cyberwatch, this prioritization is based first on defining a criticality policy for each asset. Each scope is assigned Confidentiality, Integrity, and Availability (CIA) requirements that allow for the recalculation of a contextual CVSS score: the CVSS-BTE.
This score takes your technical reality into account: for example, a server completely isolated from the network can be defined as accessible only locally. The criticality of remotely exploitable vulnerabilities is then automatically downgraded. Conversely, a flaw affecting an exposed system in production will retain a high priority level.
This contextualization is complemented by a threat-oriented analysis. Vulnerabilities flagged as high priority are those that combine:
- A CVSS threshold above which a vulnerability must be addressed,
- The EPSS score, which reflects the probability of exploitation in the real world,
Inclusion in reference catalogs such as CERT-FR ALE, CISA KEV, or the lists maintained by Cyberwatch.
We no longer think in terms of overall theoretical severity, but in terms of actual risk to a given asset.
Prioritization thus becomes directly actionable by teams: efforts are focused on critical vulnerabilities that are exposed and likely to be exploited, rather than on an unprioritized backlog of CVEs.
4) Validation: Verifying Exploitability and Measuring the Effectiveness of Patches
After defining the vulnerabilities to be addressed as a priority, the validation phase consists of measuring the effectiveness of the decisions made by answering two key questions:
- Is the threat truly real in your context?
- Have the remediation actions effectively eliminated the risk?
The goal is to move from a theoretical decision to a measurable reduction in exposure.
In Cyberwatch, this validation begins by contextualizing each CVE: the vulnerability encyclopedia centralizes, for a given vulnerability, the technical severity (CVSS and CVSS-BTE), available patches, and, most importantly, the existence of public exploits or known attack tools.
Cross-referenced with the EPSS score and inclusion in reference catalogs (CERT-FR, CISA KEV, etc.), this information allows for the immediate identification of vulnerabilities that are actively exploited, easy to scale in attack campaigns, and recognized as critical by authoritative bodies.
Conversely, a severe vulnerability with no known exploit and a low probability of exploitation can be objectively reclassified.
Validation also covers the effectiveness of fixes. After deploying a patch, making a configuration change, or removing a service, Cyberwatch automatically reruns analyses on the affected assets. The CVE’s actual removal is verified, detection and fix dates are logged, and the exposure time is calculated.
You no longer simply report that a fix has been deployed: you demonstrate that the risk has been eliminated, detect remediation failures, and identify any regressions.
These indicators directly inform CTEM management by providing a factual measure of the effectiveness of the actions taken.
5) Mobilization: Orchestrating remediation and driving risk reduction
Once vulnerabilities have been validated, the challenge is to move to execution: fix, track progress, and demonstrate that the risk is actually decreasing. This is the role of the mobilization phase, where Cyberwatch becomes the central hub connecting security teams, IT operations, and management.
In practice, it is based on three dimensions:
Orchestrating technical remediation with patch management
The patch management view establishes a direct link between a high-priority vulnerability and the required action. For each asset, it centralizes CVEs, associated patches, and possible operations.
Patches can be deployed automatically on Windows and Linux environments, with dependency management and integration with existing tools such as WSUS or Red Hat Satellite. When software itself is the source of the risk, its uninstallation can be triggered from the platform.
Cyberwatch is no longer limited to identifying vulnerabilities: it provides a traceable technical action plan, vulnerability by vulnerability.
Integrating with IT workflows via ITSM
Mobilizing also means aligning with the processes of the teams responsible for remediation.
ITSM integrations (ServiceNow, Microsoft Teams, GLPI, Jira, etc.) enable the automatic conversion of a validated vulnerability into a pre-filled ticket that includes all relevant context: the affected asset, severity level, and recommended fix.
Security teams manage the process in Cyberwatch, while IT teams work in their usual tools, yet the workflow remains seamless and synchronized.
Driving remediation over time
Mobilization is sustainable only if it is measurable. Cyberwatch logs the detection and resolution dates for each vulnerability and calculates processing times.
This data feeds into dashboards: critical vulnerabilities by scope, average remediation time, SLA compliance, and scan coverage.
The alert module automatically triggers notifications or integrations when a threshold is reached: new critical CVE, obsolete system, correction deadline exceeded.
You no longer just track deployed patches; you manage long-term risk reduction objectives.
This traceability enables you to provide insights to steering committees, demonstrate compliance (particularly NIS2), and base decisions on factual indicators from the field.
CTEM: Key Takeaways
Implementing a CTEM program ultimately means changing your approach: shifting from ad-hoc vulnerability management to continuous management of the attack surface.
With Cyberwatch, this approach becomes very concrete, as every stage of the cycle is operationally implemented within the platform:
- A reliable, dynamic inventory of all your assets, including those that fall outside traditional approaches
- Segmentation of your attack surface aligned with your business priorities and criticality levels
- Moving away from the “endless backlog” to focus efforts on exploitable vulnerabilities that are effectively targeted and critical to your context
- The transition from abstract CVEs to proven exposure, with systematic re-scanning and reference catalogs
- Orchestrated and traceable remediation, from patch deployment to demonstration of risk reduction
It is this continuity between detection, decision-making, and action that enables a concrete response to current challenges: operational resilience, regulatory compliance (NIS2), and transparency with respect to your governance.
Would you like to see how this approach translates into practice in a real-world environment?
CTEM FAQ
What is Continuous Threat Exposure Management (CTEM)?
CTEM is a framework defined by Gartner to continuously identify exposed assets, prioritize exploitable vulnerabilities, and effectively reduce the risk of compromise.
Is CTEM a tool or a methodology?
CTEM is a methodology that relies on discovery, analysis, and remediation tools to drive risk reduction.
Why has CTEM become a leading approach in cybersecurity?
It has gained prominence in particular because it enables cybersecurity to be adapted to cloud and hybrid environments where the attack surface is constantly evolving.
What are the 5 phases of CTEM?
The CTEM framework defined by Gartner follows a continuous cycle: Discovery → Scoping → Prioritization → Validation → Mobilization.
What is the connection between CTEM and NIS2?
CTEM facilitates NIS2 compliance by providing a continuous view of risk, with tracking of remediation and performance metrics.