The 2026 External Security Checklist

Everything below is observable from outside, without credentials and without your cooperation. That is the defining property: an enterprise buyer, an auditor and an attacker all see the same thing, and none of them need your permission to look.

Ordered by what actually costs you a deal or fails an audit first.

Tier 1: disqualifying

Failures here end vendor reviews. Fix before anything else on this page.

[ ] TLS 1.0 and 1.1 refused, not merely deprioritised
[ ] TLS 1.2 minimum, TLS 1.3 supported
[ ] Certificate valid, not expired, correct SANs for every hostname served
[ ] Complete certificate chain (no missing intermediates)
[ ] HTTP redirects to HTTPS
[ ] HSTS present with a long max-age
[ ] No exposed .git directory, .env file or backup archive
[ ] No directory listing on the web root
[ ] DMARC published at p=quarantine or p=reject

Exposed .env and .git deserve their place here despite looking basic. They leak credentials directly, and they remain findable on production domains in 2026.

A note on how these should be measured: a path returning HTTP 200 is not proof of exposure. Single-page applications answer 200 with their shell for any path, so a checker that reports every 200 as an exposed file generates false positives that train teams to ignore it. Confirmation by content signature is the fix.

Tier 2: expected by any serious buyer

Absence here does not end the review, but it generates questions and follow-up work.

[ ] Content-Security-Policy without 'unsafe-inline' in script-src
[ ] CSP using nonce + strict-dynamic rather than an origin allowlist
[ ] object-src 'none' and base-uri 'self'
[ ] frame-ancestors 'none' (or an explicit allowlist)
[ ] X-Content-Type-Options: nosniff
[ ] Referrer-Policy set
[ ] Permissions-Policy disabling unused powerful features
[ ] Forward-secret cipher suites only
[ ] OCSP stapling enabled
[ ] SPF and DKIM published and aligned with DMARC
[ ] DNSSEC on the zone (or a documented decision not to)
[ ] security.txt published (RFC 9116)
[ ] No source maps served in production
[ ] No known-vulnerable JavaScript library versions

unsafe-inline in script-src is the single most common finding in this tier, and it reduces a long, impressive-looking policy to no protection at all. The full maturity ladder.

Tier 3: the 2026 additions

These are new. Most vendors have none of them, which is exactly why they differentiate.

[ ] MTA-STS published in enforce mode (not testing)
[ ] TLS-RPT published and reports actually read
[ ] Certificate issued lifetime within the ceiling in force at issuance
[ ] Certificate lifetime at or below 100 days, or renewal automated before 2027-03-15
[ ] X25519MLKEM768 hybrid key agreement offered
[ ] Hybrid group enabled at the origin, not only at the CDN edge
[ ] require-trusted-types-for 'script' in the CSP
[ ] trusted-types policy allowlist declared
[ ] Integrity-Policy enforced (or report-only, as a first step)
[ ] SRI hashes on every third-party script

Four of these cost roughly an afternoon each. What each one measures and how it is scored.

Tier 4: attack surface

Less about configuration, more about what exists that you have forgotten.

[ ] Subdomain inventory reconciled against certificate transparency logs
[ ] No dangling DNS records pointing at deprovisioned services
[ ] No exposed admin panels or management interfaces
[ ] No exposed enterprise edge devices (VPN, mail gateway) on the perimeter
[ ] Staging and development hosts not publicly reachable, or authenticated
[ ] DNS zone transfer refused
[ ] No verbose error pages leaking stack traces or framework versions

Certificate transparency is the highest-yield item. Every certificate ever issued for your domain is public, which means your forgotten subdomains are public too. Reconciling that list against what you believe you operate routinely surfaces hosts nobody has patched in two years.

Dangling DNS is the one that turns into a real incident, because a CNAME pointing at a deprovisioned cloud resource can be claimed by someone else.

How to use this

Do not start at the top and work down. Start by measuring everything, then fix in tier order. The common failure is a team that spends a sprint on Tier 3 while a Tier 1 item is still open on a subdomain nobody remembered.

Check your application subdomain separately from your marketing site. They frequently differ, and the one holding customer data is often the weaker of the two.

Measure repeatedly, not once. A single clean result proves a moment. Auditors under NIS2 are asking about drift detection, and the recurring finding in 2026 assessments is missing evidence rather than missing security. A dated series is the artefact that answers it.

Be precise about scope. None of this covers encryption at rest, internal service-to-service traffic, key custody, access control or business logic. Presenting an external measurement as though it covered a whole control invites a correction from the auditor. Where the line sits.

Framework mapping

Tier	NIS2	ISO/IEC 27001:2022	DORA
TLS and certificates	21(2)(h)	A.8.24	Art.9
Headers and CSP	21(2)(g), 21(2)(e)	A.8.26, A.8.28	Art.9
Mail transport	21(2)(h), 21(2)(e)	A.8.24, A.5.14	Art.9, Art.7
Third-party script integrity	21(2)(d)	A.5.21	Art.28
Attack surface	21(2)(a), 21(2)(e)	A.8.8, A.5.7	Art.8

One measurement, mapped three ways. For teams answering more than one framework, producing the external evidence once and mapping it is materially less work than running separate exercises. How NIS2 and ISO 27001 relate.

The short version

Tier 1 loses deals. Tier 2 creates friction. Tier 3 differentiates, and is currently cheap because almost nobody has done it. Tier 4 is where the incident comes from.

Measure first, fix in order, and keep the dated results.