What patching looks like when you support the whole mess: endpoints, M365, identity, browsers, VPN, and line-of-business tools

Monday morning at one shop. Windows laptops across the sales floor. A handful of Macs the design team brought in. An M365 tenant that Microsoft updates on its own schedule. Entra ID handling authentication and conditional access. Three browsers with three different extension policies. A Fortinet VPN appliance that’s quietly sitting on a firmware version from last quarter. Dynamics for the ERP side. Two line-of-business SaaS apps the COO bought without telling IT. That’s one shop, one week.

Most people hear “patching” and picture Windows Update. Download, restart, done. That model stopped being accurate about a decade ago, but a surprising amount of security-team workflow still assumes that’s the whole surface. It’s maybe 30% of it.

The rest of the surface is scattered across products that patch on different schedules, through different mechanisms, with different risk profiles. Here’s what the full picture actually looks like.

Endpoints

This is the part everyone thinks about. Windows laptops, Windows servers, the occasional Mac that came in through a BYOD exception or a department that bought their own hardware.

The Windows side is manageable if you have Intune or SCCM and a ring-based deployment model. Push to a pilot group, wait 48 hours, check for breakage, then widen the ring. The hard part isn’t the tooling. It’s the exceptions: the laptop that hasn’t checked in for three weeks because the sales rep is traveling, the legacy server running a LOB app that panics if you update .NET, the BYOD Mac that technically isn’t domain-joined but definitely has company email on it.

Endpoint patching is the one surface where the tooling is mature. The gap is coverage, not capability. You know how to push the patch. The question is whether every device is actually receiving it.

M365 cloud

You don’t patch M365. Microsoft does, on their schedule, and you react.

That sounds easier, and in one sense it is. You’re not deploying anything. But Microsoft rolls features and security changes into M365 updates without always flagging which changes are security-relevant. A “feature update” to Teams might include a fix for an OAuth scope vulnerability. A change to SharePoint Online permissions might silently close a path that an attacker was using.

The operator’s job here isn’t patching. It’s monitoring the Message Center, reading the changelog, and figuring out whether a change broke a workflow your users depend on. The risk model is different: you can’t control the timeline, and you can’t roll back. You’re reacting to what the vendor already did.

Identity

Entra ID, conditional access policies, OAuth app registrations, break-the-glass accounts. Identity is the surface where a configuration change is effectively a patch.

When Microsoft updates Entra’s conditional access engine, your policies might behave differently. When an OAuth scope gets deprecated, the app registration you approved six months ago might stop working, or worse, might silently gain broader access than you intended. Break-the-glass accounts need periodic credential rotation, and the audit trail needs to show that nobody used them since the last rotation.

Identity patching isn’t about deploying a binary. It’s about reviewing your configuration against the current state of the platform and confirming that the assumptions you made last quarter still hold.

Browsers

Chrome, Edge, and whatever Firefox holdout is still running in accounting.

Browser patches are frequent and usually automatic, which makes them feel low-risk. The hidden surface is extensions. A browser extension with broad permissions is functionally a piece of software running inside your user’s authenticated session. Chrome enterprise policies let you allowlist and blocklist extensions, but the allowlist needs maintenance. Extensions change ownership, get acquired by adtech companies, or quietly add permissions in a minor version bump.

The CVE surface for browsers themselves is well-covered by vendor auto-update. The CVE surface for the extension ecosystem is barely tracked at all. When a browser extension shows up on CISA KEV, most shops don’t have a fast path to remove it fleet-wide. That’s a gap worth knowing about before it matters.

Remote access

VPN appliances are quietly one of the biggest categories on CISA’s Known Exploited Vulnerabilities list. Fortinet, Palo Alto, Ivanti, Cisco: they’ve all had critical vulnerabilities in the past two years that were actively exploited before most shops patched.

The problem is structural. VPN appliances sit at the network edge, internet-facing by design. They’re the front door. And updating them usually requires a maintenance window because the update restarts the VPN service, which disconnects every remote user. So shops defer the update until the next scheduled window, and the next scheduled window is two weeks away, and by then the exploit has been public for a month.

Remote access patching has the highest ratio of “severity of the vulnerability” to “friction of deploying the fix.” The CVEs are critical. The deployment path is disruptive. That combination means VPN patches need their own triage lane, separate from the general endpoint cadence.

Line-of-business apps

The ERP system the company runs on. The industry-specific SaaS tool that finance uses for reporting. The legacy desktop app from a vendor who charges for major version upgrades and bundles security fixes into the paid release.

LOB apps patch on the vendor’s schedule, not yours. Some vendors ship security updates quarterly. Some ship them when they feel like it. Some bundle security fixes into feature releases and won’t tell you which bugs are security-relevant unless you ask.

The worst case is the pay-to-patch model: the vendor found a vulnerability, fixed it in version 8.0, and you’re on 7.2. The fix is available, but only if you buy the upgrade. Your options are pay, mitigate, or accept the risk. None of those are great.

What ties them together

A CVE is the ping. The operator’s job is knowing which of these six surfaces the CVE touches, in what version shape, with what blast radius, and through which deployment mechanism.

A single CVE for Chrome is an endpoint patch, a browser policy check, and possibly an extension audit. A single CVE for Entra ID is an identity review and a conditional access policy check. A single CVE for Fortinet is a VPN firmware update that requires a maintenance window and a heads-up to every remote worker.

The triage model doesn’t change. Patch now, patch later, or ignore for now. But the execution path is different for every surface, and the friction is different for every surface. Knowing which surface you’re dealing with is the first step in knowing how long the fix will actually take.

The honest risk split

Some of these surfaces you own. Endpoints, identity configuration, VPN appliances: you control the deployment timeline, you run the maintenance window, you eat the rollback if the patch breaks something. The risk is yours, and so is the agency to fix it.

Some of these surfaces you don’t own. M365, LOB SaaS, cloud platforms that patch on the vendor’s schedule. You can’t speed up the fix, and you can’t roll it back. The risk is yours, but the agency belongs to the vendor. CVEs on the “pray the vendor fixes it” surfaces produce a different triage than CVEs on the “you own it” surfaces. The action item might be “apply compensating controls” instead of “deploy the patch,” because there is no patch you can deploy.

Being honest about which surfaces you control and which you don’t changes how you respond to the next ticket. It’s the difference between an action plan and a monitoring plan.

The job is bigger than CVEs

PatchDay Alert filters CVEs worth triaging. That’s the daily digest. But the operator’s job has always been bigger than CVEs. It’s endpoint rings, identity reviews, browser extension audits, VPN firmware windows, and vendor release cycles. The six surfaces don’t all get a CVE when something goes wrong. Sometimes the risk is a configuration drift, a deprecated API scope, or a feature change that broke your workflow.

The blog exists because the rest of the job is also worth writing about. Not just which CVEs to patch today, but how the whole surface works, how the pieces fit together, and what happens when they don’t.