A network scanner should be held to a higher standard, not a lower one

It does not listen

A program that accepts inbound connections is a program that can be attacked from the network. ScanWRX accepts none. There is no listening TCP socket at any point in its life, no UDP socket on a service port, and no web server bound to anything.

The most common place a desktop application acquires a listening socket is sign-in. Nearly every desktop app that talks to a web account uses the OAuth loopback flow: it opens http://127.0.0.1:<port>, sends you to the browser, and the browser redirects back to that local server.

ScanWRX deliberately does not do this, because it would require the application to listen — and “it is only bound to loopback” is a promise about how something is configured rather than about what it is capable of.

Activation instead uses a device-authorisation flow. The application makes an outbound request, shows you a short code, and then polls — outbound — until you have approved that code in a browser. Every connection is made by the application, outward. The browser and the application never speak to each other. Nothing listens.

Measured, on 3 September 2026

Reading source code cannot prove this. Source review cannot see what a dependency does, what the WebView2 runtime does, or what Windows does on the process’s behalf. So the sockets were sampled continuously: at rest before launch, for 25 seconds at idle after launch, and throughout three consecutive full scans of a /24.

Those 189 endpoints deserve an explanation rather than a footnote. A scanner has to send UDP and receive the replies — mDNS, SSDP, WS-Discovery and NetBIOS are all request-and-response over UDP, and a socket cannot receive a reply without holding a local port. Some of those sockets bind 0.0.0.0, which is required because multicast answers arrive from addresses the socket never sent to.

That is still not a service. Every port is assigned by the operating system, is different on every run, is gone when the scan ends, and has no firewall rule permitting anything to reach it. An ephemeral source port for an outbound query is not an inbound service, and the measurement above shows the idle application holding none at all.

Things ScanWRX will never do

• Open an inbound TCP or UDP service port
• Add an inbound Windows Firewall exception
• Configure UPnP or NAT-PMP port forwarding
• Establish a reverse tunnel, SSH tunnel, or any other tunnel
• Install or start an SSH server, or any listener service
• Enable Windows remote management, RDP or PowerShell remoting
• Expose the scan database over the network
• Provide a remote shell, or any remote-administration capability

Two automated checks defend this. A source check runs on every build and fails it if anyone adds a listener, a tunnel, or a port-mapping call. A regression test runs a real scan and asserts the process holds no listening socket before, during or after. Neither replaces the full measurement, which is run before every release.

What leaves your machine

Almost nothing, and never anything about the networks you scan.

Scan results

Never transmitted. No IP address, MAC address, hostname, device name, service or note is ever sent anywhere. Scans live in a SQLite file in your own Windows profile.

ScanWRX Free

No outbound connection at all beyond the network you point it at. It does not phone home, because it has nothing to say.

ScanWRX Pro

Contacts scanwrx.myrrapp.net to activate and to refresh its entitlement. That request carries an account id, a device id, and the application and Windows version. Nothing else.

Update checks

Send the current version number and nothing more. Can be switched off.

Crash and diagnostics

Nothing is sent automatically. The diagnostic package is written to a file you choose, and you send it to us only if you decide to.

Credentials

ScanWRX never guesses a credential. It does not try public, it does not try private, and it does not work through a list of manufacturer defaults. Trying credentials until one works is credential guessing — it is what an attacker does, anything monitoring the network logs it as such, and it is not something a tool on your laptop should do on a client’s network.

• SNMP credentials go to Windows Credential Manager, never to the database
• SNMP is read-only; there is no write path in ordinary discovery
• Credentials never appear in a log, an export or a diagnostic package
• Logs are filtered so a line mentioning a credential is dropped entirely

Discovered data is treated as hostile

A hostname, an mDNS record, an SSDP descriptor or an HTTP page title is written by whoever owns that device — not by you, and not by us. A device on a client’s network can call itself anything it likes, including something designed to break the program reading it.

So every discovered string is treated as untrusted input everywhere it goes: it is escaped before display, never interpreted as markup, bounded in length, stripped of control characters before it can reach a log line, and quoted properly on its way into a CSV. A device name is data. It is never code.

Privileges

ScanWRX does not ask for administrator, and it does not install a driver. There is no packet-capture filter, no kernel component and no service. It installs per-user by default, into your own profile, where it cannot modify anything the rest of the machine depends on.

This is a real security property, not a convenience one. A tool that needs elevation to look at a network is a tool that can do anything at all to the machine it runs on.

Reporting a vulnerability

Email support@companywrx.com with “security” in the subject. We will acknowledge within two business days and tell you what we intend to do and when.

We will not threaten you for reporting something in good faith. If you find a way to make ScanWRX listen on a port, we want to know before your customer does.