Skip to main content
Change Risk Intel

Patch Tuesday: What It Is and How to Plan Around It

The Change Risk Intel Desk · 15 min read

Why this matters right now

Every organization running Windows, Exchange, Office, .NET, or Azure services inherits Microsoft’s release calendar whether or not it has a formal patch management program. Microsoft confirms security updates are scheduled for “the second Tuesday of each month at 10:00 AM PST” and explicitly tells IT teams to plan deployment schedules around it (Microsoft Security Update Guide FAQ). A single month’s release can carry dozens of CVEs across products your CAB has never inventoried by patch source, and a missed critical fix sits exposed for a full month until the next cycle — or longer if the vulnerability isn’t triaged at all. When an out-of-band release breaks that rhythm, as happened with the PrintNightmare Windows Print Spooler vulnerability in July 2021, the calendar-based plan has to give way to same-week emergency change, and teams without a pre-agreed emergency process lose days scrambling to convene approvers (Microsoft MSRC blog).

What is the history and cadence of Patch Tuesday?

Microsoft consolidated its security releases into a predictable monthly cadence in the early 2000s, moving away from ad hoc bulletin releases as the volume of reported vulnerabilities grew. The mechanism has stayed remarkably stable since: releases land on the second Tuesday of each month at 10:00 AM Pacific Time, and Microsoft explicitly advises IT pros to “plan their deployment schedules accordingly” based on their own time zone offset from Pacific (Microsoft Security Update Guide FAQ). That single sentence is the reason Patch Tuesday exists as an operational concept rather than just a vulnerability disclosure event — Microsoft designed it as a schedule, not a surprise.

Not every Microsoft release follows this exact rhythm. Non-security quality updates for some products have shipped on a first-Tuesday cadence in the past, and Microsoft has periodically adjusted release mechanics for individual product lines, so the FAQ page is worth rechecking each year rather than assumed static (Microsoft Security Update Guide FAQ). The core security release, though, has anchored to the second Tuesday for two decades, which is why change advisory boards can build a recurring calendar item around it with confidence.

What does Microsoft actually ship on Patch Tuesday?

Patch Tuesday isn’t a single patch — it’s a coordinated wave of releases across Microsoft’s product surface, published through the Security Update Guide portal rather than the old-style bulletin emails Microsoft retired around 2017 (Microsoft Learn archive). In a typical month, the release includes:

  • Windows cumulative updates for all supported client and server versions, bundling security fixes with reliability improvements into a single rollup rather than separate patches.
  • Microsoft Exchange Server security updates, which regularly carry some of the highest-severity CVEs of any product line because Exchange is both internet-facing and holds credential material.
  • Office and Microsoft 365 Apps updates, split between Click-to-Run channel releases and MSI-based deployments depending on how an organization licenses Office.
  • .NET Framework and .NET security updates, which affect any custom line-of-business application built on the runtime, not just Microsoft products.
  • Azure and cloud service updates, which are typically auto-applied by Microsoft to the service itself but still get documented in the Update Guide for compliance and audit trail purposes.

Every one of these releases gets a corresponding entry in the Security Update Guide at msrc.microsoft.com, which is the canonical source of truth for what shipped, what CVE it addresses, and what the exploitability assessment looks like (MSRC).

How do you read the MSRC Security Update Guide?

The Security Update Guide replaced Microsoft’s older static security bulletins in 2017 specifically so the data could be queried, filtered, and exported rather than read as a monolithic PDF (Microsoft Learn archive). For a change manager triaging a release, the practical workflow is:

  1. Go to the Update Guide portal and filter by release date to isolate the current month’s Patch Tuesday batch.
  2. Sort by CVSS base score and exploitability assessment (Microsoft tags each CVE with whether exploitation has been detected or is “more likely”/“less likely”) to prioritize which cumulative updates get expedited into a pilot ring first.
  3. Cross-reference affected product and version against your CMDB, not against Microsoft’s generic product family name — a single CVE entry can list a dozen individual product/version combinations, and only some may be in your estate.
  4. Export the filtered result set — Microsoft has supported a downloadable spreadsheet/CSV view of the Update Guide data specifically so this step doesn’t require manual transcription (Microsoft Learn archive).
  5. Log the KB article number tied to each CVE — deployment tooling (WSUS, Intune, SCCM) references KB numbers, not CVE IDs, so this is the field your change ticket actually needs.

Treat the Update Guide as the primary source, and use secondary vulnerability-management vendor writeups (Qualys, Tenable, Rapid7) only for prioritization color — never as the record of what Microsoft shipped.

What is the full 2026 Patch Tuesday schedule?

Patch Tuesday always falls on the second Tuesday of the month, so the full-year calendar can be computed and verified independently of any single vendor’s blog post. The table below lists all twelve 2026 dates, consistent with Microsoft’s stated cadence (Microsoft Security Update Guide FAQ):

