What Is Patch Tuesday? A Complete Guide

Microsoft gives organizations a predictable date for its main monthly security release, but the hard part begins after the updates arrive. Security and IT teams still need to determine which products are affected, which vulnerabilities matter most in their environment, how much testing is needed, which systems should move first, and whether deployment succeeded.

For teams asking, ‘what is Patch Tuesday’, it is Microsoft's recurring monthly security release, published on the second Tuesday of each month, typically at 10:00 a.m. Pacific Time. Microsoft calls the Windows package a monthly security update, and it is cumulative.

A complete operating process should cover release review, prioritization, testing, staged deployment, restarts, out-of-band fixes, hotpatching, failed installations, rollback, and verification. The release date gives teams a rhythm. The security value comes from how well those steps are executed.

What is Patch Tuesday in Microsoft's release model

Microsoft publishes the monthly Windows security update on the second Tuesday of each month. The company also refers to the release as Update Tuesday, a B week release, a quality update, a security update, or the latest cumulative update.

For Windows, the monthly package contains new security fixes, previously released fixes, and non-security changes carried forward from the previous optional preview release. Because the package is cumulative, administrators generally do not need to install every missed monthly package in sequence. Installing the latest applicable cumulative update brings a supported device to the current servicing level for that release branch.

The Microsoft security release can extend beyond Windows. September 2026 updates covered Windows, Windows Server, Office, SharePoint, Exchange, SQL Server, .NET, Visual Studio, Dynamics 365, and Azure. Microsoft also confirmed that two Windows vulnerabilities addressed that month had already been exploited before the fixes were published.

That broader scope is why Microsoft Patch Tuesday should be treated as a security operations event rather than a Windows-only maintenance task.

Why Patch Tuesday matters to IT and security

The fixed date gives organizations a repeatable point for security review and change planning.

Security teams can review newly published CVEs, exploitation status, affected products, and vendor information. Endpoint and infrastructure teams can map those releases to asset and software inventory. Application owners can prepare validation work. Change teams can reserve deployment windows and restart periods.

Microsoft said in May 2026 that monthly releases are growing as vulnerability reporting, automation, research participation, and software analysis increase the number of issues reaching its response process. Microsoft also advised customers to make deployment decisions using exposure and impact rather than raw vulnerability counts.

A fixed date therefore helps with planning, but the number of fixes should not decide priority on its own.

What Microsoft publishes during the monthly cycle

The Windows monthly security package includes both security and nonsecurity changes and is cumulative. Microsoft makes these updates available through Windows Update, Windows Server Update Services, the Microsoft Update Catalog, and enterprise update management products.

Several other release types sit around the same monthly cycle.

Microsoft documents those release types separately because they do not serve the same operational purpose.

Some Microsoft cloud services follow continuous update models instead of waiting for the monthly on-premises release.

Understanding what is Patch Tuesday therefore requires separating the monthly release from Microsoft's wider software maintenance activity.

Start with triage, not immediate deployment

The first task after release should be assessment.

Teams should identify which products and versions in their environment are affected. Then they should review exploitation evidence, severity, exploitability, asset role, network exposure, business impact, and available mitigations.

The September 2026 release shows why that order matters. Microsoft reported that CVE-2026-85880 and CVE-2026-81963 had been exploited before the monthly fixes were published. Both affected Windows and required faster attention than a routine issue with no evidence of exploitation.

Microsoft recommends using exposure and impact along with signals such as observed exploitation and public exploit status when deciding what to address first.

A practical response can place exploited vulnerabilities and highly exposed systems into an expedited path while lower-risk fixes move through the standard maintenance cycle.

Microsoft Patch Tuesday should feed a risk-based queue, not a simple list sorted by CVE count.

Test updates against representative systems

Testing should answer two questions. Does the update install correctly, and do the affected business functions continue to work?

Representative systems should cover common hardware models, business applications, VPN clients, identity components, endpoint security agents, drivers, and software that interacts closely with Windows. Server testing may also need service startup checks, database connectivity, cluster behavior, and application dependencies.

NIST's 2025 revision to SP 800-53 added and revised controls related to software update testing, deployment management, software integrity, validation, and root-cause analysis after update failures.

Testing time can be shortened when exploitation is active, but teams should still confirm installation and service health before broad deployment where operational conditions allow it.

Use staged rollout instead of one large deployment

A staged rollout limits how many systems are affected if an update causes a problem.

A small technical group can receive the update first. A broader pilot can follow after the first group behaves normally. Production groups can then move according to business impact and maintenance requirements.

Organizations are not tied to one deployment product. Windows updates can be managed through Windows Update, Windows Autopatch, Microsoft Intune, WSUS, Microsoft Configuration Manager, the Microsoft Update Catalog, or non-Microsoft tools. Microsoft lists those as valid enterprise update paths.

