The **Scans** screen has two tabs: Scans and Schedules.

## Scan types

| Type | What it does |
| --- | --- |
| **Discovery** | Expands your seeds to find assets. Creates no vulnerability findings. |
| **Full** | Discovery plus evaluation — produces findings. |
| **Validation** | Re-collects HTTP and TLS evidence and re-runs safe checks against existing assets. No new discovery. |
| **Continuous discovery** | Discovery on an ongoing cadence. |

Use **Discovery** when you're building inventory and don't want finding noise. Use **Full** when you want the complete picture.

### The Intrusive option

Intrusive is **not a separate scan type** — it is a tick you add to a Full scan. An Intrusive run does everything a Full scan does, plus two checks that are otherwise held back:

- **TCP port checking** against a curated port list
- **Template scanning** to confirm exposures rather than infer them

You can only tick it for an organisation that has a valid **scan authorization** on file — a signed statement, with a named signer and an expiry, recorded on the organisation's settings page. Without one, the option is refused; the server enforces this, not just the interface.

Schedules can be Intrusive too, and are checked against the same authorization when they fire.

See [Security and acceptable use](security-and-acceptable-use) for exactly what these checks do.

## Scoping a scan

You don't have to scan everything every time:

- **Discovery on selected seeds.** Select specific seeds and run discovery on just those, rather than every seed in the organisation.
- **Full scan on selected assets.** Target a chosen set of existing assets; nothing new is discovered.
- **Single-finding rescan.** Open a finding and use **Rescan** to re-run only the checks relevant to it. See [Working with findings](working-with-findings).

## How a scan works

Every scan moves through four phases, shown in the "How Scans Work" panel:

1. **Seed normalization** — validates and normalizes your seeds into assets, and applies your scan exclusions. If your organisation requires domain verification, unverified domain seeds are skipped here.
2. **Collection** — gathers data from DNS, Certificate Transparency, passive DNS, internet registries, internet-wide scan data, TLS handshakes and HTTP headers. New candidates go through the confidence gate.
3. **Evaluation** — infers your technology stack from the collected evidence, then evaluates that evidence for misconfigurations and correlates public CVEs. Skipped for discovery-mode scans.
4. **Finalization** — records score factors, writes the coverage record and builds the relationship graph.

## Two verdicts, not one

A finished scan tells you **two separate things**, and it matters that you read them separately:

- **Status** — did the scan finish? `Completed`, `Failed`, `Cancelled`.
- **Assessment quality** — how much did it actually assess? `Complete`, `Completed with gaps`, or `Inconclusive`.

A scan can legitimately be **Completed** *and* **Inconclusive** at the same time. That is not a contradiction — it means orchestration ran to the end but too little of your estate was actually assessed to draw a conclusion from. A scan where most assets returned nothing usable is reported that way rather than shown as a clean bill of health.

Every gap carries a plain-language reason: an asset outside your active scan scope, one matching your own exclusion policy, a check with no coverage for that asset type, an optional data provider that was unavailable, or a check that finished without usable evidence. The coverage record is written once when the scan ends and never changes afterwards, so a scan you read today says the same thing next quarter even if your scope or exclusions have moved on.

Scans that ran before this feature existed show their status alone, with no quality badge. Nothing reconstructs coverage for them — an honest absence beats a confident guess.

## Watching a scan

Scan cards show status, organization, type, timestamps, how many collection steps ran, and how many findings resulted. The list polls automatically every 5 seconds while anything is pending or running, so you don't need to refresh.

Open a scan to see per-step status — useful when one data source is unavailable. Most collection steps **degrade rather than fail**: if Certificate Transparency is unreachable, the scan continues without it and reports that step as degraded.

From the scan detail you can **Stop** a running scan, or **Restart** it. Restarting runs the scan from the beginning — there is no resume.

Filter by status (pending, running, completed, failed, cancelled) and by organization.

### Muting a noisy check

Some checks fail repeatedly for reasons you already understand and cannot change — a host that always times out, a provider that never returns data for one asset. You can **mute** a check so its failures stop drawing attention.

A mute is a standing rule tied to an organization, optionally a specific asset, and one check. It is idempotent, so muting the same thing twice just keeps the existing rule.

> A mute changes only how a failed check is **surfaced afterwards**. It does not change how the scan runs, and it does not make the check pass — the run still records what actually happened, and coverage still counts it as a gap. It is a way to quiet a known problem, not a way to hide one.

## Comparing scans

Switch to compare mode and pick two completed scans. The diff panel shows what changed between them — findings opened and closed, assets added and removed. This is the fastest way to answer "what changed since last week?"

## Scheduling

On the **Schedules** tab, create a schedule with an organization, a frequency and a scan type:

- **Daily** — 02:00 UTC
- **Weekly** — Sundays, 02:00 UTC
- **Monthly** — 1st of the month, 02:00 UTC

Each schedule can be enabled, disabled or deleted. If a scan is already pending or running for that organization and type, the scheduler skips that cycle rather than stacking runs.

## Scan exclusions

Exclude specific hosts or patterns from scanning — useful for third-party-hosted assets or systems under change freeze. Rules support exact match or hostname-suffix match, an optional asset-type filter, a required reason and an optional expiry date.

There's a preview tool: enter a hostname and it tells you whether your current rules would exclude it.

Anything excluded still shows as a gap on the scan's coverage record, so an excluded estate never reads as fully assessed.