Inside Our Zero-Day Vulnerability Response Process

When Palo Alto Networks disclosed a critical buffer overflow in PAN-OS (CVE-2026-0300, CVSS 9.3), security researchers confirmed active exploitation within hours. Attackers had already built scanning tools to find vulnerable firewalls before most IT teams finished reading the advisory. We had every affected client environment patched within 12 hours of that disclosure.

Most business owners never see what happens during those 12 hours. You get an email saying a patch was applied, or maybe you hear nothing at all. This post walks through how our team actually responds when a critical zero-day drops, using real examples from recent vulnerabilities.

Hour Zero: The SOC Flags It

Our Security Operations Center runs 24/7 and monitors multiple threat intelligence feeds, vendor advisories, and the CISA Known Exploited Vulnerabilities (KEV) catalog. When a critical CVE surfaces, our SOC analysts are typically the first to flag it.

The SOC doesn’t just send an email and wait. Analysts open tickets with our internal engineering team and call escalation contacts directly. For CVE-2026-0300, that call happened before most of the security press had published their first articles about it.

The initial assessment focuses on three questions: what’s the severity, is it being actively exploited, and do any of our clients run the affected software? Speed matters here because attackers work from the same public advisories we do.

Hours 1-2: Triage and Asset Inventory

Centralized asset management is what makes the next two hours fast instead of chaotic. We use our RMM platform to query every client environment and identify exactly which systems run the affected software and versions. For the PAN-OS vulnerability, that meant identifying every Palo Alto firewall across our entire client base within minutes.

That inventory separates a structured response from a scramble. Without centralized asset visibility, you’re relying on spreadsheets, memory, or manually checking each environment one at a time. With a real-time software inventory, we know exactly who’s affected before the first patch is even available.

At the same time, our endpoint detection and response (EDR) platform gets updated detection rules pushed to every managed endpoint. EDR monitors for exploitation attempts in real time, so if an attacker tries to use the vulnerability against a client before the patch is deployed, we see it immediately. This safety net buys us time during the patching window.

Hours 2-6: Mitigation and Patch Deployment

Patching takes time. Vendors need to release fixes, we need to validate them, and deployment has to be staged to avoid breaking production systems. During that window, multiple layers of defense work together to reduce exposure.

Perimeter blocking. Our Fortinet firewalls receive updated threat signatures and IPS rules to block known exploit traffic targeting the vulnerability. This stops the most common attack patterns at the network edge before they reach internal systems.

Log correlation. Our managed SIEM platform pulls logs from firewalls, servers, cloud services, and endpoint agents, then correlates them to determine whether the vulnerability has already been exploited in any client environment. For the cPanel mass exploitation (CVE-2026-41940), where multiple threat actors were actively compromising hosting environments, that retroactive analysis was just as important as the forward-looking patch deployment.

Additional endpoint defense. Bitdefender provides a second layer of endpoint protection during the vulnerability window, catching threats that might bypass a single detection engine.

Once the vendor releases a patch, we test it against representative systems before deploying broadly. We work directly with vendors to verify critical patches and confirm compatibility. The RMM platform then pushes validated patches to every affected system across all client environments.

Hours 6-12: Validation and Communication

Deploying a patch is not the same as confirming it worked. After deployment, we run verification scans through the RMM platform to confirm every affected system reports the patched version. Any system that failed to update gets flagged for manual follow-up, whether the cause is a pending reboot, a software conflict, or a connectivity issue.

Our SIEM and EDR data provide a second layer of confidence: we can confirm whether exploitation occurred during the vulnerability window. For clients in regulated industries with audit requirements, this evidence trail matters as much as the patch itself.

Client communication happens throughout the process, not just at the end. All clients receive updates through our ticketing system, and technical contacts get direct calls for critical vulnerabilities. We don’t wait until everything is resolved to start communicating. Clients know what we found, what we’re doing about it, and when they can expect confirmation.

The PAN-OS zero-day followed this exact process. So did our response to the FortiClient EMS vulnerability earlier this year. The tools and specific steps vary with each vulnerability, but the process stays consistent because it was built to handle exactly these situations.

What to Expect From Your IT Provider

If you’re evaluating managed security providers or wondering whether your current provider would handle a zero-day effectively, here’s what to ask:

• How quickly do you learn about new critical vulnerabilities? The answer should involve 24/7 monitoring and threat intelligence feeds, not “we check vendor websites periodically.”
• Can you identify every affected system across all clients within an hour? This requires centralized asset management with real-time software inventory. If they can’t answer confidently, they’re working from incomplete data.
• What happens between the advisory and the patch? Look for layered mitigation: firewall rules, EDR updates, SIEM monitoring. If the only answer is “we wait for the patch and apply it,” your environment is unprotected during the gap.
• How do you confirm patches actually deployed? Verification scans, not assumptions. “We pushed it” is not the same as “we confirmed it.”
• How and when do you communicate during a response? Updates should come during the event, not after. You should receive specific information about what was affected and what was done, not a vague “your systems have been updated” message.

The difference between a structured vulnerability response and an ad hoc one is not visible when nothing is happening. It shows up when a CVSS 9.3 advisory drops and your IT provider needs to protect your environment before attackers reach it. The tools, the process, and the team behind them determine whether you’re patched in 12 hours or still exposed a week later.

If you aren’t confident your current provider can walk you through their response process the way we just did, that’s worth a conversation.