Skip to main content

Let’s talk about patch scheduling

  • February 26, 2026
  • 3 replies
  • 24 views
FerrisBNA
Forum|alt.badge.img+1

Hello all you IT Rockstars!

 

I’d like to get some of your thoughts on Patch Scheduling.  Since there are so many tools available to use with Jamf Pro, it really gives us a wealth of options for customizing.

 

What and When:

The way I look at things, there are 3 basic categories of patching urgency on macOS.

Feature:           Non-Security OS Patches, New macOS versions, and specific software that is a deliberate manual rollout.  Example: corporate VPN software.  This is something that we would want uniform version across the fleet.  These are planned and don’t have a standard cadence.

Critical:           Security OS Patches, Zero-day patches, and other applications that the security issue addressed by the patch is important to your organization.  I am thinking of having these install once a week, short deferral period, force update within 24 hours.

Routine:          Basically, all other application patches.  I am torn between doing these on a weekly basis with the critical patches, or draw that out to a monthly cadence.

 

What to patch and what NOT to patch:

Some applications can be patched with Jamf but also have their own auto-update features. 

For some like AV software, and security agents, I suggest just letting those update using their own built-in updater.  I just keep an eye on the versions in the environment so that I catch if the updater breaks on any devices, it can be addressed quickly.

I am “on the fence” a letting applications like Chrome/Edge/Firefox auto update.  The only reason is that I don’t want the end-user to be bombarded with too much update activity/notifications.

 

What time to apply patches:

This used to be so easy when everyone had desktops that were powered on in the office 24/7.

The Application patching is the tricky one.  I want to limit the amount of patching that is visible to the end-user, and also not utilize too many resources when the user is on a Zoom/Teams/WebEx/Meet meeting.  I haven’t gotten a script to check for active meetings of these apps to work.

How visible do you want patching to be?

My thinking is to do as much application patching possible silently.  The only end-user notifications being if an application needs to be closed before installing the patch.

For OS patching, I think just the opposite.  I’ll pre-cache the updates silently but have a clear notification that the OS needs to be patched, how long that will take, what to expect, and how long you can defer the update.

 

-Pat

-Pat

3 replies

AJPinto
Forum|alt.badge.img+26
  • AJPinto
  • Legendary Contributor
  • February 26, 2026

Most macOS updates, and most modern application updates, include security fixes. Even when Apple labels something as a feature release, the delta almost always contains CVE remediation. Because of that, it’s safest to treat nearly all updates as security‑relevant and deploy them as quickly as your environment can tolerate.

 

Auto‑update behavior

If an application has a reliable auto‑update mechanism, enabling it with the shortest reasonable delay significantly reduces exposure. Browsers are a good example: Chrome, Edge, and Firefox routinely ship updates that address dozens of CVEs at once. Delaying those updates increases risk without providing meaningful operational benefit.

Developer tools are a special case, but even there, frequent updates matter. Outdated toolchains and runtimes can introduce vulnerabilities into the software your teams are building.

macOS update cadence

There is no such thing as a feature‑only macOS update. Apple ships deltas that bundle security fixes with everything else. A practical target is to deploy macOS updates within about seven days of release, assuming no vendor blockers. If a vendor blocker exists, you still need a risk assessment to determine whether the greater risk is breaking the vendor tool or leaving the CVEs unpatched.

High‑risk applications

Browsers, Office, collaboration tools, and anything that processes untrusted content should be patched within 24 hours when possible. These applications are common attack vectors, and their updates almost always include security fixes.

Lower‑risk applications

For tools that don’t interact with untrusted data and don’t expose meaningful attack surface, a 30–90 day cadence is usually acceptable depending on business need and risk tolerance.

Zero‑day updates

Zero‑day patches are less common, but when they appear, they should be deployed immediately. CAB, change control, and user notifications come after. The only discussion that should happen before deployment is a quick risk assessment, because not every zero‑day applies to every environment and some organizations already have mitigating controls in place that reduce the effective risk.

Testing and validation

None of this replaces CI/CD practices or regression testing. Every update that can reasonably be tested should go through validation, and full‑stack reviews should be performed on a regular cadence, typically quarterly. This is where most of an engineer’s time and focus should be spent. The goal is to ensure that rapid patching does not introduce instability, while still maintaining an aggressive security posture.

Chubs
Forum|alt.badge.img+23
  • Chubs
  • Jamf Heroes
  • February 26, 2026

What we have and what works well for us is having update rings that mirror our Windows environment for OS patching.  We leverage declarative updates for this and allow Apple to be the “bad guys” when it comes to forcing users to update.  

Ring 1: N day release install
Ring 2: 7 day release install
Ring 3: 30 day release install

For apps, we force the auto update feature set on everything that we can.  For those users that ignore those update prompts, we use a 30 day cycle of forcing the app to update via the Jamf App Catalog.

Ideally, the app updater catches 98% of the patches while jamf catches the other 2%.  Really wish we could version in the jamf app catalog and have more control over notifications, but at this point it is what it is.

Our compliance level has never been higher.

**We like using native tooling as we do not have to rely on community projects or open source things - meaning if something is pushed and breaks, it doesn’t stop our workflow.  No scripts to run, no additional tooling needed - just nativeness doing its own thing.

Jarred

I find your lack of faith disturbing
pete_c
Forum|alt.badge.img+16
  • pete_c
  • Honored Contributor
  • February 26, 2026

Setting Google Chrome to auto-update using its own built-in mechanism has been a tremendous improvement in my fleet’s vulnerability and compliance scores.  No complaints from end users and easily set via profile.

If/when I have to move to Edge, I fully intend to use the same approach (no surprise as they’re both just Chromium).

 

https://chromeenterprise.google/policies/#RelaunchNotification

    Terms & ConditionsCookie settingsAccessibility statement