Should You Take a System Offline If You Can't Patch a Critical Flaw?

Sometimes, and less often than the headlines suggest. Take a system offline when it is reachable by attackers, the flaw is exploitable or about to be, the data or access behind it matters, and no compensating control you trust can be in place within hours. Otherwise, cut off the vulnerable path, keep the rest running, and patch fast.

"Offline" is not one switch. It ranges from pulling a whole site to blocking one upload endpoint for unauthenticated users. Teams that get this right choose the smallest cut that removes the attack path, write down why, and put a deadline on it.

Key takeaways

• Government guidance this week was conditional every time: patch first, mitigate if you cannot, and only then consider going offline. Nobody advised going offline instead of patching.
• NIST SP 800-40 Rev. 4 lists four ways to respond to a vulnerability: accept, mitigate, transfer and avoid. Taking a system offline is a form of avoid or mitigate, chosen for a period of time, not a permanent state.
• In the first hour you need four facts: is it exposed, is it being exploited, is the vulnerable code in a live path, and what data or access sits behind it.
• Pre-agree who can pull a revenue system. Decisions about not updating belong at senior level, according to the UK NCSC, so put the name in the runbook before the incident.
• "Partly offline" is usually the better answer: block one path, one method, one region, or all unauthenticated traffic, and leave the rest of the service up.
• Bringing a system back is a checklist, not a feeling: patched, verified, checked for compromise, monitored, and the temporary mitigation removed on a schedule.
• The way to avoid the question next time is a pipeline that can rebuild and redeploy any service within hours, plus an inventory that tells you where a component runs.

Why this question landed on every ops desk this week

On 21 October 2026, PHP shipped fixes for two critical flaws that allow remote code execution, and public bodies across Europe took websites offline while they patched. We covered the news in why governments took websites offline over PHP2Shell. This post is about the decision itself, which applies to any critical vulnerability in any stack.

Read on their own pages, the agency advice was consistent and conditional:

• CISA's alert of 21 October urges immediate patching. It says organisations that cannot update right away, or that run PHP 8.1 or earlier, "should take PHP-based systems offline until they can be patched or updated." It adds that a web application firewall "may provide some protection" in the meantime, and that CISA had not observed exploitation at the time of publication.
• The UK NCSC gives an ordered list: find every installation, update, apply temporary mitigations, and only if those cannot be applied in time, consider taking the system offline. It also asks teams to check a system for compromise before upgrading or mitigating it if they cannot update or disable it straight away.
• CERT-EU Security Advisory 2026-018 says to patch immediately and, if that is delayed, to "consider isolating internet-facing resources from public networks until the fix is applied and verified." It also says PHP's temporary mitigations reduce exposure but do not make systems safe.

The line most quoted in the press, take the system offline "until it can be fully mitigated," was attributed in different reports to different US agencies. Defense One linked it to a post by the FBI Cyber Division. TechCrunch reported that the NSA advised organisations to update immediately or take systems offline until they could. The UK NCSC page uses near identical wording. We could not reach an NSA or FBI page directly, so treat the attribution as reported.

Notice the order: patch, then mitigate, then isolate. Offline was the last rung, not the first.

What does it actually mean to take a system offline?

NIST SP 800-40 Rev. 4, the US guide to enterprise patch management, gives a vocabulary that helps here. It names four risk responses:

Two lines from that publication matter for this decision. First, NIST says that patching or upgrading is the only response that removes the vulnerability "without removing functionality." Everything else trades away some function, some reach or some certainty. Second, NIST says that by default an organisation already accepts the risk of the software it runs. Doing nothing is a decision, even when nobody signs it.

So "should we take it offline?" is really a choice between four answers. Accept costs you risk, mitigate costs some function and confidence, transfer costs money and time, and avoid costs availability and revenue but buys the most certainty.

