Trust · Last updated 5 October 2026

What ClearVisibility does on your network

ClearVisibility collects an inventory of your IT estate. Anything that does that looks, from a packet capture or an EDR console, a lot like something you would not want on your network. You are entitled to know exactly what it does, what it refuses to do, and what leaves your premises.

Why this page exists

We publish this because the alternative is that you work it out from logs and alerts, and arrive at the worst available interpretation. Everything below was checked against the source of the shipping build. Where a claim could not be checked, it is not here.

Two things this page deliberately does not do. It does not claim a control the product does not enforce, and it does not soften anything a security team would reasonably object to. Those objections are written out under things you may not like, because a page that reads as reassurance is worth nothing to the person whose job is to doubt it.

The short version

Does it sweep our network for hosts? Not unless you switch it on and tell it which ranges. It is off in every install we ship.
Does it ever pick its own targets? For two Windows inventory collectors, yes, from machines it has already found in your directory. In full below.
Does it scan the internet? No. Public address space nobody configured is refused outright.
Does it check our domains without being asked? No. A domain is checked only after a person adds it.
Does our inventory leave the network? No. There is no outbound path for it anywhere in the product.
What does leave? Registration and licensing details, and lookups about domains you added. Listed in full below.
Does it update itself? Yes, if you register it with our update service. Packages are signed, and an unsigned one is refused.
The desktop edition? Listens on 127.0.0.1 only, and has no network discovery at all.

Nothing scans because the product decided to

Every collection path needs one of these first:

a configuration value a person entered, such as a network range, a WMI credential, a Configuration Manager connection string, an SNMP community or a domain name;
a sign-in a person completed, for the Microsoft 365, Entra, Intune and Azure connectors;
or a file a person uploaded.

Where a collector can pick its own targets, it is named as such below, with the cap and the source of the target list. We regard "it chose its own targets and nobody was told" as a defect, not a feature.

The discovery collectors

Discovery runs on the server edition only. It is one daily pass, at 13:00 local time in the install we ship. Each collector is independent, and a collector with nothing configured does nothing and says so in the discovery log.

Active Directory

Reads your directory over LDAP, on TCP 389. It enumerates computer objects (hostname, operating system, organisational unit, last logon) and user objects (identity, department, group membership, last logon). It is a read. Nothing is written back and no group membership is changed.

If the server is domain joined and you have set nothing, it binds to its own domain. The settings only narrow that: a specific domain controller, a different domain, a particular organisational unit, or a named account.

WMI and WinRM

Queries Windows machines for hardware, operating system, security posture, installed software from the registry uninstall keys, and running processes. Only enumerations are issued. Nothing is written, and no agent or software is installed on the target.

This collector picks its own targets when you have not given it a list. It takes up to 100 Windows machines that discovery has already found, seen in the last 30 days, newest first. Those machines come from the directory read above, not from a network sweep. It can be switched off or replaced with an explicit list.

It needs credentials that can read WMI on the target, and it needs WinRM (TCP 5985 or 5986) or DCOM (TCP 135 plus the dynamic RPC range) reachable. It is the ordinary Windows management path, which is also why it is visible to your monitoring.

Configuration Manager

Reads your Configuration Manager site database through its reporting views, over a read-only login you supply, on the port in the connection string you give it. It is dormant until you give it that connection string, and it exists so a managed estate is read from the system that already manages it instead of being scanned again.

SNMP

Reads managed switches, routers and printers: system and interface identity, the bridge forwarding table, VLAN tables and ARP tables, so other assets can be located to a port and a VLAN. GET and GET-NEXT only, never SET. Dormant until you list targets and provide a read community or v3 read-only credentials. It never picks its own targets.

Application usage, from the Windows SRUM database

This one deserves a paragraph of its own, because it is the heaviest thing the product does and we would rather you heard it from us.

Windows records per-application resource usage in a database called SRUDB.dat. A system service holds it open exclusively, so it cannot be copied in place. To read it, this collector runs esentutl on the target machine through WMI process creation, which writes an unlocked copy into the target's Windows temp folder, and then reads that copy back over the C$ administrative share, on TCP 445.

That is process execution, plus a temporary file, plus an SMB pull, on your machines, from a privileged account. Your EDR will see it, and it is right to. Nothing on the target is modified beyond the temporary copy, and the collector declares itself as not read-only for exactly this reason.

In the install we ship, this collector is enabled with no targets, and it will pick its own: up to 25 Windows machines that discovery already found, seen in the last 30 days. You can disable it, give it an explicit target list, or turn off its self-targeting. We are not comfortable that the heaviest collector self-targets by default. It is on the list to change, and until it does, this page says so.

Network scan

