LAST UPDATED: JUNE 2026 • PUBLIC

Scan Methodology

A complete, transparent breakdown of how the NIS2 Engine assesses supply chain risk entirely from the outside-in.

Our Core Principle

Every security assessment performed by the NIS2 Compliance Engine is 100% passive. We observe only what is publicly visible on the open internet — the same information available to any browser, email server, or search engine. We never interact with a vendor's internal systems, attempt authentication, or send any form of payload.

This approach is legally equivalent to reading a company's publicly listed phone number. We are not knocking on the door — we are reading the sign outside it.

Legal Basis for Scanning

Passive external reconnaissance of publicly accessible infrastructure is universally recognized as lawful under:

  • EU NIS2 Directive 2022/2555 — Article 21 explicitly requires organizations to assess the security posture of their supply chain
  • German IT Security Act 2.0 (IT-SiG 2.0)
  • UK Computer Misuse Act 1990 — passive observation of public data is explicitly outside scope
  • US Computer Fraud and Abuse Act — no unauthorized access occurs as no authentication is attempted

Your organization, as our client, initiates these assessments under your legal right and contractual obligation to perform third-party vendor due diligence. You confirm this authorization when adding each vendor domain to your account.

What We Check

1. DNS Security Layer

We query the public Domain Name System — the same system your browser uses every time you visit a website.

Checks performed:

  • SPF (Sender Policy Framework) — Does the vendor publish which mail servers are authorized to send email on their behalf? A missing or weak SPF record means anyone can send convincing phishing emails pretending to be from this vendor.
  • DMARC (Domain-based Message Authentication) — Does the vendor enforce email authentication? A DMARC policy of none means even if SPF fails, no action is taken.
  • DKIM (DomainKeys Identified Mail) — Does the vendor cryptographically sign outgoing emails? We probe common selector names to detect DKIM presence.
  • DNSSEC — Is the vendor's DNS signed and validated? Without DNSSEC, DNS responses can be spoofed by attackers redirecting traffic to malicious servers.
  • CAA Records — Has the vendor restricted which Certificate Authorities can issue SSL certificates for their domain? Missing CAA records allow any CA to issue certificates.
  • Zone Transfer — We attempt a DNS zone transfer request. Legitimate DNS servers reject this. Servers that allow it expose their entire internal DNS structure — a critical misconfiguration.
  • NS Records — We identify the nameserver provider for infrastructure context.
  • MX Records — We identify the email infrastructure provider.
Data source: Public DNS resolvers. No authentication. No access to private DNS zones.

2. Certificate Transparency & Subdomain Intelligence

Every SSL/TLS certificate ever issued for a domain is permanently logged in public Certificate Transparency logs maintained by Google, Cloudflare, and other certificate authorities. This is a legal requirement under RFC 6962.

Checks performed:

  • Full historical subdomain enumeration via crt.sh public API
  • Identification of shadow IT environments — forgotten subdomains like dev.vendor.com, staging.vendor.com, old.vendor.com that may have weaker security than the primary domain
  • Certificate issuer analysis
Data source: crt.sh public Certificate Transparency log aggregator. Read-only API. No authentication required.

3. TLS and SSL Inspection

We establish standard HTTPS connections — identical to what your browser does — and observe what the server presents.

Checks performed:

  • TLS version support — We test whether the server accepts connections using deprecated TLS 1.0 and TLS 1.1 protocols, which are vulnerable to POODLE and BEAST attacks and deprecated by RFC 8996 since March 2021
  • TLS 1.3 support — Modern standard required by NIS2 Article 21.2(g)
  • Certificate validity — Is the certificate currently valid and trusted by major certificate authorities?
  • Certificate expiry — How many days until expiry? Expired certificates cause service outages and destroy user trust
  • Self-signed certificates — Indicates absence of trusted CA validation
  • Wildcard certificates — Assessed for scope and appropriateness
  • Subject Alternative Names — Complete list of domains covered by the certificate
  • Cipher suite negotiation — What encryption algorithms does the server prefer?
