"We already manage our vulnerabilities; we run regular security scans."
If you are a CIO or CISO, you may have said this before. And it’s a fair point: your tools are likely in place, your scan cycles are scheduled, and your dashboards are populated. On the surface, everything is under control.
The problem is that between scans, your attack surface keeps evolving. And assets you once considered secure may no longer be.
The challenge is no longer just about detecting flaws at regular intervals, but about managing your exposure in real time, based on threats, your specific context, and your actual remediation capacity.
That is exactly the promise of CTEM (Continuous Threat Exposure Management): shifting from periodic checks to continuous, structured risk management.
In this article, we will break down this essential approach, understand how it redefines vulnerability management, and see how Cyberwatch helps you integrate it into your daily operations.
CTEM: A new approach to the limitations of traditional vulnerability management
For years, vulnerability management (VM) and IT security relied on periodic audits: a monthly scan, a quarterly pentest, an annual compliance audit.
But this approach is no longer in sync with the reality of modern IT environments. Here’s why:
1) Increasingly dynamic and ephemeral infrastructures
The traditional vulnerability management model is based on a simple principle: taking a snapshot of the IT security posture at a specific point in time, analyzing the results, and then fixing the identified issues.
The problem is that in the era of cloud and continuous deployment, this snapshot becomes outdated the very second it is 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 shut it down.
Your next scan will discover these issues 2 to 4 weeks late, at best.
This scenario is not hypothetical. In modern architectures, with hybrid multi-cloud environments, thousands of microservices, containers orchestrated by Kubernetes, serverless functions, or even publicly exposed APIs, your attack surface is effectively multiplied and changes to your infrastructure are constant.
The consequence is immediate: the asset mapping your analysis relies on quickly becomes obsolete, and some assets slip through your monitoring.
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 data from FIRST (Forum of Incident Response and Security Teams), nearly 50,000 CVEs were recorded in 2025. That is an increase of approximately 21% over one year, following an estimated 39% rise between 2023 and 2024.
On top of this avalanche of vulnerabilities comes an acceleration in exploitation times: attackers are now industrializing the exploitation of critical flaws, and for the most high-profile vulnerabilities (like Log4Shell a few years ago), the time between publication 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 scanning 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 within what timeframe.
However, in traditional approaches, prioritization still relies largely on generic technical scores (CVSS), without taking into account:
- The actual exposure of the asset,
- Its business criticality,
- The existence of active exploits,
- Or your operational remediation capacity.
The result: your teams accumulate thousands of vulnerabilities without being able to clearly identify which ones must be addressed first.
Several weeks (sometimes several months) can therefore pass between the detection of a critical flaw and its effective remediation.
This gap is all the more problematic as regulatory pressure intensifies. The NIS2 directive (applicable since October 2024) imposes strengthened cyber risk management obligations, with penalties of up to 2% of global annual turnover.
To address all these challenges, simply improving scans is no longer enough: you need to change your approach. That is the whole 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 advisory firm Gartner in 2022, as part of its work on "exposure management."
Gartner defines it as a set of processes and capabilities organized into five phases (which we will detail shortly), allowing for the continuous assessment of the accessibility, exposure, and exploitability of digital and physical assets.
Two elements are essential to this definition:
- First, CTEM is not just a tool. It is a comprehensive methodological framework, which structures how an organization measures its actual exposure, prioritizes its security actions, and concretely reduces the risk of compromise.
- Next, the approach is resolutely focused on exploitability and business impact, rather than just vulnerability detection. The goal is no longer just to know how many flaws 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 threat exposure through a continuous cycle.
The 5 phases of the CTEM framework
The CTEM framework is structured around five phases :
These five phases form a continuous loop, which is precisely what distinguishes them from a standard sequence of security actions.
- Discovery : everything begins with a reliable and 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 truly priority scope. The analysis focuses on critical assets and compromise scenarios with a significant business impact, rather than treating the entire IT system uniformly.
- Prioritization : In a context where not everything can be fixed immediately, this step allows you to rank vulnerabilities based on actual risk. Unlike traditional approaches based solely on CVSS scores, this prioritization incorporates contextual criteria: the existence of active exploits, the probability of exploitation (via scores like EPSS), and the network exposure level of the affected asset.
- Validation : Before mobilizing teams, it is essential to confirm that the risk is concrete. Attack path analysis or simulations help identify truly exploitable flaws and rule out those that do not pose an immediate threat.
- Mobilization : The final phase transforms prioritization into remediation actions that are planned and managed over time, taking into account operational constraints and the team's actual capacity to fix issues.
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 management and compliance management platform: not just another brick in your security stack, but the platform that operationalizes every step of the CTEM cycle.
Implementing CTEM with Cyberwatch, step by step
1) Discovery: build a reliable and living inventory of your assets
Without an exhaustive and up-to-date inventory, CTEM is impossible.
That is why Cyberwatch relies on a wide range of discovery mechanisms to automatically identify the assets in your infrastructure, whether they are on-premises, in the cloud, containerized, or external.
The main discovery mechanisms:
- On-premises infrastructure : network scans and targeted discovery to detect unregistered machines, followed by onboarding (agentless mode available), organization into groups, and ongoing tracking via recurring executions.
- Cloud (AWS, Azure, GCP, OpenStack, etc.) : querying APIs 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, etc.) : inventory of images (registries and/or currently deployed images) with automatic addition for analysis.
- External exposure (IP / DNS / WHOIS / Certificate Transparency) : scanning IP ranges and domain inventories, detecting related domains (brands, subsidiaries, forgotten domains), and identifying 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 maintain a reliable, continuous view of your attack surface.
2) Scoping: define a perimeter aligned with your business objectives
Once the inventory has been made reliable through the discovery phase, the challenge is no longer to analyze everything in the same way, but to adapt the level of rigor to the level of risk.
A critical asset like an ERP server exposed on the Internet must, for example, be prioritized, while a low-exposure asset, such as an isolated development environment, is assigned a lower priority.
Scoping consists precisely of organizing your attack surface into coherent perimeters to avoid noise and focus your efforts where the business impact is real.
With Cyberwatch, this logic is implemented through organizing assets into projects or into 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: IT Dept + CISO
This segmentation avoids overestimating unrealistic risks while applying higher standards to critical resources.
3) Prioritization: moving from CVE volume to truly critical risk
Once the inventory is under control and the scope is defined, the goal becomes clear: determining what needs to be fixed first.
In practical terms, this means transforming a list of thousands of vulnerabilities into a short, contextualized queue aligned with your business objectives.
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 CVSS score based on context: the CVSS-BTE.
This score takes your technical reality into account: for example, a server completely isolated from the network can be defined as locally accessible only. Vulnerabilities exploitable remotely will then have their criticality automatically downgraded. Conversely, a flaw affecting a system exposed in production will maintain a high priority level.
In addition to this contextualization, there is a threat-informed scanning. Vulnerabilities flagged as high priority are those that combine:
- A CVSS threshold above which a flaw must be addressed,
- The EPSS score, which reflects the probability of exploitation in the real world,
- Presence in reference catalogs such as CERT-FR ALE, CISA KEV, or lists maintained by Cyberwatch.
We no longer think in terms of overall theoretical severity, but in terms of actual risk to a specific asset.
Prioritization thus becomes directly actionable for teams: efforts are focused on vulnerabilities that are critical, exposed, and likely to be exploited, rather than on a backlog of unprioritized CVEs.
4) Validation: verify exploitability and measure patch effectiveness
After defining which vulnerabilities to prioritize, the validation phase involves measuring the effectiveness of the decisions made by answering two key questions:
- Is the threat truly real in your specific context?
- Have the remediation actions effectively eliminated the risk?
The goal is to move from theoretical decision-making to a measurable reduction in exposure.
In Cyberwatch, this validation begins by contextualizing each CVE: the vulnerability encyclopedia centralizes technical severity (CVSS and CVSS-BTE), available patches, and, most importantly, the existence of public exploits or known attack tools for any given flaw.
Cross-referenced with the EPSS score and inclusion in reference catalogs (CERT-FR, CISA KEV, etc.), this information makes it possible to immediately identify vulnerabilities that are actively exploited, easily weaponized in attack campaigns, and recognized as critical by leading authorities.
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, changing a configuration, or removing a service, Cyberwatch automatically re-scans the affected assets. The actual disappearance of the CVE is verified, detection and remediation dates are logged, and the total exposure time is calculated.
You no longer just report a patch as deployed: you prove that the risk has been eliminated, detect remediation failures, and identify any potential regressions.
These metrics 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 are validated, the challenge is to move to execution: patching, tracking progress, and demonstrating that the risk is actually decreasing. This is the role of the mobilization phase, where Cyberwatch becomes the focal point for security teams, IT operations, and management.
It is based on three concrete dimensions:
Orchestrating technical remediation with patch management
The patch management view creates a direct link between a priority vulnerability and the action to be taken. 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 into existing tools like 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 flaws: it provides a traceable technical action plan, vulnerability by vulnerability.
Integrating with IT workflows via ITSM
Mobilization also means aligning with the processes of the teams in charge of remediation.
ITSM integrations (ServiceNow, Microsoft Teams, GLPI, Jira, etc.) allow you to automatically turn a validated vulnerability into a pre-filled ticket containing all the necessary context: the affected asset, criticality level, and recommended fix.
Security teams manage everything within Cyberwatch while IT teams work in their usual tools, keeping the entire chain continuous and synchronized.
Managing remediation over time
Effort is only sustainable if it is measurable. Cyberwatch tracks the detection and remediation dates for every vulnerability and calculates processing times.
This data powers the dashboards : critical vulnerabilities by scope, mean time to remediate, SLA compliance, and scan coverage.
The alerting module automatically triggers notifications or integrations when a threshold is reached, such as a new critical CVE, an obsolete system, or an expired remediation deadline.
You are no longer just tracking deployed patches; you are managing long-term risk reduction goals.
This traceability helps support steering committees, demonstrate compliance (notably with NIS2), and base decisions on factual, field-derived metrics.
CTEM: key takeaways
Implementing a CTEM program ultimately means shifting your posture: moving from ad-hoc vulnerability management to continuous exposure surface management.
With Cyberwatch, this approach becomes very tangible, as every stage of the cycle is translated into operational action within the platform:
- A reliable and dynamic inventory of all your assets, including those that traditional approaches miss
- Segmentation of your attack surface aligned with your business objectives and criticality levels
- Moving beyond the "infinite backlog" to focus efforts on exploitable vulnerabilities that are specifically targeted and critical to your environment
- Transitioning from abstract CVEs to proven exposure, with systematic re-scanning and reference catalogs
- Orchestrated and traceable remediation, from patch deployment to demonstrating risk reduction
This continuity between detection, decision-making, and action is what allows you to effectively address today's challenges: operational resilience, regulatory compliance (NIS2), and transparency for your governance.
Would you like to see how this approach works in a real-world environment? Request a Cyberwatch demo.
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 leverages discovery, analysis, and remediation tools to drive risk reduction.
Why has CTEM become a benchmark approach in cybersecurity?
It has become essential because it allows cybersecurity to adapt 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 link between CTEM and NIS2?
CTEM facilitates NIS2 compliance by providing a continuous view of risk, along with remediation tracking and performance indicators.