Off in every install we ship, both editions. The collector is not even registered with the application unless a site sets its enable flag, and it has shipped off since August 2026. The continuous fifteen-minute sweep loop is a second flag, also off.

When a site does switch it on, what it does is: ICMP echo, a read of the local machine's own ARP cache, and TCP connect probes to a short list of ports (22, 80, 135, 139, 161, 443, 445, 515, 631, 3389 and 9100 by default). A connection is opened and closed immediately. Where a service announces itself on connect, the first 256 bytes of that announcement are read. Nothing is sent to the service and nothing is written to any host. No exploit is attempted, no credential is tried and no vulnerability is probed. The scan records what answered, and never asserts that something is absent.

Concurrency and timeouts default to the most conservative of three profiles.

What a network scan is allowed to sweep

The ranges a scan may touch are decided by a policy, not by whatever the machine happens to be plugged into. The policy judges each range on two things together: where the range came from, and what address space it is in.

Configured by your administrator, private address space. Scanned. Typing it is the confirmation that it is wanted.
Configured by your administrator, public address space. Scanned, with a warning recorded in the discovery log. You named it, and an organisation scanning address space it owns is a legitimate case.
Derived from the server's own network card because nothing was configured, private address space. Scanned, and the log records that the scope was derived rather than confirmed, and names the setting to state it properly.
Derived from the server's own network card, public address space. Refused. Nothing is sent.

The last one is the one that matters. A server with a public address used to sweep whatever subnets its own interfaces sat on. That would mean the product port-scanning a block of the internet belonging to other people, with no range ever typed by anybody. It now refuses. A site that genuinely owns public address space can permit it with a setting, and setting that key is itself the statement of authorisation.

Three details a reviewer will want:

RFC 1918 space, loopback, link-local and RFC 6598 carrier-grade NAT all count as private. Address space reserved for documentation counts as public, because reserved is not the same as yours.
A range is masked to its network address before the private test, so a single address written with a prefix is judged on the network it names.
Anything wider than a /16 is refused with an explanation, rather than silently dropped.

Every refusal and every warning appears in the discovery log and in the collector's health detail on the connectors console, so a scope problem is visible before a run rather than after one returns nothing. The policy is unit-tested, with each reserved block pinned from both sides so an off-by-one at a boundary cannot admit a neighbour's network. It has not been watched on a server with a public address, because the machine it was written on does not have one.

The external threat checks

These look at your internet-facing surface: certificates, DNS and email posture, dangling DNS records, look-alike domains, domain registration state and public credential breaches.

Nothing is checked on the product's own initiative. A domain is in scope only when a person put it there, by one of exactly two routes: your administrator entered it in configuration, or somebody added it on the external threats page. With no domain in scope, a run calls no source at all.

The product will suggest domains it can see, from your users' email addresses, from the address fields in setup, and from the domain the server is joined to. A suggestion is not a scope entry, and suggestions are never checked until somebody accepts one. Domains are used exactly as entered and are never shortened to a parent domain, a public suffix such as co.uk is refused outright, and personal webmail domains are refused as scan seeds. Removing a domain from scope deletes its stored findings.

Most of these checks are passive: they ask third-party databases about your domains rather than touching your servers. The genuinely active ones are port scanning, nmap service detection, nuclei web templates, and the TLS and security header checks. Those exist on the server edition only, their master switch and every individual check default off, and they additionally require the specific domain to be on an explicit authorisation list before a single packet is sent. That check is in one shared place, so a new source cannot forget it. On a fresh install the authorisation list is empty, so active scanning cannot run.

In the install we ship, the daily external threat re-scan is off as well.

What leaves your installation

To us, the ClearVisibility update and licensing service

Registration, once. Your organisation name, the contact email address you type in, the name of the machine it is installed on, a randomly generated installation identifier, a one-way hash of the machine name and that identifier, and the product version. The server edition also sends the Windows domain name you type into the setup screen. No estate data.
The licence check, daily. Your site reference and your installation identifier, with your installation's own access credential, to fetch this site's signed entitlement document. It sends no body and no version. An installation that has never paid has no entitlement record, and the check does nothing at all.
Update checks. The server edition's update pull carries your installation's access credential and nothing else: no body, no identifier. The desktop edition's update check carries no credential at all and is genuinely anonymous, because the desktop ships no secret and the code signature is the trust anchor instead.
The vulnerability data feed. A request for the current snapshot and its files. This is a download. We are not told what software you have.

That is the complete list. No inventory, no asset record, no user record, no device name other than the one it is installed on, no serial number, no installed-software list and no finding is ever sent to us. There is no usage telemetry and no analytics in the product or in its web interface, in either edition, so there is nothing to switch off. The application's own pages load no fonts, scripts, trackers or images from anyone else's servers. The one exception is the payment form, which loads from Paddle only when you choose to buy.

