What Vantyris actually does.

A target gets two kinds of attention. The free teaser reads only what's already visible to any internet user: how your padlock is configured, and what protective instructions your site sends to your visitor's browser. No ownership check, no signup, partial answer in seconds. Treat it as a sample.

The verified scan only runs once you've proven the site is yours (DNS record, file, or HTML meta tag, your pick). It adds the email-impersonation and DNS-hijack checks that need your authorisation under UK law before we run them. Today it covers about 70% of the typical small-business hygiene surface; the rest is on the roadmap below. First report in under 60 seconds.

The full report is in plain English, with a "what this means for your business" explanation, a "how to fix it" with who does it and roughly how long, and the technical evidence one click away if you want it. Three PDF layouts ship from the same data: a full editorial document, a single-page executive view for a board pack, and a single-issue work order you can hand directly to whoever does the fix.

Vantyris's posture model is anchored to two public standards. The first is the UK NCSC's External Attack Surface Management (EASM) guidance, which frames the baseline question as "what does the internet see when it looks at us?" That means subdomains, services, certificates, technologies. Every verified target has an attack-surface snapshot pane that answers that question with data from Certificate Transparency logs and DNS.

The second is the OWASP secure-configuration baselines for the categories we check (TLS, HTTP headers, email authentication, CAA). Where two standards disagree (rare), the report cites both and explains the difference.

Each finding card carries a small "References" list with links to the IETF RFC, the NCSC guidance, the CISA KEV entry, or the MDN page that defines what we're flagging. The reader can verify the finding's premise without taking our word for it.

Vantyris is not a certifying body for UK Cyber Essentials. We don't sign certificates, we don't issue the badge. What we do is map each finding to the five NCSC Cyber Essentials control areas (firewalls, secure configuration, security update management, user access control, malware protection) and show on the report which controls each finding informs.

This is useful in the most common preparation pattern: you're putting together a Cyber Essentials submission and you want to know which questions an external scanner can speak to versus which need internal evidence (endpoint posture, policy, training). The alignment section on every verified report draws that line for you.

Each finding carries a confidence rating (high, medium, low) drawn from how deterministic the underlying check is. A TLS handshake either negotiates a deprecated protocol or it doesn't; that's high. A version-banner heuristic could be wrong; that's medium. A finding that depends on what the scanner cannot see from outside (server-side rate-limiting, a WAF rule that fires after several attempts, post-password 2FA) is Medium with explicit caveats. Low-confidence findings carry a visible label so a reader knows where to apply judgement.

Each finding also carries a priority score (0–100) that blends three signals: the severity of the finding, whether the underlying CVE (if any) is in CISA's Known Exploited Vulnerabilities catalogue, and the history state compared to the previous scan (new, recurring, or regressed). A finding that was new last month and got worse this month sorts higher than a finding of the same severity that just appeared.

The findings list defaults to severity order so the report reads naturally, but you can switch to priority order in a single click, or group by category to triage by area of your stack. Within a severity tier, regulatory and data-loss findings (consent missing, data dump exposed, Safe-Browsing listing) surface before pure hardening gaps (HSTS short).

Vantyris is a passive scanner — we read what's already visible to anyone on the open internet about your domain. That covers a lot (TLS posture, response headers, DNS records, exposed paths, third-party scripts, public reputation listings) but it does not cover everything. We're explicit about that in the report, because pretending otherwise is what produces "the scanner said X was a critical High but actually our WAF blocks it" arguments at the client meeting.

Things a passive Vantyris scan can prove from outside the front door: that /wp-login.php is reachable; that no CAPTCHA, bot challenge, or 2FA hint is visible in the rendered page; that DMARC is or isn't published; that /readme.html is or isn't downloadable; that the TLS handshake offers TLS 1.0; that /wp-json/wp/v2/users returns a list of slugs.

Things a passive Vantyris scan cannot prove from outside: that server-side login rate-limiting is absent; that a Cloudflare bot-protection rule won't fire after three failed attempts; that account-level 2FA isn't enforced after the password step; that a WAF won't transparently block the next request. We flag the finding so you know to verify those controls, but we don't claim they don't exist. Findings touching this boundary carry Medium confidence and a "what a passive scan cannot prove" caveat in the evidence pack.