A Patch Tuesday workflow should work regardless of the management platform. Start with a representative group, observe results, expand deployment, and keep failed or unavailable devices in the workflow.

Out-of-band updates need a separate response path

Microsoft can release an out-of-band update when a recently identified problem cannot wait for the next monthly cycle. These updates are cumulative and can supersede the prior monthly security and optional preview packages for the same servicing branch.

September 2026 provides a recent example. After the September 8 security release, Microsoft documented Remote Desktop Services instability affecting several Windows versions. Out-of-band cumulative updates followed on September 14 to resolve the problem.

Teams that review Windows updates only once per month can miss an off-cycle correction.

The emergency path should already define who can approve the change, which systems receive it first, how much testing is required, and how failures will be handled.

Optional previews are not the same as security releases

Microsoft usually publishes optional nonsecurity preview updates on the fourth Tuesday of the month.

Those packages give administrators an opportunity to validate nonsecurity content before it appears in a later monthly security package. They can be useful for teams that want early compatibility testing, but they do not automatically carry the same urgency as a fix for a vulnerability under active exploitation.

The distinction matters when teams design approval policies. Monthly security releases, preview updates, feature updates, drivers, and out-of-band packages should not all move through the same timeline.

Feature updates need a different rollout plan

Windows feature updates follow an annual cadence and move devices to a newer Windows version. Microsoft currently releases them in the second half of the calendar year.

That is a larger change than the normal monthly cumulative package. Feature updates can affect application compatibility, drivers, hardware readiness, and support lifecycle dates, so they usually need a broader test group and a longer rollout.

Monthly security updates should remain on their recurring operational path. Feature updates should use a separate readiness and deployment plan.

Mixing the two creates avoidable confusion over urgency, compatibility testing, and rollback expectations.

Restarts need to be part of deployment planning

Some Windows security updates require a restart before the changed components take effect.

Endpoint policies can use deadlines, active hours, grace periods, and user notifications to prevent indefinite restart deferral. Servers may need maintenance windows, service sequencing, workload failover, or ordered restarts across clustered systems.

Eligible Windows environments can also use hotpatch updates. Microsoft's current model uses a baseline cumulative update that requires a restart, followed by eligible hotpatch months where supported devices can receive security-only updates without a normal restart.

Hotpatching changes restart frequency. It does not remove assessment, deployment monitoring, or verification.

Failed updates need a defined recovery path

A completed deployment job does not mean every system reached the intended state.

Some devices may have been offline. An update can fail. A restart can remain pending. A compatibility problem may require the rollout to stop.

Teams should separate installed, failed, pending, inactive, excluded, and not-applicable states. Failed systems need an owner and another action.

When a newly installed package causes a production problem, pause wider rollout first. Confirm the affected KB or package, review Windows release health information, and check whether Microsoft has published a known issue, replacement package, workaround, or recovery option.

The September 2026 Remote Desktop Services problem shows why that process matters. Microsoft documented the affected updates, published matching out-of-band corrections, and instructed administrators to install the relevant cumulative package for the affected operating system.

Rollback should be planned before it is needed. Removing a security update can reopen the vulnerability it corrected, so teams should weigh service availability against renewed exposure before uninstalling a package.

Verification should decide when the work is complete

Deployment status is only one part of closure.

Verification should confirm that the required build or package is installed, any required restart is complete, affected applications still function, and devices that missed the first deployment have returned to the workflow.

Where an update addresses an identified vulnerability, follow-up vulnerability assessment or version evidence can confirm that the vulnerable state is no longer present.

September 2026 also shows why monitoring after deployment matters. Microsoft documented Remote Desktop Services instability after that month's security update and published an out-of-band correction six days later.

Release-day deployment is therefore one checkpoint, not the end of the process.

Track metrics that show unresolved work

A monthly completion percentage can look healthy while important systems remain behind.

Useful measures include time from release to triage, time to pilot deployment, percentage of applicable systems verified within policy, failed installations, pending restarts, inactive devices, approved exceptions, and time to verified closure.

Expedited vulnerabilities should be reported separately from routine work. A high overall completion rate can hide slow action on the smaller number of flaws with known exploitation or high local exposure.

Trend data can also show whether a hardware model, server group, office, or application repeatedly delays deployment.

A mature program treats the second Tuesday as the start of a controlled workflow, not as a reminder to push every available update.

Teams review affected products, prioritize according to exploitation and business exposure, test representative systems, deploy in stages, monitor failures, plan restarts, watch for off-cycle releases, and verify the resulting software state.

Microsoft Patch Tuesday gives organizations a predictable rhythm. The value comes from connecting that release to asset context, risk, change control, deployment, and verification.

For anyone still asking what is Patch Tuesday, the answer is broader than Microsoft publishing fixes on the second Tuesday. It is a recurring decision point where security information becomes operational work.

A well-run Patch Tuesday process gives teams a repeatable monthly rhythm without forcing every update through the same timeline.