Month2026 Patch Tuesday date
JanuaryJanuary 13
FebruaryFebruary 10
MarchMarch 10
AprilApril 14
MayMay 12
JuneJune 9
JulyJuly 14
AugustAugust 11
SeptemberSeptember 8
OctoberOctober 13
NovemberNovember 10
DecemberDecember 8

Bookmark our Patch Tuesday calendar tool rather than re-deriving this table manually every January — it also flags out-of-band releases as they’re announced, which a static calendar can’t do.

What happens when Microsoft ships out-of-band, off the normal calendar?

Patch Tuesday is a planning anchor, not a guarantee that nothing else ships that month. Microsoft has issued emergency out-of-band releases multiple times when active exploitation or public disclosure made waiting for the next scheduled Tuesday untenable.

The clearest recent example is PrintNightmare (CVE-2021-34527). Microsoft’s June 2021 Patch Tuesday had already addressed a related Print Spooler CVE, but a second, more severe remote-code-execution flaw in the same component was published days later. Microsoft responded with out-of-band updates on July 6 and July 7, 2021 — outside the normal monthly window — covering essentially every supported Windows version at the time, and published follow-up guidance clarifying mitigation steps as the situation evolved (Microsoft MSRC blog).

Log4Shell (CVE-2021-44228) is a different kind of out-of-band event: the vulnerable component, Apache Log4j, isn’t a Microsoft product, but the vulnerability’s blast radius was large enough that Microsoft published emergency detection and hunting guidance for its own security tooling within days of public disclosure in December 2021, rather than waiting to fold guidance into the next Patch Tuesday cycle (Microsoft Security Blog). Microsoft’s Defender Vulnerability Management team has kept that guidance updated well past the original incident, underscoring that out-of-band response isn’t a one-time announcement — it’s an ongoing thread a CAB needs to track separately from the monthly cadence (Microsoft Learn).

The operational lesson for a CAB is the same in both cases: your change calendar needs an emergency lane that bypasses the standard T+2/T+7/T+14 timeline entirely, with pre-authorized approvers who don’t need to wait for the next scheduled CAB session. If your emergency change process only exists on paper, an out-of-band week is where that gap gets found the hard way. For a structured way to score urgency the moment a CVE lands, see how to read a CISA KEV entry — CISA’s Known Exploited Vulnerabilities catalog is often the fastest independent confirmation that a given CVE deserves out-of-band treatment rather than the standard cycle.

How do you coordinate Patch Tuesday with your CAB calendar?

The value of a fixed monthly release date is that a CAB can build a recurring rhythm around it instead of reacting fresh each month. A timeline that works for most mid-market and enterprise environments looks like this, measured from the Patch Tuesday release date (T+0):

  • T+0 (release day): Pull the current month’s data from the Security Update Guide, triage by CVSS score and exploitability, and flag anything that maps to a KEV entry for expedited handling.
  • T+2: Change tickets for all in-scope KB articles are drafted and sitting in your ITSM tool as “draft” status, with rollback plans attached, ready for CAB review — not yet approved for production.
  • T+7: Deployment to the pilot ring (a representative but non-critical subset of endpoints/servers) is complete, and telemetry from that ring — crash reports, performance regressions, application compatibility issues — is being reviewed.
  • T+14: Assuming the pilot ring is clean, broad production rollout completes. This two-week buffer is deliberately long enough to catch the update-quality issues that occasionally accompany cumulative Windows updates, without leaving known CVEs unpatched for a full additional month.

This timeline assumes no KEV-listed or actively-exploited CVE in the batch; if one is present, compress the schedule and route it through your emergency change lane instead, following the CISA KEV guidance linked above. If your CAB doesn’t yet have a documented recurring agenda item for this, our guide on how to run a CAB meeting in 2026 covers where a monthly patch review slots into a standing agenda without turning every session into an ad hoc vulnerability briefing.

Do other vendors release on a Patch Tuesday-adjacent schedule?

Microsoft isn’t the only vendor whose release calendar a CAB needs on the wall. Two other vendors matter enough to most enterprise estates to warrant their own calendar entries:

Adobe has historically released security bulletins on the same second Tuesday as Microsoft, covering Acrobat, Reader, ColdFusion, Experience Manager, and its Creative Cloud desktop applications (helpx.adobe.com/security). As of July 14, 2026, Adobe moved to a twice-monthly cadence — publishing on both the second and fourth Tuesday of each month — citing AI-accelerated vulnerability discovery that was compressing the gap between disclosure and exploitation (CSO Online). Any change calendar built around a single monthly Adobe entry needs to be updated to reflect two Adobe release windows per month going forward.

