Every Emergency Patch is a Planned Outage

On September 27, 2026, Citrix disclosed eight vulnerabilities in NetScaler, the gateway in front of remote access and business applications at thousands of companies. Two of them, CVE-2026-88771 and CVE-2026-88772, have already been exploited before anyone outside the attackers knew they existed. The same day, CISA added both to its Known Exploited Vulnerabilities catalog and gave federal agencies until Wednesday to patch. For each of those organizations, the fix meant taking remote access and every application that routes through the gateway offline this week. The faster you can restore the business, the faster you can afford to patch.

Patch on the attacker's clock

A zero-day means defenders get no head start, and this week they got less than that. Exploitation was already underway on September 26, a day before Citrix published a fix. It is the third time in three years that NetScaler has sent security teams scrambling. And the deadlines keep shrinking: for CitrixBleed 2 in July 2025, CISA gave federal agencies one day.

Meanwhile, the defenders' clock is running the other way. The 2026 Verizon DBIR found that exploiting a vulnerability is now the most common way attackers get in, accounting for 31 percent of breaches, while the median time to fully patch grew from 32 days to 43.

Forty-three days is far longer than this week's three-day deadline, so the patch goes in on the attacker's schedule, whatever it costs the business.

Take the gateway down on your schedule 

Patching an edge device means taking it offline, and every application that depends on it goes dark at the same time, from remote access for the whole workforce to the business apps that route through the gateway. The Dutch National Cyber Security Centre warned organizations in advance that "NetScaler upgrades can cause downtime." Some teams didn't wait for a patch to exist. One administrator wrote: "We ended up just shutting down outside access to Netscaler this afternoon until we got a clean bill of health from Citrix."

A planned outage starts and ends when the business agrees it should. Waiting hands that timing to the attacker.

Before the patch goes in, you need to know what the outage will cost: which business systems depend on the device, how long each one can be down, and how quickly it is restored. 

Plan for that second outage

If an attacker reached the device before the patch did, the patch is only the first outage. CISA's guidance for this pair goes well past updating firmware: isolate the device, revoke credentials, investigate the systems connected to it, rebuild with the latest firmware, rotate passwords and keys, and replace SSL certificates. 

The second outage is what really determines how long the business stays disrupted. The original CitrixBleed in 2023 became an entry point for LockBit ransomware affiliates. So plan the rebuild the way you plan the patch, knowing what it involves and how long it takes.

Map the outage in advance

Four things are critical to determine, before the next advisory arrives:

1. Which business systems depend on this device? Map the applications, users and partners that reach the business through the gateway, so the outage has a name and a scope before it starts.
2. What goes down with it? Authentication, remote access and anything that trusts the device's certificates can fail with it, so list them in the order they break.
3. In what order are they restored? Recovery runs in a sequence. Decide which systems the business needs first, and what each one waits on, while there is still time to think it through.
4. How long does that take? Put a number on it. Leadership can approve a patch window with a known end time in minutes, while an open-ended one turns into a meeting.

Build the gateway for the next patch

Mapping the outage tells you what it will cost the business. Resilient infrastructure is what keeps that outage as short as possible. When the gateway runs as a high availability pair, one node can be patched while the other carries the traffic, and Citrix supports upgrading a NetScaler pair this way without dropping existing connections.

Remember to also plan for the patch itself to fail. A failed upgrade can keep the gateway down well past the patch window, and at times the only way out is a rollback to the previous build and that build still carries the vulnerability you were patching, so the business is down and exposed at the same time. A rollback works only if you have a clean, safe and current backup of the device and its configuration, taken before the patch goes in.

Prepare for the rebuild the same way. Keep a documented configuration you can rebuild the device from, and a current list of the certificates and credentials it holds. Then, if the device has to be wiped, rotating those secrets follows a checklist. The systems that depend on the gateway need a restore order your teams have already rehearsed. With that in place, the next question is when to schedule the patch.

Make a downtime decision that you control

We can all be sure: there will be another NetScaler advisory, and each one will arrive with less time to act. What security teams do control is how much each emergency patch costs the business. A Resilience Assessment maps the systems your business runs on and scores how each one would hold up, so the next advisory starts with those four answers already in hand. With those answers and that infrastructure in place, the patch window has a more predictable end time that the business can plan around. 

Book your Resilience Assessment

‍