The summary tells you whether something needs attention. The full report tells you which machines, which addresses, and which ports, which is what anyone actually fixing it needs.
Summary and full report
A free scan needs no account and no email address. You get the score, the key findings, the counts, and example evidence.
The full report adds what the example evidence leaves out: the complete affected-host and endpoint lists, the certificate inventory, and the exports. Reading your report covers how to work through them. That matters when a finding covers more endpoints than the one shown, which is most of the time on a real domain.
The purchase flow shows the price before checkout. A fresh report can be unlocked directly; an older one can offer a paid retest so that what you buy is current evidence rather than a snapshot from last quarter. Always use the price shown in the flow rather than an old screenshot or exported report.
The link is the access
This is the part worth reading twice.
A normal report link opens the summary unless the viewer already has full access. The full-report link delivered after purchase carries that access with it. Forward it and you have forwarded the access, to anyone who ends up holding it.
So treat links containing access tokens exactly like credentials. Keep them out of public tickets, public repositories, and public documentation. Deciding who should see your infrastructure’s weak points is a separate decision from deciding who to send a URL to, and the URL will not make it for you.
A signed-in account with qualifying access can also open its purchased reports without passing links around, which is usually the better route for a team.
Pick the export that fits the job
| Format | Good for |
|---|---|
| CSV | Assigning affected hosts and endpoints to owners. Sorts and filters in a spreadsheet |
| Markdown | Attaching to a ticket or keeping alongside an assessment |
| JSON | Feeding the underlying report data into your own tooling |
Which controls appear depends on your report access and on what data that report actually holds.
Whatever you export, carry the domain, the scan date, and the finding context with it. A bare list of IP addresses, with no hostname and no observed behavior, is how somebody ends up reconfiguring the wrong server.
Keep the evidence with the work
Send the smallest relevant slice to the person who owns that TLS terminator, DNS zone, or mail service. Ask them to record what changed and when.
Then confirm with a fresh report rather than a reply. Fixing and retesting covers that loop.