Oracle runs on a slower, quarterly cadence: Critical Patch Updates ship on the third Tuesday of January, April, July, and October (Oracle Security Alerts). Oracle also introduced monthly Critical Security Patch Updates (CSPUs) starting May 28, 2026, aligned to the third Tuesday of the months that fall between quarterly CPU releases, effectively giving Oracle-heavy environments a monthly patch touchpoint alongside the existing quarterly one (Oracle Security blog). If your estate runs Oracle Database, WebLogic, or E-Business Suite, that third-Tuesday rhythm belongs on the same shared calendar as Microsoft’s and Adobe’s release dates — treat all three as inputs to one change calendar, not three separate trackers.

What to do about it

A Patch Tuesday process that only exists in someone’s head doesn’t survive that person’s vacation. Build it as a written, repeatable procedure:

  1. Put all three vendor calendars — Microsoft, Adobe, and Oracle — on one shared calendar, not three separate ones your patching, application, and database teams each track independently.
  2. Pre-authorize an emergency change lane with named approvers who can act same-day, so an out-of-band release like PrintNightmare doesn’t wait for your next scheduled CAB session.
  3. Standardize the T+0/T+2/T+7/T+14 timeline as your default, and require an explicit justification any time a team wants to deviate from it in either direction.
  4. Cross-reference every Patch Tuesday CVE batch against CISA’s KEV catalog the same day it’s released — see how to read a CISA KEV entry for the specific fields to check first.
  5. Maintain a pilot ring that’s actually representative of your production fleet’s OS versions, hardware, and installed application mix — a pilot ring of five identical VMs catches nothing a diverse production estate will hit.
  6. Log the KB number, not just the CVE ID, on every change ticket — your deployment tooling and your auditors both need the KB reference to trace what was actually installed.
  7. Review your 12 external risk sources monthly, not just on Patch Tuesday — vendor advisories, KEV updates, and vulnerability intel don’t wait for the second Tuesday, and our guide to the external sources every CAB should monitor lays out a monitoring cadence that fills the gaps between patch cycles.
  8. Score each batch’s aggregate risk before scheduling, using a consistent method — our Change Risk Score tool gives CABs a repeatable number to attach to the change ticket rather than a subjective “high/medium/low” label that varies reviewer to reviewer.

Frequently asked questions

What time does Patch Tuesday actually release?

Microsoft targets 10:00 AM Pacific Time on the second Tuesday of each month for the Security Update Guide release (Microsoft Security Update Guide FAQ). Convert to your local time zone and build your team’s monitoring window around that, since Microsoft does not publish a separate localized release time.

Does every Microsoft product follow the Patch Tuesday schedule?

No. Microsoft’s own FAQ notes that “some products do not follow the Patch Tuesday schedule” (Microsoft Security Update Guide FAQ), and some non-security quality updates have historically shipped on a first-Tuesday cadence for specific product lines. Always confirm cadence per product rather than assuming uniform timing.

What’s the difference between Patch Tuesday and an out-of-band release?

Patch Tuesday is the scheduled, predictable monthly release. An out-of-band release is an emergency patch issued outside that schedule, typically because a vulnerability is being actively exploited or was publicly disclosed with enough detail that waiting for the next monthly cycle is judged too risky — as happened with PrintNightmare in July 2021 (Microsoft MSRC blog).

Where do I find the authoritative list of what Microsoft patched this month?

The Security Update Guide at msrc.microsoft.com/update-guide is the canonical, queryable source. It replaced static bulletin pages in 2017 specifically to support filtering, sorting, and export (Microsoft Learn archive).

How long should we wait before deploying a Patch Tuesday update to production?

A T+14 broad-deployment target from release day is a reasonable default for most environments, giving a pilot ring roughly a week to surface compatibility or stability regressions before wider rollout. Compress this timeline for any CVE that appears in CISA’s KEV catalog or carries a Microsoft exploitability assessment of “exploitation detected.”

Does Adobe’s new twice-monthly schedule replace its second-Tuesday release?

No — Adobe kept its existing second-Tuesday release and added a second one on the fourth Tuesday, effective July 14, 2026, rather than replacing the original slot (CSO Online). Change calendars need to reflect two Adobe release dates per month going forward, not one.

Is Oracle’s patch cadence the same as Microsoft’s?

No. Oracle’s primary Critical Patch Update ships quarterly, on the third Tuesday of January, April, July, and October (Oracle Security Alerts). Oracle supplements this with monthly Critical Security Patch Updates on the third Tuesday of the intervening months, starting May 28, 2026 (Oracle Security blog).

Should out-of-band patches skip our normal CAB approval process?

No — they should route through a pre-defined emergency change process with expedited but still documented approval, not skip governance entirely. The goal is speed without losing the audit trail your SOX or SOC 2 controls require; see our SOC 2 change management controls guide for how auditors expect emergency changes to be evidenced.

Sources

Published July 21, 2026.