NIST also separates three emergency scenarios that map neatly onto this week: emergency patching (a fix exists, deploy it on an accelerated schedule), emergency mitigation (no fix yet, or the fix is broken, so mitigate temporarily), and unpatchable assets (isolate them for the long term). The guide's advice for emergency mitigation is worth copying into your runbook: plan for several kinds of mitigation in advance, including deactivating functionality and isolating assets, automate them, and set schedules for both patch deployment and mitigation removal.

When is offline the right call versus a compensating control?

The honest answer is that offline is right when the alternatives are not good enough in the time you have. Here is a way to make that concrete.

The four questions that decide it

1. Can an attacker reach the vulnerable code? An internet facing endpoint with no authentication in front of it is the worst case. A service that only listens on an internal network behind a VPN is a very different risk.
2. Is exploitation happening or close? CISA's Stakeholder Specific Vulnerability Categorization (SSVC) treats exploitation status as the first decision point, alongside technical impact, whether exploitation is automatable, mission prevalence and public well being impact. Its outcomes run from Track to Act, where Act means leadership sets the response and remediation happens "as soon as possible."
3. Do you have a mitigation you trust? A vendor workaround that closes the specific attack path, a WAF rule tested against the actual request pattern, or the ability to turn the vulnerable feature off. If the vendor or a national CERT says the workarounds are partial, weight this low.
4. What is behind the system? Customer personal data, payment data, credentials, administrative access to other systems, or a foothold into your internal network all raise the stakes. A static brochure site with no secrets on the box lowers them.

A decision table

Two cautions apply to every row. First, "no exploitation observed" describes what one agency or vendor has seen at one moment. On 21 October, CISA had not observed exploitation while other reporting described early attempts. Assume it can change within hours of a public fix, because a patch diff shows attackers where to look. Second, a WAF is a compensating control, not a fix. CISA's own wording was that it "may provide some protection." For more on what counts and how to record it, see compensating controls: what they are and how to document one.

When offline is clearly wrong

Going offline is not free and is sometimes the riskier move:

• Safety and life critical systems. A hospital system, an industrial control loop or an emergency dispatch tool may do more harm offline than exposed for a few hours behind tight network controls. NIST notes that some regulated assets cannot be updated on the customer's own schedule at all.
• When the system is not exposed. Pulling an internal service that nothing outside can reach does not reduce much risk and does cost the business.
• When a better cut exists. If one endpoint carries the vulnerability, blocking that endpoint protects you nearly as well as pulling the site.

What facts do you need in the first hour?

Use a short, fixed list so nobody debates what to look up.

1. Exposure

Where does the vulnerable component run, and who can reach it?

• Which services, hosts, containers and vendor products include it, at which versions.
• Which of those are internet facing, and whether any authentication sits in front.
• Which products embed the component without advertising it. CERT-EU and CISA both warned that PHP is often bundled inside other software, so a version check on your own servers is not the whole picture. The Dutch NCSC published a public inventory of products that embed PHP for this reason.

2. Exploit status

• Is the vulnerability in CISA's Known Exploited Vulnerabilities (KEV) catalog? CISA says organisations should use KEV "as an input to their vulnerability management prioritization framework."
• Has the vendor, a national CERT or a credible researcher reported exploitation or a public proof of concept?
• Is exploitation automatable, meaning a scanner could hit every exposed instance without human effort? That is one of SSVC's decision points and a strong signal toward faster action.

3. Reachability

A component can be present without its vulnerable function being used. Reachability analysis asks whether your code, or the request path into it, actually calls the vulnerable function. If it does not, your urgency drops, though it does not vanish, because configuration and future code changes can bring it into play. For the method, see reachability analysis for prioritizing vulnerabilities.

For runtime flaws like the PHP case, reachability is different: if the runtime handles web requests, the vulnerable code is in the path by definition. Do not let a "not reachable" label on an application library talk you out of patching a language runtime.

4. Data and access at stake

• What data does the system store or process: personal data, payment card data, health data, credentials, secrets?
• What can it reach: databases, internal APIs, cloud control planes, other hosts?
• What would a compromise oblige you to do: notify a regulator, notify customers, invoke incident response?

A first hour worksheet

