Your endpoint already knows every port it is listening on, and the program behind each one. From its own outbound testing, it also knows the outside address of the router or firewall in front of it. External Validation puts the two together: once a day, an independent validator on infrastructure we control goes to that router’s outside face, from a neutral public address that is not on your network, and tries each of those ports to confirm the router has no open path back in. A port that should be closed and answers anyway is a confirmed exposure — reported the same day, with the address it was reached from and a record of what happened on the wire.
A perimeter scanner tests the addresses you told it about. This starts from what each device itself reports — so the check follows the device, not a list.
The agent reports every port the device is listening on, on every network interface, with the program behind it. That inventory is already on your dashboard. It is also the exact list an attacker would love to have — so we use it first. And because the device tests its own outbound path, it also knows the outside address of the router or firewall standing in front of it.
An independent validator, on infrastructure we run, goes to that outside address from a neutral public address that is not on your network and tries each port the device reported. The question is simple: does the router or firewall have an open path in to that port on that device? Both IPv4 and IPv6 are tried, because a firewall is often configured for one and forgot the other.
If the router lets the probe through and a port your policy says must be blocked answers, it is a confirmed exposure: that device, that port, reachable from the internet. Tenant admins are alerted (email, webhook, dashboard), the finding lands on that device’s Exposed tab marked externally confirmed reachable, and it stays there until a later check confirms the door is closed.
Each port checked gets one plain-language verdict. When the evidence is ambiguous, the verdict says so.
Reachable from the internet, and your policy says it should be blocked. The one that pages you.
Tried more than once from outside, no answer every time. The healthy result for a must-be-blocked port.
It answered, and you told us it should — a web server, a VPN gateway. Recorded, not alarmed.
You said this should be reachable and it was not. Useful the morning a customer says your service is down.
Some services stay silent by design, so silence proves nothing. We say inconclusive rather than call it blocked.
| Endpoint | Service | Verdict | What happened | Probed from |
|---|---|---|---|---|
| branch-nas-01 203.0.113.24 | tcp/445file sharing | Exposed | the port answered from the internet — reachable | 198.51.100.741 ms round-trip |
| branch-nas-01 203.0.113.24 | tcp/3389remote desktop | Confirmed blocked | no response before timeout — dropped by a firewall | 198.51.100.7 |
| web-edge-02 2001:db8::2 | tcp/443web | Expected open | the port answered — intentionally public | 2001:db8:ff::9 |
| acct-laptop-jk 203.0.113.88 | udp/5353local discovery | Inconclusive | no reply and no rejection — can’t be told apart | 198.51.100.7 |
Illustrative readout. The real page lists every port checked, the address it was probed from, the round-trip time, and when it was last checked.
The scan-your-range approach and the ask-the-device approach answer the same question from different starting points. Only one of them follows the device.
Every finding shows the public address the probe came from. It is ours, it is not on your network, and it appears in your own firewall logs — so you can audit the check, not just trust it.
A run can be recorded on the wire. The capture sits beside the results with a plain-language summary and a download link, so an exposed finding is something you can hand to whoever owns the firewall.
The validator probes endpoints on your explicit ownership list and nothing else. It never scans the internet, never touches an address you have not claimed, and skips any device it could not reach by a genuinely external path.
Exposed Services is the inside-out view: the agent watches its own outbound flows and catches a machine reaching a database or admin port on a public address the moment it happens. External Validation is the outside-in view: an independent check that the doors into your devices are shut. Both land on the same Exposed tab, so “what can reach us, and what are we reaching” is one page, not two tools.
We try the handle. We never try to break in. A penetration test attempts to exploit what it finds; External Validation only asks whether a port answers from outside, records the answer, and stops. That is what makes it safe to run against every device every day.
It confirms that the ports we know about did not answer from the outside on the day we checked. It cannot speak for a port that was not listening at the time, a service that stays silent by design, or a door that opens tomorrow. That is why it runs every day and why the inconclusive verdict exists.
Only endpoints you own, only after you have listed them, only from an address you can see in the results. Nothing about this touches a network that is not yours.
Sign up free, enroll one agent, and its listening ports are on the dashboard within a minute. Once your endpoints are on the ownership list, the first outside-in check runs that night.
Part of the Security lane · the outside-in partner to Exposed Services.