Skip to content

All about standards scans

A standards scan checks one of your domains against the open internet standards — TLS configuration, DNSSEC, HSTS, IPv6, CAA, security.txt, the modern HTTP security headers, and more.

Wondering what gets checked, why it matters, and how to turn it on? This article explains the toggle, the test set behind it, and the organisational reasons compliance is worth bothering with.

Cyberfusion is the only host doing this proactively

Most hosting providers leave standards compliance to you: if you want to know whether your site is compliant, you run a scan yourself, read the report, and act on it. If you have ten domains, that's ten manual checks. If a setting drifts (a certificate is reissued with the wrong ciphers, an HSTS header is dropped during a refactor), nothing tells you — until someone runs the scan again.

Cyberfusion is — as far as we know — the only managed host that scans its customers' domains for standards compliance automatically. With 'Standards Scans' enabled on a domain router, the domain is included in Cyberfusion's regular scan runs. Configuration drift shows up in the next scan, instead of waiting for someone to remember to run a manual test.

A 100% score is achievable

Cyberfusion is in the public Hall of Fame for hosters that score 100%.

Tests that pass regardless of per-domain settings

Some of the standards are network- or platform-level, not per-domain. On Cyberfusion these tests pass for every hosted domain — there is no toggle:

  • RPKI — proves to other networks that the IP routes for our network belong to us, so an attacker can't redirect traffic by announcing a fake route. Signed across the entire Cyberfusion network.
  • IPv6 reachability — webserver nodes and nameservers are dual-stack.
  • DNSSEC — zones served by Cyberfusion's nameservers are signed.
  • Modern TLS, ciphers, key-exchange parameters — the webserver config rules out the obsolete protocols (SSLv2/3, TLS 1.0/1.1) and weak ciphers.

The remaining points are things you control on the domain router or in the application: the attached certificate, HTTP security headers, CAA records, and the security.txt policy.

Why standards compliance matters

The "internet standards" aren't an abstract checklist — each one fixes a specific real-world problem:

  • HTTPS, HSTS, modern TLS, DANE — without these, an attacker on the network between your visitor and your server can read or change what's transmitted. Banking details, login cookies, form data.
  • DNSSEC — without it, an attacker can poison DNS and silently send your visitors to a fake copy of your site.
  • CAA records — limit which certificate authorities are allowed to issue a certificate for your domain. Without one, any CA in the world can issue a cert for you, and a compromised CA has happened more than once.
  • IPv6 — visitors on IPv6-only networks (some mobile carriers, large parts of Asia) literally cannot reach an IPv4-only site.
  • security.txt — see All about security.txt policies. Without it, researchers who find a bug don't know who to tell.
  • CSP, Referrer-Policy, X-Content-Type-Options, X-Frame-Options — HTTP headers that block common browser-side attacks (clickjacking, content sniffing, leaking the user's previous URL to a third party).

Organisational reasons to score well

Beyond the security benefit, standards compliance is often a hard requirement when you sell to certain customers:

  • (Semi-)government in the Netherlands — the Dutch government's "apply or explain" list of mandatory open standards is published by Forum Standaardisatie. Government bodies (and companies that supply them) are required to comply or document why they don't.
  • EU public sector tenders — increasingly cite the eIDAS regulation, NIS2, or member-state security baselines. A failing standards scan is an easy point against your bid.
  • Healthcare, finance, education — sectors with their own security baselines (NEN 7510, BIO, ISO 27001) often reference these same standards. A passing scan is one of the cheapest pieces of evidence you can produce during an audit.
  • Public procurement scorecards — some governments publish supplier scores publicly.

Where to find the toggle

Open a domain router in Core. The 'Standards Scans' tile sits next to 'Force SSL' and 'QUIC' in the top row of toggles. Click 'Enable' to opt the domain into scans, 'Disable' to opt out.

New domain routers — whether you create one yourself or one is created for you by a virtual host, URL redirect, or n8n instance — have 'Standards Scans' enabled by default.

What gets scanned

The scan covers (non-exhaustive):

  • Transport security — IPv6 reachability of webserver and nameserver, DNSSEC validation, HTTPS availability, HTTP-to-HTTPS redirect, HSTS (and its policy parameters), TLS protocol versions (no SSLv2/3, no TLS 1.0/1.1), cipher suite selection, key exchange parameters, OCSP stapling, certificate trust chain, hostname match, DANE/TLSA records.
  • Domain configuration — CAA records.
  • HTTP security headers — Content-Security-Policy, Referrer-Policy, X-Content-Type-Options, X-Frame-Options.
  • security.txt — presence and validity of the file at /.well-known/security.txt. See security.txt policies.

Turning scans off

There are legitimate reasons to opt out:

  • The domain is internal-only and never reached over the public internet — the scan can't reach it and would always fail.
  • The domain points at a third-party service (a status page, a marketing tool) whose configuration you don't control.
  • You're running an experiment and don't want failing results to show up while you're mid-change.

Disable the toggle on the domain router and the domain is dropped from the next scan run.