If you cannot fill in the first row within an hour, that gap is the real finding, and the strongest argument for isolating first and investigating second.

Who has the authority to take a revenue system offline?

Many teams discover mid incident that nobody is sure who can pull a revenue system, and the exposure window grows while people find each other.

The UK NCSC's vulnerability management guidance is clear that choosing not to update is a senior decision and the organisation must own that risk. The mirror image is also true: choosing to take a revenue system down is a business decision, so the authority has to be agreed with the business before the incident.

What to pre-agree

• A named decision owner per tier of system, with a deputy. For tier one revenue systems this is usually the CTO, CISO or a designated incident commander with delegated authority.
• A threshold that triggers the decision, written in plain terms: for example, a critical remote code execution in an internet facing component, with exploitation active or a fix public, and no tested mitigation within four hours.
• Who can act without asking. Many organisations let the security on call lead isolate a system immediately when active compromise is suspected, with the business owner informed within a fixed time rather than asked first.
• A maximum time to decide. If the decision owner cannot be reached in, say, 30 minutes, the deputy decides. Silence is not a decision.
• A communication path to customer support, sales, legal and the status page.

A responsibility table you can adapt

The key line is the third one. When there is evidence of active compromise, waiting for a meeting is how a contained incident becomes a breach, so give the people closest to the system the authority to isolate first.

How do you take something partly offline?

"Partly offline" means removing the attack path while keeping as much of the service as you can. It is often the best answer, because most vulnerabilities live behind a specific route, method, file type or feature.

Options from narrowest to widest

A useful rule: the narrower the cut, the more you need to know about the vulnerability. If the advisory tells you exactly which feature or request type triggers the flaw, block that. If the advisory says, as CERT-EU did of PHP's workarounds this week, that mitigations reduce exposure but do not make systems safe, a narrow cut buys less and isolation becomes more attractive.

Step by step: the first four hours

The following walkthrough uses common tools. Adapt the names to your environment, and test these changes in a staging environment before you need them for real.

Step 1: Find every instance

Check versions on hosts and in images:

# Language runtime on a host
php -v
dpkg -l | grep -i php        # Debian and Ubuntu
rpm -qa | grep -i php        # RHEL family

# What is running in containers right now
docker ps --format '{{.Image}}' | sort -u

# Images in a Kubernetes cluster
kubectl get pods -A -o jsonpath='{range .items[*]}{.spec.containers[*].image}{"\n"}{end}' | sort -u

Scan source trees, images and SBOMs for the component, so you catch copies that are bundled rather than installed:

safeguard scan --dir .
safeguard scan --image registry.example.com/web:2026.10.20
safeguard scan --sbom vendor-product-sbom.cdx.json
# results are written as JSON under ./output

For a deeper method, see SBOM incident response: finding affected products fast.

Step 2: Confirm exposure

# What is listening on the host, and on which interfaces
ss -tlnp

# What the public internet sees from your edge
curl -sI https://www.example.com | grep -i -E 'server|x-powered-by'

Compare the list from step 1 with your load balancer and DNS records. Anything in both lists is the priority set.

Step 3: Apply the narrowest cut that removes the path

Block one path at an nginx reverse proxy and tell clients it is temporary:

# Temporarily disable the vulnerable route
location ^~ /upload/ {
    add_header Retry-After 3600 always;
    return 503;
}

# Allow the admin area only from the VPN range
location ^~ /admin/ {
    allow 10.20.0.0/16;
    deny  all;
    proxy_pass http://app_backend;
}

# Cap request bodies while you patch
client_max_body_size 2m;

Validate and reload without dropping existing connections:

sudo nginx -t && sudo systemctl reload nginx

A 503 response with a Retry-After header tells browsers, monitors and crawlers that the outage is temporary, which is kinder to search ranking and uptime checks than a 404 or a closed port.

Step 4: Or isolate the whole service

In Kubernetes, remove public ingress while keeping the pods for investigation:

# deny-all-ingress.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: emergency-deny-ingress
  namespace: web
spec:
  podSelector:
    matchLabels:
      app: storefront
  policyTypes:
    - Ingress
  ingress: []

