SaaSFort An external security baseline that never changes is either perfect or unmaintained. Ours changed in 2026, and this is the record of what moved and on what reasoning.
Six controls were added. All of them address things that were either not deployable or not asked about two years ago.
The rule we applied
A control earns a place in the baseline when three things are true.
It is externally observable, without credentials or cooperation. If it cannot be measured from outside, it belongs in a questionnaire, not in a scan.
It is actionable, meaning a team can change it. Reporting a condition nobody can fix produces noise, and noise trains people to ignore the report.
It is decidable from evidence, not inferred from a banner or a version string. A verdict we cannot substantiate with a raw observation is a guess, and guesses are what make scanners untrustworthy.
The last one is why two of the six are reported as informational rather than as failures.
1. MTA-STS policy
What it measures. Whether the domain publishes an MTA-STS policy (RFC 8461), and critically, which mode the policy declares.
Why. SPF, DKIM and DMARC authenticate the sender. None of them stop an on-path attacker from stripping STARTTLS and forcing plaintext delivery. This was the largest unmeasured gap in the baseline.
How it is scored. enforce passes. testing is a Low finding, because it reports failures and delivers anyway. none, or a policy advertised in DNS but unreachable over HTTPS, is Medium. Absence is Low.
Reporting the mode rather than the presence of a record is the distinction that matters: a domain parked in testing has the appearance of the control and none of the effect.
Not applicable to domains with no MX record. A domain that receives no mail is not failing a mail control, and reporting it would put an unfixable finding in front of every customer whose marketing domain does not accept mail.
2. TLS-RPT reporting
What it measures. A v=TLSRPTv1 record at _smtp._tls.<domain> (RFC 8460).
Why. TLS-RPT is what makes MTA-STS safe to enforce and what surfaces a failing MX host before a customer notices. Without it, TLS delivery failures are invisible.
How it is scored. Informational when absent, because it is telemetry rather than a protective control. Present is a pass.
3. Post-quantum key exchange
What it measures. Whether the server negotiates the X25519MLKEM768 hybrid group, IANA codepoint 0x11ec.
Why. Chrome, Firefox and Edge have offered it by default since version 131. Origin-side support was near ten percent in 2026. The exposure it addresses is harvest-now-decrypt-later.
How it is measured. A real TLS handshake restricted to the hybrid group. Not a banner, not a version inference. On failure, a second unrestricted handshake confirms the host answers TLS at all before anything is concluded, because a failed handshake against an unreachable host proves nothing.
How it is scored. Informational when absent. Not offering post-quantum key agreement in 2026 is an exposure with a delayed effect, not a present misconfiguration, and scoring it as a failure would misrepresent the risk. The reasoning in full.
4. Certificate lifetime
What it measures. How long the certificate was issued for, compared against the CA/Browser Forum ceiling in force on its issuance date.
Why. Distinct from expiry, which asks when the certificate runs out. Lifetime asks how the renewal process works, and with the ceiling stepping to 100 days in March 2027, a long-lived certificate predicts an outage.
The subtlety that matters. The ceiling is evaluated against notBefore, not against today. A 398-day certificate issued in 2025 complied with the rule in force when it was minted and is still valid. A checker comparing every certificate to today’s ceiling reports a false finding on every legitimately issued legacy certificate, which is precisely how a tool teaches people to ignore it.
How it is scored. Above the applicable ceiling is Medium. Within the ceiling but above the next step down is informational, flagging that the renewal cadence has to change before that step lands. Otherwise a pass. The full timeline.
5. Trusted Types
What it measures. Whether the CSP carries require-trusted-types-for 'script' and a trusted-types policy allowlist.
Why. Every other CSP directive governs where scripts come from. DOM XSS loads no script, so none of them apply. Trusted Types is the only CSP mechanism addressing the sink.
How it is scored. Three states, because they are genuinely different postures: both directives present is a pass; enforcement without an allowlist is Low, since any code can then mint policies and the audit trail is lost; neither is Low. The deployment path.
6. Integrity-Policy
What it measures. The Integrity-Policy and Integrity-Policy-Report-Only response headers from SRI Level 2.
Why. The existing SRI check reports whether individual scripts carry integrity attributes. Integrity-Policy is the enforcement layer that stops coverage decaying when someone adds a script and forgets the attribute.
How it is scored. Enforced is a pass. Report-only is informational, since violations are reported but scripts still execute. Absent is informational. Browser support is still partial, notably in Safari, so a harder severity would not be defensible yet. Why it matters anyway.
Framework mapping
Every new control maps into the same three frameworks the rest of the baseline uses, because an unmapped finding is invisible in the evidence report that customers actually use.
| Control | NIS2 | ISO 27001:2022 | DORA |
|---|---|---|---|
| MTA-STS policy | 21(2)(h), 21(2)(e) | A.8.24, A.5.14 | Art.9, Art.7 |
| TLS-RPT reporting | 21(2)(b), 21(2)(h) | A.8.16, A.5.14 | Art.10, Art.9 |
| Post-quantum key exchange | 21(2)(h) | A.8.24 | Art.9 |
| Certificate lifetime | 21(2)(h) | A.8.24 | Art.9 |
| Trusted Types | 21(2)(g), 21(2)(e) | A.8.28, A.8.26 | Art.9 |
| Integrity-Policy | 21(2)(d), 21(2)(g) | A.5.21, A.8.28 | Art.28, Art.6 |
What did not change
The published figure of 66 checks across 25 categories stays as it is. It was always a conservative number sitting inside the implemented range rather than a count of everything the engine can emit, and adding controls makes it more conservative, not less.
We would rather under-claim a number that is checkable than inflate one that is not. What an external scan can and cannot prove.
The short version
Six controls added: two for mail transport, one for key agreement, one for certificate process, two for browser-side integrity.
Two are scored informational on purpose, because reporting a forward-looking exposure as a failure would be inaccurate, and accuracy is the only thing that makes a grade worth citing.
Ready to put this into practice?
Two ways to start — pick what fits. Free Scan if you want to see your security grade in 60s with no commitment. Free 14-day Growth trial if you're ready to monitor multiple domains, export NIS2 reports, and download Deal Reports — no credit card required.
No credit card · Cancel anytime · GDPR-ready · EU-hosted