In most cases, no. An unpatchable system should not reach the internet unless there is a named, necessary reason. Blocking outbound traffic does not prevent an attack, but it limits what a compromised system can download, where it can send data and how it can be controlled from outside.
What the guidance says
NIST's text on unsupported components says the increased risk of using them can be mitigated, for example, by prohibiting their connection to public or uncontrolled networks. Its deny by default, allow by exception enhancement applies to inbound and outbound traffic, so that only essential and approved connections exist.
Many teams focus on inbound rules and leave outbound open. That leaves attackers a comfortable way to fetch tools and move data out.
Why outbound matters for legacy hosts
A legacy server rarely needs to browse the web or reach arbitrary addresses. Typical needs are narrow: time sync, a database, a license server, a backup target, a vendor update site. If outbound is open and something goes wrong, the host can reach out to the attacker's infrastructure. If outbound is closed, the attack has to work harder.
Find the real needs
- Capture outbound flows for a few weeks. Use firewall logs or flow records. Include month end.
- Ask the owner about each destination. What is it for? Is it still needed?
- Group the results.
| Outbound flow | Typical decision |
|---|---|
| Internal database, time server, backup target | Allow by address and port |
| Vendor license or update site | Allow by specific address, ideally through a proxy |
| Operating system update service for an unsupported OS | Usually unnecessary, review |
| General web access | Block |
| Unknown or unexplained | Block, then see who complains |
- Write allow rules for the approved flows. End with a deny.
- Log denies and review them. A denied connection to an unfamiliar external address from a legacy host is a strong signal.
Use a proxy for the exceptions
If the system needs to fetch something from outside, such as a vendor update, route it through a proxy that restricts destinations, inspects content where it can and logs requests. Better still, fetch the file on a modern machine, check it and copy it in by a controlled path.
DNS deserves a rule
DNS is often left open. Point the host at an internal resolver, allow only that, and log queries. Otherwise DNS can carry data out or reach attacker controlled names even when other outbound traffic is blocked.
Handle the pushback
Teams worry that blocking egress will break something. Reduce that risk by running in logging mode first, rolling out by system with a rollback plan, and keeping a short channel for requests, with a decision in days not weeks.
Record it
Add to the exception: the allowed outbound destinations with reasons, the date of the last review, and the test showing that an internet connection from the host fails.
Quick check
Does blocking egress stop ransomware?
It does not stop it from running locally, but it can block downloads, command channels and data theft over the network. Backups and isolation still matter.
What about operating system updates for an unsupported OS?
If the vendor has ended updates, the host has little to fetch. If you buy extended updates, route them through a controlled path and allow only the update destinations.
Sources
- NIST SP 800-53 Rev 5 control catalog (OSCAL JSON, NIST oscal-content repository) (SA-22 Unsupported System Components and SC-7(5) Deny by Default, Allow by Exception)
Last reviewed: 19 October 2026.
