Zero-day and patch management -
a 24-hour plan

When Microsoft ships a patch for a critical zero-day in Windows (e.g., CVSS 9.8), some companies react in hours, others wait weeks or months. The difference is not luck - it is preparation. In this article I break down zero-day vs known CVE, explain CVSS scoring, show a 5-step action plan for 24 hours, and describe how ManageEngine Endpoint Central supports this process.

Zero-day vs known CVE - what is the difference?

The term zero-day comes from the days when people counted days from a vulnerability's discovery to the appearance of an exploit - the vendor had "zero" days to prepare a patch. Today zero-day means a vulnerability the vendor does not know about, or knows about but does not yet have a public patch for.

Known CVE is a vulnerability cataloged in the NIST database, with an assigned CVE ID (e.g., CVE-2025-1234), a CVSS score, and an available patch. Most known CVEs exist in the database for a few days to a few weeks before an exploit appears.

This is a key distinction:

• Zero-day: no patch, no vendor knowledge, the attacker has a significant advantage, defense = mitigation (network isolation, WAF, segmentation)
• Known CVE: a patch is available, public knowledge, attackers will try before you patch, defense = fast patching + scanning

CVSS scoring - how to read severity

CVSS (Common Vulnerability Scoring System) is an open, international vulnerability scoring standard on a 0-10 scale, maintained by FIRST. The US NVD database (run by NIST) assigns CVSS scores to known CVEs, which lets you assess their relative severity.

How to read CVSS (per CVSS v3 thresholds):

• 0.0-3.9 (Low): minimal risk, usually requires physical access or specific conditions - update in the current cycle (e.g., monthly)
• 4.0-6.9 (Medium): moderate risk, often requires authentication or special conditions - update on a shorter horizon
• 7.0-8.9 (High): high risk, possible remote access or remote code execution - update within a few days
• 9.0-10.0 (Critical): critical risk, e.g., remote takeover without authentication - update as fast as possible, in emergency mode

Specific time thresholds (how many days to patch for a given level) are defined by each organization in its policy - this is a risk-based approach, in line with the spirit of NIST SP 800-40. The values in this article are indicative.

The CVSS score alone is not everything - in prioritization it is also worth considering whether an actively exploited exploit exists for the vulnerability (e.g., whether the flaw is in the CISA KEV catalog) and how critical the affected system is in your infrastructure.

24-hour action plan (5 steps)

When a vulnerability with CVSS 9+ appears, the procedure must start immediately:

• Step 1: Identification (H+0h to H+2h)

  Your monitor (NIST NVD, vendor advisory) gets an alert about a vulnerability. Check: does it affect us (OS/application)? What CVSS? Is a patch available? Trigger: CVSS 9+ = activate the full team.

• Step 2: Impact assessment (H+2h to H+4h)

  How many systems/machines are affected? Check the inventory (CMDB in ManageEngine) - OS versions, applications, vulnerability scan. Prioritization: critical (production) vs non-critical.

• Step 3: Action plan (H+4h to H+8h)

  Is a patch available? Does it require a restart? Are there known compatibility issues? Establish a patching window (night/weekend is better, but for CVSS 9+ you can act live). Rollback plan (VM snapshot, backup, fallback patch).

• Step 4: Pilot (H+8h to H+20h)

  Patch the TEST environment (2-3 machines, representative configurations). Test functionality, applications, network. No regression = approval for rollout.

• Step 5: Full deployment (H+20h to H+24h)

  Staged rollout: 10% to 50% to 100% of machines. Monitoring (CPU, memory, network, error logs). Be ready to roll back at any stage.

CVSS and patching windows - how much time to react?

The table below is an example, risk-based policy - the time values are indicative and do not come from a specific, mandated deadline in NIST or NIS2. Each organization should set its own thresholds based on risk and system criticality.

Patch management automation in ManageEngine Endpoint Central

Manual patch management at the scale of 50-500 machines is chaos. ManageEngine Endpoint Central automates the whole thing:

• Automatic vulnerability scanning: every 24 hours, scan all machines for missing patches and known exploits
• CVSS-based prioritization: the system automatically prioritizes patches based on CVSS and business impact
• Staged deployment: rolling out the patch in waves (10% to 50% to 100%) with monitoring at each stage
• Fallback policy: if X% of machines fail after a patch, automatically roll back on the rest
• Compliance reporting: a report showing which machines are patched, which are missing patches, and when a patch is required (for NIS2/ISO 27001 audits)

A typical ManageEngine workflow:

1. CVE-2025-99999 (CVSS 9.5) appears for Windows 10
2. ManageEngine pulls the patch from WSUS/Windows Update - CVSS 9.5 triggers a CRITICAL alert
3. The system checks inventory - 120 Windows 10 machines are vulnerable
4. It creates a Change ticket (automatically assigned to Security Manager)
5. Rollout: pilot (5 machines) > monitor 2 hours > staging (60 machines) > monitor 4 hours > full deployment (55 machines)
6. Compliance report: 120/120 patched. Time to patch: 12 hours

Best practices - staged deployment and rollback

Never patch everything at once. Even if the patch comes from Microsoft and you tested it for 3 days, there is always a risk of negative interaction with a locally customized system.

Staged deployment pattern:

• Wave 1 (5-10% of machines, T+2h after the patch): representative machines (mix of configurations), critical applications disabled during testing
• Monitor Wave 1 (2-4 hours): error logs, CPU/memory, network, user reports
• Wave 2 (50% of machines, T+6h): if Wave 1 is OK, expand to 50%
• Monitor Wave 2 (4 hours): escalation path ready
• Wave 3 (100% of machines, T+12h): final rollout

Rollback procedure (always required):

• VM snapshot before the patch (on-premise) or image backup (cloud)
• Known good configuration in the repository (we use the SDP artifact repository)
• Communication plan: who powers off the machine, who waits for rollback, which systems are touched
• Test rollback once a quarter (do not wait for an emergency to test the procedure)

Frequently asked questions (FAQ)