NIS2 domain security check

A free scan of the DNS, email and TLS settings that the technical measures of NIS2 point to. It gives you a readiness indicator for the externally visible part of your setup. It is not a certification and it is not legal advice.

The bare domain, without http:// or a path.

Free scans today Loading...

Anonymous results are kept for 1 hour. Single-standard check

The scan runs all 14 standards, not only this one. 5 free scans a day, no account needed.

What this check is, and what it is not

Read this before you read a result.

What it is

Directive (EU) 2022/2555 (NIS2) requires covered entities to take appropriate and proportionate technical, operational and organisational measures to manage their security risks. Commission Implementing Regulation (EU) 2024/2690 lists detailed technical requirements for certain digital infrastructure and ICT service providers. SetEnforce maps the findings of a domain scan to those technical requirements, so you can see which externally visible settings line up with them.

What it is not

It is a readiness indicator, not a certification, an audit or a statement that you comply. Most of the annex is governance: incident handling, training, supplier contracts, backup plans. No scan can observe that, so the mapping leaves it out instead of pretending. Whether NIS2 applies to your organisation is a legal question for you and your competent authority.

What the scan maps to NIS2

Nine areas of the annex have technical, externally observable checks behind them. The weight is the one used in SetEnforce's mapping. It is not a legal term.

NIS2 requirement areas, the checks behind them and where they run
Area What the scan looks at Annex point Weight In an anonymous scan
Email transport security TLSA records for the mail servers (DANE), the MTA-STS record and policy, TLS-RPT, and STARTTLS on the mail servers. 6.7.2(k) required DNS-based checks run. The STARTTLS and other mail server probes are active and show as Not tested.
Anti-spoofing An SPF record, and a DMARC policy that enforces and covers subdomains. 6.7.2(k) required Runs.
Message authentication A DKIM record, found through selector discovery. 6.7.2(k) required Runs.
DNS security The DNSSEC chain of trust, the DS record, signatures, algorithms and key hygiene. 6.7.2(l) required Runs.
Routing security A valid ROA for the prefixes of the nameservers and mail servers. 6.7.2(l) recommended Runs. See the RPKI checker.
IPv6 Whether IPv6 is published and reachable. 6.7.2(j) recommended Publication is checked. Reachability and parity are active checks.
Vulnerability disclosure A valid security.txt (RFC 9116). 6.10.2(e) required Runs.
TLS protocol versions Only current TLS versions are offered. 9.1.2(b) required Runs.
TLS cipher strength Cipher strength and key exchange groups. 9.1.2(b) required Runs.

The scan also checks HTTP security headers, CAA records, DNS hygiene and registration data. Those appear in your report but are not tied to a requirement of the annex, so they are not part of the NIS2 view. Multi-factor authentication on remote and privileged access is a technical requirement the scan can never see, because it does not sign in anywhere. It is listed in the mapping as not observable.

What a failing result looks like

A common one: the DMARC record only monitors (p=none) and has no reporting address. This is the finding as the report words it.

High DMARC policy actually enforces, and covers subdomains email.dmarc.policy_strength

Fail_dmarc.example.com: policy_none, no_rua.

Impact

With `p=none`, a receiving mail server that authenticates a forged message against this domain is told to deliver it anyway. Anyone can send mail that appears to come from this domain, and business-email-compromise attacks against the domain's own customers and staff succeed at the mail-server level.

Remediation

_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]; sp=reject; adkim=s; aspf=s"

Migration path if you are at p=none today:
  1. keep p=none, confirm rua reports arrive for two weeks
  2. fix any legitimate senders failing alignment
  3. p=quarantine; pct=25, then 50, then 100
  4. p=reject
Set sp explicitly - it does not inherit p in the way most operators assume.

The summary line names every condition that triggered the finding, here a monitor-only policy and a missing reporting address. A missing record or a record a verifier would discard gets its own wording. The findings list is part of the signed-in report.

Where to start

