Microsoft risk cohorts: prioritising October security updates

On 13 October, MSRC introduced risk cohorts: groups of CVEs requiring similar questions about deployment, exposure and privilege boundaries. The groups are provisional; they change neither update guidance nor the need to assess individual CVEs. Source: Microsoft’s risk cohort announcement.

Breachroad’s conclusion: IT teams can use the idea to organise knowledge of their environment, while a patch decision should still identify specific vulnerabilities, assets and required action. The workflow below is our recommendation for administrators, service owners and security teams.

Start with a verifiable answer

We suggest preparing short descriptions of key services and device groups. Each should have an owner, confirmation date and evidence of the actual configuration. Saying that a feature is unused becomes useful when the scope and systems examined are clear.

Distinguish declared state, confirmed state and missing information. In our assessment, keeping those three values is more useful than forcing a yes or no answer from incomplete inventory. Give missing information an accountable owner and a completion date.

Same application, different workstations

Consider a company with a purchasing team, designers and a spare computer. All groups have the same office application but differ in how they work and manage updates. This is a hypothetical training scenario, rather than data from Microsoft’s report.

Purchasing handles documents from external suppliers. Designers have additional extensions. The spare computer rarely connects to corporate management systems. A general answer about the application does not yet describe those differences.

Our recommendation is to record the shared deployment information and identify exceptions requiring separate verification. The application owner should understand the input data scope, while the administrator confirms versions and updates. Both answers should be visible when deciding on action.

Turn environment context into an update task

We suggest attaching four concrete findings to the task:

1. Scope. Identify the vulnerabilities, assets and components covered by the decision. A risk group name alone is insufficient as a task identifier.
2. Priority evidence. Record vendor information about exploitation and conditions relevant to your deployment. Distinguish confirmed evidence from assumptions.
3. Owner and deadline. Establish who performs the change, who approves an exception and when reassessment happens. A user or application availability constraint should have a visible resolution path.
4. Outcome evidence. Define how you will confirm the running version, completion of required stages and availability of necessary functions.

This is our suggested decision record. It explains why two systems received different deadlines without requiring someone to reconstruct the reasoning from chat conversations.

Keep exceptions visible

MSRC notes that a shared cohort does not mean one patch or mitigation addresses every CVE in it. The concept remains exploratory, and the Security Update Guide does not currently display these relationships. Those limitations come from the source above.

In our plan, each separate decision retains its rationale and a reference to current vendor information. If new exploitation evidence, changed exposure or a revised assessment appears, revisit the relevant tasks. Classifying devices earlier does not close that review.

Check whether the workflow helps

We recommend assessing a small, clearly defined scope before applying the method across the entire register. Determine whether the environment description actually reduces evidence collection work and whether decision makers still see important differences between tasks.

During review, ask about missing evidence, delayed exceptions and outdated configuration descriptions. This assesses decision quality, rather than only counting records closed after sending an update package.

In training, participants can compare fictional workstations and explain which findings apply jointly and which need further verification. The exercise requires neither real vulnerable systems nor offensive testing.

For broader context, read our guide to vulnerability management. IT teams and service owners can practise these decisions in our cybersecurity training for organisations.