The installation identifier is a random value created when the software first runs. It is not derived from your hardware, your Windows account or your network. We compare the identifier on each licence check against the one your licence was issued to, and when they differ we record that a licence appears to be in use on more than one installation. We do not refuse the licence when that happens, because replacing a machine is an ordinary thing to do.

To third parties, only about domains you added

When an external threat check runs for a domain in scope, these are contacted. All are free and keyless, and all are on when a check runs:

crt.sh, the domain name, to read published certificate transparency logs.
Google public DNS over HTTPS, the domain and host names being resolved. If your policy requires a specific resolver, note this in review.
login.microsoftonline.com, the domain name, to detect a Microsoft tenant.
The IANA registry directory and your domain's own RDAP registry, the domain name.
Cloudflare, Fastly, Amazon and Imperva, nothing about you. Their published IP range lists are downloaded.
Your own mta-sts host, nothing about you. Your own published policy file is fetched.
Look-alike domains, a request to the look-alike's own front page. Never to your servers.

These are contacted only if somebody configures them with a key or a flag, and none of them is contacted on an install nobody has changed:

Shodan InternetDB, IP addresses resolved from your domain. Off since 5 October 2026. It was the one keyless source in this list that used to be on, and it was withdrawn because its terms require a commercial licence we have not taken. Switching it back on is an attestation that you hold one.
Shodan, domain and host names. Off, and needs an API key.
Have I Been Pwned, the domain name only. Off, and needs a paid API key.
GitHub code search, search terms derived from your domain. Off, and needs a token.
A public breach database, each employee email address, individually, in the request URL. Off.

The last one is the row to read twice. That check sends real email addresses of real people to a third party, one address per request. It is personal data leaving your organisation, it is relevant to your data protection position, and that is precisely why it ships switched off and why switching it on is a deliberate act. The product's own documentation says so where the switch is, and tells you to confirm your privacy notice and your lawful basis first. If you turn it on, that is your decision to record, not ours.

To public reference feeds

Both editions download public catalogues so the product can interpret what it finds locally: the end-of-life catalogue, the Microsoft Security Update Guide, the CISA known-exploited vulnerability list, and the ENERGY STAR certified-computers dataset. These are downloads. Nothing about your estate is sent to any of them.

One disclosure for proxy and EDR teams: the ENERGY STAR download deliberately sends a browser-style User-Agent, because the government host blocks non-browser clients and a product token gets the whole feed blocked. A proxy that inspects User-Agent may flag it as a mismatch. It is expected behaviour, not evasion. Every other reference call identifies itself honestly as ClearVisibility.

To Microsoft and ServiceNow, when you connect a tenant

The Microsoft 365, Entra, Intune and Azure connectors read your own tenant with your own sign-in, through Microsoft's published APIs. ServiceNow is read through an OAuth client you create in your own instance, and what it can see is governed by that client's roles inside ServiceNow. In every case the data flows from them into your ClearVisibility installation. It does not pass through us.

Nowhere, in the case of diagnostics

The support diagnostics bundle is a zip file written where you choose, with every configuration value whose name looks like a password or a token masked out. It never contains the database itself or the stored database password. Nothing uploads it. If you want us to see it, you send it. The logs inside it can name devices and users from your estate, and the file says so in its own first lines so you can read it before deciding.

Our support staff cannot reach into your installation. Where a support case needs elevated access, we issue a signed key that somebody at your end pastes in. We cannot apply it remotely, and it expires.

The ports and addresses to allow out

Everything the product sends to the internet is HTTPS on TCP 443. There is no other outbound protocol and no other port, with two exceptions you configure yourself: your own SMTP host, on whichever port you give it, and your Configuration Manager database, on the port in your connection string.

For full default functionality on a server, the destinations are: endoflife.date, data.energystar.gov, api.msrc.microsoft.com and www.cisa.gov for reference data; crt.sh, dns.google, login.microsoftonline.com, the IANA RDAP directory and your own domains' registries for the passive threat checks, together with the published range lists at cloudflare.com, api.fastly.com, ip-ranges.amazonaws.com and my.imperva.com; our own licence and update service if you registered the site; and graph.microsoft.com, management.azure.com, api.securitycenter.microsoft.com and Azure blob storage if you connect a Microsoft tenant.

On your own network, each discovery collector uses its own protocol's ordinary port: TCP 389 for the directory read, TCP 5985 or 5986 for WinRM, or TCP 135 plus the dynamic RPC range for DCOM, UDP 161 for SNMP, and TCP 445 for the application-usage copy. If you switch the network scan on, it opens short-lived TCP connections to its configured port list.

