Scanning a host you do not control is, in many jurisdictions, unauthorised access to a computer system. That constraint shapes any self-service scanner: before it sends a single packet to a target the user has typed in, the platform must hold reasonable proof that the target belongs to whoever started the scan. Scanning is the easy part, those tools have been around for decades; the hard part is that the target arrives from a form, and it is data you cannot trust.

Context

The NIS2 directive, transposed in Italy by Legislative Decree 138/2024 (in force since 16 October 2024), widens cyber risk-management duties to an estimated 15,000–18,000 organisations, against the roughly 500 covered by the earlier NIS regime (Legislative Decree 65/2018). Among the technical measures required of essential and important entities is risk analysis on information and network systems, with significant-incident reporting to CSIRT Italia under the 24/72/30 rule. For a sizeable share of these organisations — manufacturing, healthcare, food, digital services — the concrete consequence is having to run periodic vulnerability assessments without an in-house security team.

Hence the push towards cloud platforms that run the scan in self-service: the user types a domain or an address block and gets a report. When the initiative passes from the expert operator to the end user, so does the risk of abuse, and with it the burden of proving legitimate control of the target.

The problem

In an internal security function the perimeter is known in advance: the engineer scans assets belonging to the company that pays them. In a cloud service open to registration, the input comes from someone who, with respect to the target, is not authenticated. At the network level, nothing stops a user from typing example.com when example.com is not theirs. If the platform runs the scan, it has just generated active reconnaissance traffic — and possibly intrusion traffic — against third-party infrastructure, on behalf of someone with no standing to order it.

Testing methodologies do not untangle this. The OWASP Web Security Testing Guide v4.2 and the Application Security Verification Standard say how to test, not who may have a given target tested. Authorisation is a precondition of the work, taken for granted in the rules of engagement of a traditional pentest. In a self-service platform that precondition has to be built at runtime, before the scan, automatically and verifiably.

Validation architecture

The proven mechanism is proof of domain control: the same scheme certificate authorities use to issue certificates and SaaS providers use to bind an account to a domain. The IETF set it down in draft-ietf-dnsop-domain-verification-techniques (October 2023), which gathers the practices already in wide use and fixes their weak points.

Applied to a scanner, the flow is this:

  1. The user declares the target (target.example.com).
  2. The platform generates a token with at least 128 bits of entropy and binds it to the account and the requested domain.
  3. The user publishes the token in a TXT record under a provider-specific underscore-prefixed label — _<provider>-challenge.target.example.com — or in a file at a known path on the web server.
  4. The platform queries DNS (or HTTP) and proceeds only if the token matches.

For a scanner, the IETF draft adds two details worth heeding. The first is label scoping: -host-challenge validates a single hostname, -domain-challenge the whole domain and its subdomains. A scanner should refuse to extend on its own from a validated host to the apex without an explicit domain validation, so that consent over one host does not become consent over the entire zone. The second is token encoding: for DNS labels base32 or base16 are recommended, being case-insensitive and free of awkward characters, whereas base64url is subject to normalisations that can make the comparison fail.

Email validation — the confirmation link sent to the user’s address — is a separate layer, and on its own it is not enough: it proves the registrant controls a mailbox, not that they control the target. The two checks answer different questions and should be kept apart.

The critical point

Domain validation is a check in time, not an authorisation that lasts forever. A TXT token published today may be gone tomorrow; a domain can change owner; a subdomain can end up with a different tenant — the well-known subdomain takeover. A platform that validates once and then treats the target as authorised indefinitely accumulates stale authorisations. The concrete consequence is that proof of control should be re-verified before each scan, or held valid for a short, explicit window — the IETF draft provides exactly this, an expiry field in ISO 8601 format in the record’s metadata.

There is also a silent failure to avoid. If the verifying DNS query times out or gets lost at an intermediate resolver, the platform must read the outcome as not authorised, never as authorised out of caution. A fail-open on an authorisation check that precedes offensive traffic is a security defect, not a softening of the user experience.

Implications

Triaging the results is another problem. The question is not so much whether a vulnerability is present, but how likely it is to be exploited. CVSS v4.0 (FIRST, November 2023) gives an intrinsic severity score, but says nothing about how much a flaw is actually attacked in the wild; EPSS, also from FIRST, estimates the probability of exploitation within 30 days. Crossing the two dimensions separates noise (high severity, unlikely exploitation) from real urgency (likely exploitation against an exposed asset). It is a prioritisation built on public, versionable data, not on an opaque score.

On the data side, a scan by itself produces an inventory of assets, open ports, software versions and vulnerabilities — in effect a map for an attacker. Where that data resides and how it is segregated per tenant are security properties of the service, before they are compliance footnotes: a compromised store of reports is a gift to anyone wanting to hit the platform’s customers.

Limits

Proof of domain control covers a target reachable over DNS or HTTP; on bare IP address blocks it works less well, because there is no label on which to publish a token and proof of title runs through the RIR registries or out-of-band agreements. And technical validation does not exhaust legal responsibility: it shows control of a domain, not that the user has the contractual right to test every system behind that domain — think of shared hosting. A layer of consent remains that no TXT record can stand in for.

One platform that brings these constraints into a self-service service for Italian SMEs under NIS2 is CyberScan, described in the insight published by noze: https://www.noze.it/en/insights/cyberscan-launch/.

https://www.first.org/cvss/specification-document https://www.first.org/epss/data_stats https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-domain-verification-techniques-03 https://owasp.org/www-project-web-security-testing-guide/v42/ https://owasp.org/www-project-application-security-verification-standard/ https://www.gazzettaufficiale.it/eli/id/2024/10/01/24G00155/sg

Cover image: Diagram of an iterative DNS resolution: a resolver queries the root nameserver, the .org nameserver and the wikipedia.org nameserver… — diagram by Lion Kimbro, public domain — https://commons.wikimedia.org/wiki/File:Example_of_an_iterative_DNS_resolver.svg