kubectl apply -f deny-all-ingress.yaml
# Or, if you do not need the pods for forensics, stop serving entirely
kubectl scale deployment/storefront -n web --replicas=0

On a cloud virtual machine, remove the public rule from its security group:

aws ec2 revoke-security-group-ingress \
  --group-id sg-0123456789abcdef0 \
  --protocol tcp --port 443 --cidr 0.0.0.0/0

Prefer isolation over deletion. If the system was compromised, you will want its disk, memory and logs. Scaling to zero or terminating instances can destroy that evidence.

Step 5: Look for signs of compromise

The UK NCSC asks teams that cannot update or disable a system immediately to check it for compromise and for backdoors. CISA suggested monitoring for PHP worker processes launching shells or downloading tools. Generic checks that work for most web stacks:

# Child processes of the web worker that should not be there
ps -ef --forest | grep -A3 -E 'php-fpm|httpd|nginx|node|java'

# Files in the web root changed in the last three days
find /var/www -type f -mtime -3 -printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort

# Outbound connections from the host
ss -tnp state established

If you find anything suspicious, stop treating this as patching and start treating it as an incident. NIST SP 800-61 Rev. 3, published in April 2025, frames incident response inside the NIST Cybersecurity Framework 2.0 and is a sound reference for that switch.

Step 6: Patch, rebuild and redeploy

Patching a host package and patching an image are different jobs:

# Host package
sudo apt-get update && sudo apt-get install --only-upgrade php8.3-fpm
sudo systemctl restart php8.3-fpm

# Container image: rebuild from a patched base, no cache
docker build --pull --no-cache -t registry.example.com/web:2026.10.21-patched .
docker push registry.example.com/web:2026.10.21-patched
kubectl set image deployment/storefront -n web app=registry.example.com/web:2026.10.21-patched
kubectl rollout status deployment/storefront -n web

NIST recommends a short canary phase even during emergency patching to confirm the patch is not corrupted and does not break the software. Minutes to a few hours is normal.

Step 7: Gate the old version out of CI

Once fixed, stop the vulnerable version from coming back in a later merge. A minimal GitHub Actions job that fails on a known exploited vulnerability:

name: dependency-gate
on: [pull_request]
jobs:
  gate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: safeguard-sh/gold-scan-action@v1
        with:
          fail-on: kev   # kev = known exploited only, vuln = any known CVE, none = report only

Start with kev so you do not block every merge on day one, then move to vuln once the backlog is under control.

How do you document the decision for auditors, customers and insurers?

Write the record while you decide, not afterwards. It should answer what an auditor, customer or insurer will ask months later: what you knew, when, who decided, and what you did.

A decision record template

decision_id: VULN-2026-10-21-001
component: php
affected_versions: "8.2 to 8.5 before the 21 Oct 2026 releases"
assets:
  - name: storefront
    exposure: internet, unauthenticated
    data: customer accounts, order history
  - name: internal-wiki
    exposure: VPN only
    data: internal documentation
facts_at_decision:
  kev_listed: false
  exploitation_reported: "none observed by CISA at 21 Oct publication; reports of early attempts elsewhere"
  fix_available: "yes, released 21 Oct"
  vendor_mitigation: "partial; vendor states no complete mitigation"
  reachability: "runtime handles all web requests; in path"
options_considered: [accept, mitigate, partial_offline, full_offline]
decision: partial_offline
detail: "storefront: block upload and admin paths, cap request size; internal-wiki: keep running, patch in emergency window"
decided_by: "CTO (delegated incident commander)"
decided_at: "2026-10-21T14:05Z"
review_by: "2026-10-21T20:00Z"
removal_condition: "patched build verified in production, compromise check clean"
evidence:
  - nginx change id
  - scan output before and after
  - compromise check notes

What each audience wants

