Data the sensor sends
The sensor sends one message type: a scan report. Nothing else. The structure
below is the wire contract, and it is published as a .proto file in the sensor
repository so this page can be checked against the code.
Per certificate
Section titled “Per certificate”| Field | Example | Notes |
|---|---|---|
| Certificate (DER) | binary | The certificate as presented, base64/DER - public data by definition |
| Chain | binary | Intermediates presented by the server |
| Observed IP | 10.20.4.10 |
Where it was found |
| Observed port | 443 |
|
| Observed hostname | www.example.com |
Resolved or configured target |
| Served SNI | www.example.com |
SNI sent during the handshake |
| Protocol | PROTOCOL_HTTPS |
How it was reached |
| Timestamp | 2026-08-10T13:46:00Z |
When observed |
Per report
Section titled “Per report”Sensor identity, machine ID and the scan cycle’s start and end. The tenant is not in the payload - it comes from the mTLS client certificate, so a sensor cannot claim to belong to a different tenant.
What is never sent
Section titled “What is never sent”- Private keys. Not the sensor’s own, and not the scanned services’ - those it never has access to.
- Application data. No HTTP bodies, headers, mail contents or credentials.
- Host inventory beyond certificates. No process lists, no installed software, no user accounts, no file contents.
- Network topology. Only the addresses where a certificate was actually found, not a map of what else exists.
Your internal addresses do leave
Section titled “Your internal addresses do leave”Be aware of what the first row of the table means: observed IPs and internal hostnames are transmitted and stored, because “which host serves this certificate” is the product’s core question. If a hostname is itself sensitive, exclude that range - an excluded target is never contacted and never reported.
Data location
Section titled “Data location”Reports land in the region your tenant is pinned to (eu or us) and stay
there. Regions do not replicate to each other.