The corollary: if you already enforce those server-side controls, you can mark the finding "Accepted as known risk" with a written reason and the workflow records the call. The 90-day auto-expiry means the suppression doesn't outlive the rationale.

Every finding has a workflow state: open, fixed, accepted as known risk, ignored, or assigned. State transitions are append-only: every change writes a row to a separate history table with the user who made it and the timestamp. The history is what an auditor reads when they want to know "when did you decide this was acceptable, and why?"

Accepted and ignored states require a written reason and auto-expire after 90 days, so a long-running suppression doesn't quietly turn into a forgotten one. Assignments take an email and an optional due date.

Vantyris groups every issue-bearing finding into a four-bucket roadmap: today (fixes the site owner can do this morning), this week (fixes that need developer time or coordination), later (fixes scheduled by lifecycle, like renewals or large upgrades), and acknowledged (findings that need confirmation rather than action). Severity always wins for the first three buckets: anything Critical or High lands in today regardless of how much effort the fix takes.

The Acknowledged bucket is the addition reviewers asked for in the May 2026 wave. Example: your resolved IP belongs to a shared Cloudflare edge that Spamhaus has listed. The listing is real, but it's noise from another tenant on that shared IP — not something you can or should fix. Putting it under Today made the report feel like an emergency over an informational note; Acknowledged keeps it visible without forcing urgency.

Within each bucket, findings are grouped by owner (web host, web developer, DNS admin, domain registrar, email provider, site owner). One person can pick up "everything I need to do" without scrolling past anyone else's work. This is the difference between a list of problems and a list of next actions.

Every finding also carries a typed effort field (5-10 minutes / about 30 minutes / 1-2 hours / developer day / on next renewal / confirm only) so you can plan against your actual calendar, not against vague "low/medium/high" labels.

Every verified report now opens with a Cover, then a one-page Executive Summary aimed at non-technical readers — the partner, the clinic owner, the board member who will read exactly one page and forward the PDF.

The Executive Summary carries: a headline grade and total finding count (with Acknowledged separated out), the top three "biggest wins" severity-sorted with the regulatory/data-loss tiebreak, the projected post-fix grade and score gain from the first realistic fix scenario, and a Business impact in plain English table that maps the top 10 actionable findings to a one-line commercial risk (regulatory complaint risk, brute-force exposure, deliverability drop, full-data-breach trigger, etc.). The detailed evidence and remediation steps live in Section 7.

Every finding in the detailed-findings section now ships an exact, copy-paste fix alongside the prose. WordPress REST API user enumeration gets the full add_filter('rest_endpoints', …) block. HSTS gets the Cloudflare panel path plus Nginx and Apache directives. /readme.html gets the Nginx location = /readme.html { return 404; } rule and the Apache RedirectMatch equivalent. .env exposure gets the web-server deny block.

The intent is the same as the rest of the report — make the next action obvious. The owner forwards the snippet to whoever runs the relevant panel; the panel-runner pastes it; the re-scan documents the closure.

Every verified report includes a typed Attack Surface section answering the NCSC EASM baseline question, "what does the internet see when it looks at this domain?" The section covers IPv4 and IPv6 addresses the domain resolves to, nameservers and their provider hint (Cloudflare, AWS Route53, etc.), MX hosts that receive your email, DNSSEC validation state, CAA issuers, registrar + lock state, domain age, and subdomains discovered through Certificate Transparency logs.

The data is read from the structured detail-JSON the scanner persists, not parsed out of evidence strings. That makes it stable as we add new modules: a new module can extend the surface object without breaking the report rendering.

We run scan jobs in isolated containers with strict egress allow-lists. A worker can reach the public-internet target IP and approved third-party APIs, that is all. It cannot reach private IP ranges (RFC 1918), link-local addresses, the cloud-metadata endpoint at 169.254.169.254, loopback, or CGNAT space.

We re-resolve DNS mid-scan and abort if the IP suddenly changes (a DNS-rebinding pattern). We apply per-target, per-workspace, and per-IP rate limits to remain a polite citizen of the internet.

We never run exploit frameworks, credential stuffing, brute force, or fuzz testing. We never run Nuclei's code, headless, or fuzz template paths. We only run pinned, signed template bundles that we have reviewed.