Reporting clocks can start during the offline window if you find evidence of compromise. In India, for example, the CERT-In directions of 28 April 2022 require specified incidents to be reported within 6 hours of noticing them, and the listed types include targeted scanning or probing of critical systems and compromise of critical systems. The same directions require logs to be kept for a rolling 180 days. See our guide to India's CERT-In cyber security directions. Check the equivalent rules wherever you operate.

What do SLAs and contracts say about planned emergency downtime?

Most teams have not read this part until they need it. Check the SLAs you give customers, the SLAs suppliers give you, and security clauses in customer contracts.

Read your own SLA's definitions first

Uptime commitments hinge on how "downtime" is defined and what is excluded. Common patterns include:

• Scheduled maintenance windows that do not count as downtime, often with an advance notice period. Emergency security work rarely fits the notice period.
• Emergency maintenance clauses that allow short notice work for security reasons, sometimes with a cap on hours per month.
• Force majeure and third party exclusions. These usually do not cover a decision you chose to make, even a sensible one.
• Downtime measured by error rate. For example, the Google Workspace SLA defines downtime as a period where the user interface shows more than a five percent user error rate, and its public SLA page lists exclusions such as force majeure and customer side equipment, without a separate carve out for scheduled maintenance on that page. Under a definition like that, a partial cut that keeps errors below the threshold may not count as downtime at all.

The practical point: if your contract counts every minute of a security takedown against your uptime credit, a partial cut is cheaper than a full one. Know which is which before you decide.

Security obligations often outweigh uptime

Many enterprise customer agreements also carry security obligations: keep systems patched, protect customer data, notify of incidents within a set time. A short outage that prevents a breach usually costs less, contractually and reputationally, than staying up and failing a data protection duty. Ask legal to confirm, but expect that answer.

If a supplier goes offline for the same reason, check its SLA too, and see how do I know if my vendors have patched a critical vulnerability.

Pre-agree the customer message

Prepare a template for the status page and support team:

We have temporarily disabled [feature or service] while we apply an urgent security update for a widely reported vulnerability. We have no evidence that customer data has been accessed. We expect to restore service by [time] and will update this page every [interval].

Only say "no evidence of access" if you have actually checked.

What does the bring-back checklist look like?

Coming back online is where teams cut corners, so write the checklist down.

A strong model comes from CISA's Emergency Directive 24-01, issued in early 2024 for two VPN gateway products. It required US federal agencies to disconnect affected devices by a deadline. To return a device to service, agencies had to export its configuration, factory reset it, rebuild it on a supported version, reimport the configuration and revoke and reissue the certificates, keys and passwords it held. The directive also told agencies to assume related domain accounts were compromised. That is heavier than most incidents need, but the shape is right: a possibly compromised system comes back as a clean rebuild with new secrets.

The checklist

1. Patched. The fixed version is installed everywhere the component runs, including images, base images, sidecars and bundled vendor products. Confirm with a version check and a fresh scan, not with the deployment log.
2. Restarted. Long running workers and application servers are restarted so the old code is no longer in memory.
3. Verified. The vulnerable behaviour no longer occurs. Use the vendor's verification guidance or a safe, non destructive check from your security team. Do not run public exploit code against production.
4. Clean. The compromise check came back clean, or the system was rebuilt from a known good image. If there was any doubt, credentials and keys the system held have been rotated.
5. Monitored. Extra logging and alerting on the formerly vulnerable path stays on for at least several days.
6. Mitigation removed on schedule. Temporary rules (blocked paths, size caps, allow lists) are either removed or made permanent on purpose. NIST asks for schedules for mitigation removal, because forgotten emergency rules turn into mystery outages months later.
7. Gated. CI and admission policy prevent the vulnerable version from being redeployed.
8. Communicated. Status page, support and affected customers are told the service is back, and the decision record is closed with times.
9. Reviewed. A short post incident review asks why the system could not be patched immediately and what would change that.

Who signs the return

The same person who was accountable for the decision to go offline should sign the return, with the security lead confirming steps 1 to 4. That keeps the decision honest in both directions.

How do you avoid this situation next time?

Teams that patched within hours on 21 October never had to debate going offline.

1. A patch pipeline that can ship in hours

