What Vantyris actually does.

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

The verified scan only runs once you've proven the site is yours, with a DNS record, a file or an HTML meta tag. It adds the email-impersonation and DNS-hijack checks, which need your authorisation under computer-misuse law before we run them. The first report arrives within about 90 seconds.

The full report is in plain English. Each finding says what it means for your business and how to fix it, including who should do the fix and roughly how long it takes, with the technical evidence one click away. Three PDF layouts come from the same data: the full report, which opens with a one-page executive view for a board pack; a work order for one issue, to hand straight to whoever fixes it; and a compliance report for an auditor or insurer.

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?" In practice that means subdomains, services, certificates and technologies. Every verified target has an attack surface panel that answers the 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 the two standards disagree, which is rare, the report cites both and explains the difference.

Each finding card carries a short "References" list linking to the IETF RFC, NCSC guidance, CISA KEV entry or MDN page that defines what we're flagging. You can check the premise of a finding without taking our word for it.

Vantyris is not a certifying body for UK Cyber Essentials. We don't sign certificates or 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 touches.

That helps when you're putting a Cyber Essentials submission together and want to know which questions an external scan can answer. Endpoint posture, policy and staff training still need internal evidence. The alignment section on every verified report draws that line for you.

Each finding carries a confidence rating, high, medium or low, based on how deterministic the check is. A TLS handshake either negotiates a deprecated protocol or it doesn't, so that's high. A guess from a version banner could be wrong, so that's medium. A finding that depends on something the scanner can't see from outside, such as server-side rate limiting, a WAF rule that fires after several attempts, or 2FA after the password step, is Medium with the caveats spelled out. Low-confidence findings carry a visible label, so you know where to apply judgement.

Each finding also carries a priority that weighs its severity against real-world exploitation (CISA's Known Exploited Vulnerabilities catalogue) and against your history: whether it is new, recurring or getting worse since the last scan.

The findings list defaults to severity order so the report reads naturally. One click switches it to priority order, or groups it by category so you can work through one area at a time.

Vantyris is a passive scanner. We read what anyone on the open internet can already see about your domain. That covers a lot (TLS setup, response headers, DNS records, exposed paths, third-party scripts, public reputation listings), but not everything. The report says so plainly. Pretending otherwise is how you end up arguing at a client meeting that "the scanner said High, but our WAF blocks it".

From outside the front door, a passive Vantyris scan can prove these things:

• /wp-login.php is reachable.
• No CAPTCHA, bot challenge or 2FA hint is visible in the rendered page.
• DMARC is, or isn't, published.
• /readme.html can, or can't, be downloaded.
• The TLS handshake offers TLS 1.0.
• /wp-json/wp/v2/users returns a list of slugs.

It cannot prove that login rate limiting is missing on the server, or that a Cloudflare bot rule won't fire after three failed attempts. It can't see whether 2FA kicks in after the password step, or whether a WAF will quietly block the next request. We flag the finding so you know to check those controls, but we don't claim they're absent. Findings on this boundary carry Medium confidence and a "what a passive scan cannot prove" caveat in the evidence pack.

So if you already enforce those controls, mark the finding "Accepted as known risk" with a written reason, and the workflow records the decision and the reason behind it.

Every finding has a workflow state: open, fixed, accepted as known risk, ignored or assigned. Each change adds a row to a separate history table, with who made it and when, and nothing in that table is ever edited. It's what an auditor reads when they ask "when did you decide this was acceptable, and why?"

Accepted and ignored states require a written reason, which stays on the finding and in its history. Assignments take an email and an optional due date.

Vantyris puts every finding that needs work into one of four buckets. Today holds fixes the site owner can make this morning. This week holds fixes that need developer time or coordination. Later holds fixes tied to a lifecycle event, like a renewal or a big upgrade. Acknowledged holds findings that need a check rather than a fix. Severity always wins: anything Critical or High goes in Today, however much effort it takes.

Say your site resolves to a shared CDN address that a blocklist has listed. The listing is real, but it comes from another tenant on that shared address, and it's nothing you can or should fix. Filed under Today it would make the report feel like an emergency over an informational note. Acknowledged keeps it visible without the alarm.

Within each bucket, findings are grouped by owner (web host, web developer, DNS admin, domain registrar, email provider, site owner). Each person can pick up everything they need to do without scrolling past anyone else's work. That turns a list of problems into a list of next actions.

Every finding also carries an effort estimate (5-10 minutes, about 30 minutes, 1-2 hours, a developer day, at next renewal, or confirm only), so you can plan against a real calendar instead of vague "low/medium/high" labels.

Every verified report opens with a cover and then a one-page Executive Summary for non-technical readers: the partner, the clinic owner, the board member who will read exactly one page and forward the PDF.

It shows the headline grade and the total number of findings, with Acknowledged counted separately. It lists the three biggest wins, sorted by severity and then by regulatory or data-loss risk, and the grade and score you'd get after the first realistic set of fixes. Last comes a Business impact in plain English table that gives each of the top 10 findings a one-line commercial risk, such as a regulatory complaint, brute-force exposure, emails landing in spam, or a full data breach. The detailed evidence and fixes follow.

Every finding in the detailed findings section comes with an exact fix you can paste 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 aim is the same as the rest of the report: make the next action obvious. The owner forwards the snippet to whoever runs the panel, they paste it in, and the re-scan records the fix.

Every verified report has an Attack Surface section that answers the baseline question in the NCSC's attack surface guidance: what does the internet see when it looks at this domain? It lists the IPv4 and IPv6 addresses the domain resolves to, the nameservers and who runs them (Cloudflare, AWS Route 53 and so on), the MX hosts that receive your email, the DNSSEC state, CAA issuers, the registrar and whether the domain is locked, domain age, and subdomains found in Certificate Transparency logs.

The scanner talks only to the public internet. Every request it makes is checked first, and it refuses to reach private networks, a cloud provider's internal services or an address that changes in the middle of a scan.

Requests are time-limited and spaced out, so a scan never floods your server. We never run exploit tools, password guessing, brute force or fuzz testing.