Using risk cohorts to prioritize security updates

For many customers, the priority is to install the appropriate security updates as soon as possible. Customers with more complex environments may also conduct additional risk assessments to help prioritize their response. As security update packages address more CVEs, these customers face a familiar challenge: determining which vulnerabilities require immediate attention in their environment and which may be lower priority.

Each CVE still needs to be reviewed on its own merits, but many CVEs require analysts to answer the same questions about deployment, exposure, trust boundaries, and usage patterns. Grouping CVEs around those shared questions can provide a more efficient starting point for analysis.

We call these provisional groupings risk cohorts. They are an exploratory way to help customers organize their own analysis. They are not official Microsoft vulnerability categories, do not change Microsoft update guidance, and do not replace the assessment of individual CVEs.

Traditional triage looks at each CVE individually. What is its severity? Is it being exploited? Which systems are affected? How urgently should the update be prioritized? That analysis remains essential. In a large release, however, many of the environment-specific questions repeat across vulnerabilities.

For example, customers may repeatedly ask:

• Can untrusted content reach the affected component?
• Who can run code across the relevant privilege boundary?
• Is the affected role or feature deployed in the organization?

A risk cohort is a group of CVEs that require a similar customer assessment. The CVEs may not share a root cause or a CVSS score. What they share is a question about the customer environment that can inform prioritization.

Risk cohorts are a starting point, not a final decision. Customers should continue to review each CVE for active exploitation, severity, attack vector, user interaction, and product-specific guidance.

The examples below show one way customers might organize vulnerabilities around common deployment and exposure questions. These groupings are exploratory and are provided for illustrative purposes only. The examples are intended to demonstrate the concept rather than define official Microsoft vulnerability categories. Please see the list of CVEs in each cohort here.

In this example, customers could use a smaller set of shared assessments to inform the review of hundreds of vulnerabilities. The cohort does not determine priority by itself. It reduces repeated environment analysis while keeping the differences between individual CVEs visible.

The Remote-access and RDP deployments cohort includes 64 CVEs in RDP client, gateway, and server components. The shared question is: which client, gateway, and server roles are deployed and exposed?

An analyst could use questions such as these to establish the deployment context:

• Do we run RD Gateway or RD Session Host roles that are reachable from outside the corporate network? If so, prioritize the server-side CVEs. These roles are more likely to receive unauthenticated or low-trust traffic.

• Do managed devices use RDP to connect to internal or third-party hosts? If so, the client-side CVEs need more attention. A malicious or compromised remote host could target a vulnerable RDP client.

• Are RDP endpoints available only through a VPN or Zero Trust access path, with no direct internet exposure? If so, some CVEs in the cohort may be lower priority for immediate action because the likely attack path requires access you already restrict.

These answers can help customers prioritize their risk management practices by giving context to the CVEs in the cohort. Individual vulnerabilities may still require greater attention because they are known to be exploited, do not require authentication, use a different attack vector, or otherwise differ from the broader cohort pattern.

CVEs within a cohort will still differ in severity and exploitability. In the illustrative Office cohort, for example, the 119 CVEs include remote code execution, information disclosure, elevation of privilege, and security feature bypass vulnerabilities. Of those, 23 are rated Critical and 17 require no user interaction (UI:N).

A customer could first answer the shared environment question, "Which users, applications, and workstations process untrusted documents or mail?" The customer could then use the attributes of each CVE, including severity and user-interaction requirements, to decide which vulnerabilities need the most immediate attention. This preserves CVE-specific analysis without repeating the same environment assessment for every vulnerability. 

Microsoft is sharing the risk cohort concept to support a broader customer and industry discussion about making vulnerability analysis more manageable. At this stage, the approach is exploratory. The cohorts in this post are provisional, so the Security Update Guide does not currently display these relationships.

We are not announcing a new Microsoft vulnerability classification or prioritization framework, and we are not committing to a specific product integration or publication model. Customer feedback on the usefulness, clarity, and limitations of the approach will help inform whether and how the concept develops. 

• These cohorts are provisional customer-risk groupings. They are not final or formally approved Primary/Related CVE relationships.
• A cohort does not mean that one update, workaround, or mitigation addresses every CVE in the group.
• Some of the broader groups may be divided further if a single assessment hides meaningful differences.
• The Security Update Guide (SUG) does not currently display these relationships. We are sharing the concept now so customers can consider how it fits into their own processes.

Customers who analyze security updates can consider testing this approach within their existing vulnerability management process:

1.      Identify groups of CVEs that lead to the same deployment, exposure, or trust-boundary question.

2.      Answer the shared environment question once and document the result.

3.      Use that context as a starting point when reviewing each CVE in the group.

4.      Continue to prioritize individual vulnerabilities based on active exploitation, severity, attack vector, required privileges, user interaction, and product-specific guidance.

5.      Assess whether the approach reduces repetitive analysis without hiding important exceptions.

Cohorts do not replace careful review of high-severity or actively exploited vulnerabilities. They can reduce repeated analysis in large releases and help teams spend more time on the exceptions. As AI-assisted research contributes to vulnerability discovery, this kind of approach may become more useful.

We would appreciate your feedback on whether risk cohorts would help support your vulnerability assessment and risk management processes. You can send your feedback to CVE@microsoft.com.