Data source: Standard TLS handshake. Identical to any HTTPS browser connection. No data is sent beyond the handshake.

4. HTTP Security Headers

We make a single standard HTTP GET request to the vendor's primary domain — identical to what happens when anyone visits their website in a browser.

Checks performed:

  • Strict-Transport-Security (HSTS) — Does the vendor force HTTPS for all future connections?
  • Content-Security-Policy (CSP) — Does the vendor restrict which resources can be loaded, preventing cross-site scripting attacks?
  • X-Frame-Options — Is the site protected against clickjacking attacks?
  • X-Content-Type-Options — Does the vendor prevent MIME type sniffing attacks?
  • Referrer-Policy — Does the vendor control what referrer information is shared?
  • Permissions-Policy — Does the vendor restrict access to browser APIs like camera, microphone, geolocation?
  • Cross-Origin-Opener-Policy — Is the site protected against cross-origin attacks?
  • Cross-Origin-Resource-Policy — Does the vendor restrict cross-origin resource loading?
  • HTTPS redirect — Does the vendor correctly redirect all HTTP traffic to HTTPS?
  • CORS policy — Does the vendor restrict cross-origin requests or expose a wildcard policy?
  • Cookie security flags — Are session cookies marked Secure and HttpOnly?
  • Server information disclosure — Is the vendor leaking their software stack in response headers?
  • Technology fingerprinting — What CMS, framework, or CDN is detectable from public response data?
  • Exposed administrative interfaces — Are paths like /admin, /.env, or /phpmyadmin publicly accessible?
  • Error page information leakage — Do error responses reveal stack traces or database details?
Data source: Single HTTP GET request. No authentication. No form submissions. No JavaScript execution.

5. Threat Intelligence Cross-Reference

We cross-reference the vendor's public IP address and domain against multiple free, public threat intelligence databases.

Checks performed:

  • Shodan InternetDB — Shodan continuously scans the entire public internet and maintains a database of open ports and known vulnerabilities per IP address. We query their free public API using only the vendor's IP address. We receive: open ports, associated CVE identifiers, and infrastructure tags. No scanning performed by us — we read Shodan's existing data.
  • Google Safe Browsing — Google maintains a continuously updated database of domains flagged for malware distribution, phishing, and unwanted software. We query this public API to check if the vendor's domain appears on any Google threat list.
  • AbuseIPDB — A community-maintained database of IP addresses reported for malicious activity. We query the vendor's IP address to retrieve its abuse confidence score and total report count.
  • AlienVault OTX (Open Threat Exchange) — A public threat intelligence platform maintained by AT&T Cybersecurity. We query for threat pulses associated with the vendor's domain.
  • IPInfo — We retrieve the vendor's IP address metadata including ASN, hosting organization, and geographic location. We flag vendors hosted on residential IP ranges as this is unusual for legitimate business infrastructure.
  • URLScan.io — A public service that archives website scans. We query existing scan results for the vendor's domain — we do not initiate new scans unless explicitly configured.
  • DNS Blacklist Check — We query major DNS-based blacklists (DNSBL) to check if the vendor's mail servers or IP addresses appear on email reputation blacklists.
Data source: All public APIs. Read-only queries. No data written to any third-party system.

6. Email Security Assessment

We combine DNS findings to produce an overall email security grade.

Assessment covers:

  • SPF policy strictness (-all, ~all, +all, ?all)
  • DMARC enforcement level (none, quarantine, reject)
  • DMARC aggregate reporting configuration
  • DKIM selector presence
  • Overall email spoofing resistance

Grading:

  • A SPF -all + DMARC p=reject + DKIM present
  • B SPF and DMARC present with partial enforcement
  • C SPF or DMARC present, not both
  • D Minimal email security present
  • F No email authentication configured

What We Explicitly Do Not Do

We want to be unambiguous about the boundaries of our scanning:

