Find out before go-live. Ask the vendor for a list of every outbound address, port and purpose, then confirm it by watching the product's traffic in a test network. Allow only what you can justify, and record the rest as questions for the vendor.
Why on-premises does not mean offline
Hosted on your hardware does not mean closed to the outside. Commercial products often contact the vendor for license checks, update downloads, telemetry, crash reports, content feeds and cloud features. Some call third party services the vendor chose, such as analytics or fonts. Each connection is a path out of your network, and sometimes a path in.
NCSC's cloud security guidance tells buyers to know where their data is stored, processed and managed, and to include derivatives such as verbose logs. The same thinking applies to on-premises software that sends data home. If crash reports contain customer data, it has left your premises.
Step 1: ask the vendor
Send a short request:
- A list of all outbound destinations by hostname, with port and protocol.
- The purpose of each one.
- What data each connection sends.
- Whether each can be disabled and what breaks if it is.
- Whether the destination list changes between versions, and how you are told.
- Which destinations belong to third parties.
Vendors with a mature support process often have this list ready. Treat a vague reply as information.
Step 2: observe it yourself
Do not stop at the vendor's word. In a test network:
- Install the product with no internet access first. Note what fails.
- Allow internet access through a logging proxy or firewall that records destination names.
- Run the product through normal use, including start up, idle time and an update check.
- Export the destination list and compare it with the vendor's.
A destination that appears in your capture and not in the vendor's list is the first question to send back.
Step 3: decide and enforce
| Connection type | Typical decision |
|---|---|
| Update and license checks | Allow to named hosts only |
| Telemetry with no customer data | Allow or disable by policy |
| Telemetry that includes customer or device data | Disable, or review the data flow with privacy staff |
| Unexplained destinations | Block until explained |
Enforce with an allowlist of hostnames at the firewall or proxy, not a broad "allow all HTTPS" rule. Review the list at every major upgrade.
Contract language
- The vendor documents all outbound connections and updates the list with each release.
- New connections are disclosed in release notes before they ship.
- Telemetry can be disabled without loss of security fixes.
Keep the record
Store the inventory with the product record. When an advisory names a vendor domain, or a domain is taken over, you can tell at once whether you are affected.
Quick check
Can I block all outbound traffic from a commercial product?
Often yes, but updates, license checks and some features may break. Test first and block selectively.
Who should own the list?
The product owner, with network or security staff enforcing it.
Safeguard helps map what you run with asset discovery and continuous monitoring, which makes the inventory easier to keep current.
Sources
Last reviewed: 19 October 2026.