What decides it is how fast a fixed version moves from advisory to production: automated dependency updates, fast tests, and no change board wait for a security fix. NIST notes that delaying routine patching makes emergency patching harder.

2. Rebuildable images

If every service can be rebuilt from source with a patched base image and redeployed by one command, a runtime flaw becomes an afternoon of work. If some services are hand built virtual machines that nobody dares restart, those are your future offline decisions. Rebuild them now.

3. Runtime inventory and SBOMs

Keep a current SBOM for every service and image you run, plus a list of vendor products that embed common runtimes, so "where does this run?" takes minutes to answer.

4. Pre-built emergency mitigations

NIST's advice is to plan several types of emergency mitigation in advance and automate them. In practice that means:

• Feature flags around risky features such as uploads, imports and template rendering.
• A tested static or read only fallback for public sites.
• Prewritten proxy and network rules, kept in version control, that can be applied in one change.
• A runbook entry for full isolation that preserves evidence.

5. Retire unpatchable assets or wall them off

End of life software will never get an official fix. NIST treats unpatchable assets as their own scenario that needs long term isolation such as micro segmentation. If you know a system will not be patched, isolate it now, not during the next emergency.

6. Exercise the decision

Run a tabletop once or twice a year with a critical runtime flaw and no reliable mitigation. Time how long it takes to fill the first hour worksheet and reach the decision owner, then improve that number.

Where Safeguard fits in the offline decision

Safeguard helps with the inputs and the follow through. It does not operate your firewall, your proxy or your network, and it cannot take a system offline for you.

• Finding where a component runs. Safeguard scans repositories, container images and SBOM files and shows which projects contain a given component and version, which answers the first row of the worksheet.
• Context for urgency. Vulnerability matching draws on sources including NVD, GitHub advisories, OSV and the CISA KEV catalog, and reachability analysis combines code reachability with EPSS and KEV to rank what matters. That is the core input for whether the vulnerable code sits in a live path.
• Recording the decision. Findings can be given a status, and mitigations or risk acceptance requests can be recorded against them in the platform, so the evidence lives next to the finding instead of in a chat thread.
• Shortening the patch. Griffin autonomous remediation opens fix pull requests for dependency upgrades, which is what makes going offline unnecessary in the first place. It ships switched off by default.
• Keeping it fixed. Policies and gates can block a vulnerable version from shipping again.
• Telling customers. Trust Center, a public posture page, is in early access.

Where it does not help: host operating system packages on machines you never scan, vendor appliances you cannot inspect, and the network change itself. Those still depend on your vendors, your distribution and your own runbooks.

Common mistakes

• Treating offline as all or nothing. A full outage when one path carries the flaw costs revenue for little extra safety. Start with the narrowest cut that removes the path.
• Trusting a WAF rule as a fix. Agencies described WAFs as partial protection. Keep the patch deadline even when the rule is in place.
• Patching the host but not the image. A package update on a build host does nothing for containers already running an old base image. Rebuild and redeploy.
• Forgetting to restart. Updated binaries do not replace code already loaded in long running workers.
• Ignoring embedded copies. Vendor products and appliances bundle runtimes. Ask vendors directly and check inventories such as the one the Dutch NCSC published.
• Destroying evidence. Terminating instances or wiping disks during isolation removes the logs you need if a compromise surfaces later.
• Bringing systems back without a compromise check. A patched backdoor is still a backdoor.
• Leaving emergency rules in place forever. Blocked paths and size caps become unexplained bugs. Schedule their removal.
• Deciding by committee in real time. If the decision owner is not written down, the meeting is the exposure window.
• Saying "no evidence of compromise" without looking. That sentence ends up in contracts, insurer questionnaires and regulator filings.

FAQ

Should I take my website offline if I cannot patch a critical vulnerability?

Only if it is exposed, the flaw is exploitable, something valuable sits behind it, and you cannot put a trusted mitigation in place within hours. In most cases, blocking the vulnerable path or restricting access buys the same safety with less disruption. Agencies including CISA, the UK NCSC and CERT-EU made offline the fallback after patching and mitigation, not the first step.