We do not send malicious payloads of any kind
We do not attempt SQL injection, XSS, or any form of web application attack
We do not attempt to authenticate to any login page or administrative interface
We do not brute force passwords or API keys
We do not scan internal networks, intranets, or private IP ranges
We do not intercept or capture any user traffic
We do not store any vendor data beyond what is displayed in your report
We do not share vendor findings with any third party
We do not perform port scanning beyond reading Shodan's existing public database
We do not exploit any vulnerability we discover — we only report it

How Scores Are Calculated

Scoring is entirely deterministic. The same domain scanned twice under identical conditions will always produce the same score. There is no subjective judgment in the numeric score.

We begin at 100 points and apply deductions based on a fixed penalty table. Each deduction corresponds to a specific, verifiable finding. The penalty table is publicly documented and does not change between scans.

The AI component of our platform — powered by Google Gemini — is used exclusively to write the plain-English narrative sections of your report. It does not calculate, adjust, or influence the numeric score in any way. The score is always the output of deterministic Python code applied to raw scan data.

This design ensures your score is legally defensible and reproducible. If a regulator questions a finding, you can point to the exact data source and the exact penalty rule that produced it.

Score Penalty Reference Table

FindingPenaltyNIS2 Article
Expired SSL certificate
-40
21.2(g)
Google Safe Browsing flagged
-40
21.2(e)
Active data breach detected
-35
21.2(e)
Critical CVE on public infrastructure
-35
21.2(d)
Zone transfer possible
-30
21.2(d)
Exposed database port
-30
21.2(d)
Self-signed certificate
-30
21.2(g)
TLS 1.0 enabled
-25
21.2(g)
Wildcard CORS policy
-25
21.2(j)
TLS 1.1 enabled
-20
21.2(g)
No HTTPS redirect
-20
21.2(j)
Missing HSTS header
-15
21.2(j)
Missing CSP header
-15
21.2(f)
SPF softfail (~all)
-15
21.2(a)
DMARC policy=none
-15
21.2(a)
No DMARC record
-15
21.2(a)
High CVE on infrastructure
-15
21.2(d)
Exposed admin panel
-12
21.2(f)
Error page stack trace leak
-12
21.2(f)
No DNSSEC
-10
21.2(d)
No CAA records
-10
21.2(g)
Certificate expiring within 30 days
-10
21.2(g)
Missing X-Frame-Options
-5
21.2(f)
Missing X-Content-Type-Options
-5
21.2(f)
Missing Referrer-Policy
-5
21.2(f)
Missing Permissions-Policy
-5
21.2(f)
No DKIM found
-5
21.2(a)
Server version disclosed
-5
21.2(f)
Cookie missing security flags
-5
21.2(f)
TLS 1.3 not supported
-5
21.2(g)
Residential IP hosting
-5
21.2(d)

Limitations of Automated Scanning

We believe in complete transparency about what automated scanning cannot detect:

  • We cannot assess internal security policies, access controls, or employee training
  • We cannot evaluate incident response procedures or business continuity plans
  • We cannot verify software patching practices for internal systems
  • We cannot assess physical security controls
  • We cannot evaluate contractual security obligations between vendors and their own suppliers
  • A passing score does not guarantee a vendor will not experience a breach
  • A failing score does not mean a vendor has already been compromised

For comprehensive NIS2 compliance, automated scanning should be used alongside — not as a replacement for — contractual security requirements, vendor questionnaires, and periodic manual review for critical suppliers.

Data Retention

Raw scan data is retained for 24 months to support audit trail requirements. PDF reports are retained indefinitely in your account. You may request deletion of all data associated with your account at any time by contacting us.

Vendor domain names and scan results are never shared with third parties, sold, or used to train AI models.

Requesting Removal

If you are a vendor and believe your domain has been incorrectly assessed, contact us at methodology@yourdomain.com. We will respond within 5 business days.

Note: We cannot remove domains from client accounts as clients have the right to monitor their own supply chain.