A site with no outbound access at all still works. The reference feeds, the threat checks and the licence check each fail quietly, keep the data they already have, and retry later. Setup completes on a grace licence when the licence server cannot be reached.

This list was built by reading the product's own code and shipped configuration, not by watching a running install with a packet capture. We say so because the two are not the same evidence, and a reviewer should know which one they have.

The desktop edition

The single-user desktop edition is a local application, and the differences are enforced in the server-side code rather than by hiding buttons.

It binds to 127.0.0.1 only. It is never a network listener. The port is configurable, and the build's own validation gate asserts the binding the host actually resolves rather than matching a line of source.
It has no network discovery, and no discovery at all. The whole discovery interface returns "not found" on this edition, refused in the application at a single choke point that a new endpoint cannot bypass by being forgotten. The network scanner is not registered on it. There is no path, interface or setting that makes the desktop edition scan a network.
A loopback binding is not by itself a boundary, and we do not present it as one. Any page open in your browser can reach 127.0.0.1, and this edition authenticates requests as the logged-in Windows user with no credential, because the single user is the administrator of their own install. What makes the boundary real is two checks: the host must be a loopback literal, which defeats DNS rebinding, and a request issued by a page on another origin is rejected, which is the cross-site write path.
Connector sign-ins are held in memory only. Nothing that could reach your Microsoft tenant survives closing the application. You sign in, the collection runs, and the next collection asks again.
The external threat checks are available here, passive only. The active scanners do not exist in this edition's code.
The database is a private PostgreSQL under your own local application data folder. When you uninstall, you are asked whether to delete it. A silent or managed uninstall keeps it, so an automated reinstall does not destroy your data.

Updates, and the code you run

Installers and application executables are signed with Azure Trusted Signing. The build refuses to complete if any executable in the package is unsigned, including redistributable components, and it re-checks after signing rather than assuming.

Release packages carry a manifest with a per-file hash, and a detached signature over the manifest's exact bytes. Your site verifies that signature against a public key embedded in the build before it trusts any hash inside the manifest, then checks every downloaded file against its hash before extracting it. A bad signature is refused, a signature from a key this build does not trust is refused, and a missing signature is refused too, which is the load-bearing half: refusing only a bad signature would buy nothing against somebody who can simply omit one. The SQL and data applied to your database go through the same hash enforcement as the binaries. The one case that warns rather than refuses is a build of ours that shipped with no public key embedded at all, because refusing there would strand a site over our own mistake.

A registered install applies updates on its own, by default: it stops the service, swaps the build, starts it, health-checks it, and rolls back automatically on failure.

An installed site runs one file ingester, inside the application itself. The separate upload service that older ClearVisibility sites ran is never installed.

Things you may not like

A trust page that only contains good news is a brochure. These are the things we expect a security team to object to, written out rather than left to be discovered.

The server edition listens on plain HTTP, on all interfaces, on the port chosen at install. There is no HTTPS binding and no certificate in the shipped configuration. Putting TLS in front of it is your job, and until you do, session cookies travel in clear on your network. The product is built so the session cookie becomes secure and HSTS starts being sent automatically the moment it is served over TLS, with nothing to configure. We have not served it over HTTPS ourselves, so that behaviour is implemented and unobserved.
The application usage collector self-targets by default, and its footprint is the heaviest thing here. It is set out in full above. We think the default is wrong and intend to change it.
The WMI collector self-targets by default, up to 100 machines. Read-only, but still a credentialled connection to machines nobody named.
Discovery runs with the privileges of the account you give it. There is no privilege separation inside the product. If you hand it a domain administrator, it has one. Give it the least-privileged account that can read what you want read.
There is no authorisation attestation screen. The scope policy above removes the worst case, which was scanning address space nobody named, and typing a range is treated as the statement of intent. Nobody is asked to confirm they are authorised to scan the network they typed. We regard that as not yet done.
The network scan policy has never been watched on a server with a public address. It is unit-tested, thoroughly, and unobserved in that specific case.
Antivirus allow-listing with the major vendors has not been done. Binaries are signed, which helps and is not the same thing. If your endpoint protection quarantines us, that is currently your ticket and ours, not something we have pre-empted.
Connector secrets are not yet encrypted at rest. Discovery credentials are. Microsoft and ServiceNow client secrets are held in the product's own property store without encryption, which is a known hardening item. Protect the database and the server accordingly.

How this page relates to our other policies

Our privacy policy covers this website and what happens when you buy: enquiries, analytics and the payment path through Paddle. It puts data processed inside the product outside its own scope, which is the gap this page fills. Nothing here contradicts it.

If you need something that is not answered here, ask. We would rather write it down than have you infer it.