If the first scan shows several failures, this order fixes the most for the least work.

  1. Enforce DMARC

    Move from p=none to quarantine and then reject, with SPF and DKIM aligned for every legitimate sender. This closes the easiest attack on your name.

  2. Sign the zone

    Enable DNSSEC and publish the DS record at your registrar. DANE depends on it, and so does a clean DNS result.

  3. Retire old TLS

    Offer only current TLS versions and drop weak ciphers on every public endpoint.

  4. Protect mail in transit

    Publish an MTA-STS policy and TLS-RPT reporting, and add DANE (TLSA records) if your zone is signed.

  5. Cover your prefixes

    Make sure the prefixes serving your nameservers and mail servers have valid ROAs. The RPKI checker shows which do not.

  6. Publish a disclosure channel

    Add a security.txt with a working contact and an Expires date that is in the future.

Reading the NIS2 view

How the requirement-level view works, and where it lives.

The scan itself is free and needs no account, and an anonymous scan runs the same checks as any other. What differs is how much of the report you can open. The per-requirement NIS2 view, the findings list and the exports are part of the signed-in report.

In that view every requirement shows one rolled-up status and the checks behind it, so you can see which observation produced which status. A requirement that could not be tested says so. Coverage is a matrix, not a score, and it never changes the score of the scan itself.

Related checkers: RPKI covers the routing item, DANE covers part of the email transport item.

Frequently asked questions

Does a clean result make my domain NIS2 compliant?
No. NIS2 compliance is mostly organisational: policies, incident handling, training, supplier management. A scan sees only what a domain publishes. A clean result means the externally visible settings it checks look right, nothing more.
Which NIS2 text is the mapping based on?
Findings are mapped to the technical requirements in the annex of Commission Implementing Regulation (EU) 2024/2690, which spells out the risk-management measures of Article 21 of Directive (EU) 2022/2555. The article itself is technology-neutral and does not name protocols.
Does this apply to my organisation?
That is a legal question this page cannot answer. The implementing regulation covers specific categories of digital infrastructure and ICT service providers, such as DNS service providers, cloud and data centre providers and managed service providers. Whether NIS2 applies to you, and how, depends on your sector and on the national law that transposes the directive. Ask your counsel or your competent authority.
Is this a NIS2 score?
No. The NIS2 view is a coverage matrix. For each requirement it shows a rolled-up status and the checks behind it. Requirements the scan could not test are shown as Not tested, not hidden and not counted as passed. It does not add a separate score.
Why do some checks show Not tested?
Anonymous scans and free accounts are passive: they read only what the domain publishes. Active checks, such as connecting to your mail server to test STARTTLS, run for signed-in accounts on a paid plan. A check that was not allowed to run appears as Not tested, never as passed or failed. How passive and active scans differ.
Why are security headers like HSTS not part of the NIS2 view?
The scan checks them and reports them, but the mapping does not tie them to a requirement of the implementing regulation, so they are not shown in the NIS2 view. Nothing is claimed that the annex does not say.
Are the findings mapped to other frameworks too?
Yes. NIS2 is one of 11 frameworks in the signed-in report. The BSI IT-Grundschutz mapping covers the modules for web servers (APP.3.2), email (APP.5.3) and DNS servers (APP.3.6), and there are mappings for ISO/IEC 27001:2022 Annex A, NIST CSF 2.0 and others.
Do I need an account?
Not to run the scan. Anonymous visitors get 5 scans a day, and results are kept for 1 hour. The per-requirement NIS2 view and the findings list are part of the signed-in report.

Scan a domain

Keep reading

Other checkers

  • RPKI checkerWhich of a domain's nameserver and mail server prefixes are covered by a valid ROA.
  • DANE and TLSA checkerWhether every mail server publishes TLSA records that match its certificate.

On this site

  • Compliance benchmarkAnonymous, aggregate adoption rates for each standard across scanned domains.
  • FAQScan limits, result retention, passive and active scans.
  • Full domain scanAll 14 standards and 110+ checks in one report.

Knowledge base