Is a WAF enough instead of patching?

No. A WAF rule can reduce exposure while you patch, especially when it targets a known request pattern. It can be bypassed by variations, it does nothing for internal attack paths, and agencies described it as partial protection. Treat it as a compensating control with an end date.

How long can a system stay offline?

As long as it takes to patch, verify and check for compromise, and no longer than your contracts and customers can bear. Set a review time when you decide, for example every four to six hours, and escalate if the fix is further away than expected.

Who should approve taking a production system offline?

A named senior owner agreed in advance, usually the CTO, CISO or a delegated incident commander, with a deputy. Give the security on call lead authority to isolate immediately when there is evidence of active compromise, and inform the business owner afterwards.

Does taking a system offline count against my SLA?

Often yes, unless your contract has an emergency maintenance or security exclusion, or defines downtime in a way that a partial cut does not trigger. Read the definitions and exclusions in your customer SLAs before an incident and ask legal how security obligations interact with uptime commitments.

What is the difference between isolating a system and shutting it down?

Isolation removes network access while the system keeps running, which preserves memory, logs and disk for investigation. Shutting down or terminating stops it and may destroy evidence. Prefer isolation when compromise is possible.

How do I check whether a system was compromised before bringing it back?

Look for unexpected child processes of the web or application worker, recently changed files in the web root, new scheduled tasks or accounts, and unusual outbound connections. If you are unsure, rebuild from a known good image, rotate the secrets the system held, and bring in incident response help. The UK NCSC points organisations to assured incident response providers for this.

What if the software is end of life and will never be patched?

Then offline is no longer a temporary measure. Plan to replace it, move it behind strong isolation such as micro segmentation, or both. NIST SP 800-40 treats unpatchable assets as a separate scenario that needs long term mitigation and periodic review of whether the asset is still worth the cost.

Fix it without waiting for upstream

Most offline decisions happen because a fix cannot reach production fast enough, or because no fix exists yet. Both gaps are things you can shrink before the next emergency.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

This first demo sets up the Safeguard runner on your own machine, approves it with its device code, then scans from the terminal. In the first hour of an emergency, that is how you answer "where does this component run?" across repositories and images without sending source code anywhere first.

Click through it at your own pace, or open it full screen.

The second demo is a real Safeguard CLI session. You ask it to fix the lodash CVE in a repository; it reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. The same approve each step flow is how you move a dependency to its fixed version quickly enough that offline never becomes the question.

Click through it at your own pace, or open it full screen.

The third demo is a real Android session: you send work to a computer running the CLI and approve the command on the phone with Allow once, Allow for turn or Deny. When the decision owner is away from a desk during an emergency, this is one way to keep a human approval on each step without waiting for them to get back.

Click through it at your own pace, or open it full screen.

To try it on your own code, download Safeguard or read the CLI documentation.

Quick check

Sources

• CISA: Critical Vulnerabilities in PHP Require Immediate Patching (21 October 2026)
• UK NCSC: Critical security issue affecting PHP
• CERT-EU Security Advisory 2026-018: Critical Vulnerabilities in PHP
• NIST SP 800-40 Rev. 4: Guide to Enterprise Patch Management Planning
• NIST SP 800-40 Rev. 4 (PDF)
• NIST SP 800-61 Rev. 3: Incident Response Recommendations and Considerations
• CISA: Stakeholder Specific Vulnerability Categorization (SSVC)
• CISA: Known Exploited Vulnerabilities Catalog
• CISA: Emergency Directive 24-01
• UK NCSC: Vulnerability management guidance
• CERT-In: Directions under section 70B, 28 April 2022 (PDF)
• CERT-In: Directions page
• Google Workspace Service Level Agreement
• Defense One: Critical flaws in PHP prompt warning
• TechCrunch: The internet is having a very bad cybersecurity day

Last reviewed: 23 October 2026. Agency guidance and contract terms change; check the linked pages and your own agreements before relying on them.