Exploited in Three Days, Patched in a Month: Limit What the Flaw Inherits

What Microsoft Measured About Patch Timing

On 2 November, Microsoft Security Research published its analysis of the vulnerabilities attackers actually use. Roughly 0.5% of published flaws are ever exploited, so most of the patch queue never matters. The ones that do matter are mostly takeover flaws: remote code execution, authentication bypass and local privilege escalation make up 78% of the exploited flaws Microsoft counted.

Those flaws move fast. Microsoft reports that in 2026 data through September, the median time from a flaw's publication to its addition to CISA's list of known exploited vulnerabilities was three days, and the 2026 mean was 20 days, down from 89 days in 2024. Patching moves slowly by comparison. In Microsoft's own exposure data, the median flaw is patched in about two weeks on Windows workstations and in more than a month on Windows servers. Linux servers and macOS applications take more than 10 weeks, and network appliances take more than a year.

The comparison has a limit. The three-day median covers only the small share of flaws that get exploited, so it describes the flaws that hurt, not the average one. For those, a month to patch a server is a month of exposure.

Why the Server Is Where the Damage Comes From

Microsoft notes that servers often use service accounts, application identities or cloud-managed identities with permissions beyond their operational needs, so one compromise can expose administrative privileges. For an MSP, that is the part to act on. A service that runs under a domain account has that account's password stored on the machine so Windows can start the service. If the account is also a domain admin, or the same password is used on the client's other servers, one server takeover reaches all of them.

Microsoft's advice is to patch takeover flaws on exposed, high-privilege assets first, and also to break attack paths to privileged identities before compromise spreads. It adds that patching remains essential but is not the only defensive action available. The steps below are the second half of that advice.

Six Steps to Run Before the Next Patch Cycle

Patch Tuesday is 10 November. These steps take an afternoon per client for the first pass.

Rank servers the way Microsoft ranks flaws. Start with servers that are reachable from outside and that hold the most privilege: domain controllers, identity servers, remote access and backup servers. Patch takeover flaws there first.
List what each server can use. For every server, record the local administrators, the accounts its services and scheduled tasks run under, and any domain admin that has signed in. This is the list an attacker inherits.
Remove standing administrator rights from servers. A technician who needs admin on a server for an hour should have an account that exists for that hour. Take domain admin out of any service account that doesn't need it.
Rotate service account passwords, in the right order. Patch or rebuild the server first, because a rotation on a compromised server hands the new password to the attacker. Then rotate, and make each password unique per account. 5 Ways to Rotate Active Directory Service Account Passwords covers the options, including managed service accounts where the application supports them.
Write down what you will do for anything you can't patch. A network appliance that takes a year to patch needs a compensating control now: restrict who can reach it, and make sure nothing it stores is a standing credential.
Alert on changes to privileged groups. An attacker who lands on a server will try to add an account to an admin group. Knowing within minutes turns a quiet takeover into an incident you can contain.

What This Does and Doesn't Fix

None of this stops the exploit. An attacker who takes a server can still read what is on that server, and patching stays the first defense. What the steps change is the distance between one server and the rest of the client: a flaw that lands on a server with no standing admin and rotated service account passwords reaches that server and stops there.

How Panthera Fits Into These Steps

Panthera, CyberQP's privileged access management platform, covers steps two through four for the accounts it can see. Its discovery finds privileged identities across Active Directory, Entra ID, local Windows and Google Workspace, including service accounts and local admins, so the list in step two exists before an attacker reads it. From the same view you can review a system's local administrators and remove the ones that shouldn't be there. Technicians then work from just-in-time accounts that are disabled until a task and can be single-use, deleted after the work is done, including on servers. Admin passwords rotate on a schedule or on demand into a zero-knowledge vault, and privileged account auditing alerts are available.

Service account rotation is partly built today. Panthera rotates the password on a schedule or on demand, but updating every service and scheduled task that depends on the account is not complete, so test a service account rotation on a low-risk server first. Panthera doesn't patch servers or see inside the appliances you can't patch.

To see which standing admin and service accounts exist on one client's servers, start a free trial and connect it.