SaaSFort TLS configuration has a comforting property: once it is right, it stays right. Disable the old protocol versions, pick forward-secret cipher suites, get HSTS in place, and the configuration keeps passing.
That property is false, and 2026 is a year where it visibly broke. Three things changed that turn a previously clean configuration into one with findings, and none of them are about protocol versions or cipher suites.
The baseline that has not changed
Worth stating first, because it is still most of the work and it is stable.
- TLS 1.2 minimum, TLS 1.3 supported and preferred.
- TLS 1.0 and 1.1 refused, not merely deprioritised.
- Forward-secret cipher suites only.
- HSTS with a long
max-age,includeSubDomains, and preload where the subdomain inventory allows it. - A complete certificate chain, correct SANs, OCSP stapling.
If any of these fail, fix them before reading further. They remain the items that disqualify a vendor in an enterprise review, and they outrank everything below.
Change one: certificate lifetime became a finding
CA/Browser Forum ballot SC-081v3 caps certificate lifetime at 200 days from 2026-03-15, 100 days from 2027-03-15, and 47 days from 2029-03-15. Domain validation reuse drops to 10 days on the same trajectory.
What this changes for an audit is subtle. Certificate expiry was always checked: does it expire soon. Certificate lifetime was not: how long was it issued for. The second is now the interesting one, because it predicts whether your renewal process survives the next step down.
A certificate issued for 365 days is not invalid. It is a signal that renewal is manual or semi-manual, and that in March 2027 the process breaks.
One nuance that matters for anyone building or buying a scanner: the ceiling must be evaluated against the certificate’s issuance date, not today’s. A 398-day certificate issued in 2025 complied with the rule in force when it was minted. A checker that compares every certificate to today’s ceiling reports a false finding on every legitimately issued legacy certificate, and a tool that cries wolf gets ignored.
The full timeline and what to do about it.
Change two: key agreement became a question
Chrome, Firefox and Edge have negotiated the X25519MLKEM768 hybrid group by default since version 131. Server-side support was near ten percent in 2026.
This is not yet a failure condition, and any honest tool reports it as informational rather than as a defect. Not offering post-quantum key agreement in 2026 is not a misconfiguration.
It is an exposure with a delayed effect. Traffic recorded today, protected by classical elliptic-curve key agreement, becomes readable retroactively once quantum attacks are practical. Whether that matters to you is a function of how long your data stays sensitive, which is why the question now appears in questionnaires from regulated buyers and rarely from anyone else.
The fix is one configuration line and fallback is automatic, so the cost-benefit is unusual for a cryptography change.
Change three: TLS stopped meaning only HTTPS
The third change is not about your web server at all.
A TLS audit that covers port 443 and stops there misses the mail path entirely. SMTP negotiates encryption through an unauthenticated STARTTLS advertisement that an on-path attacker can strip, and none of SPF, DKIM or DMARC detects it, because all three authenticate the message rather than the connection.
MTA-STS is the control, TLS-RPT is the telemetry, and adoption sits below one percent of the top million domains. For most organisations this is the single largest unaddressed transport-security gap, and it is also the cheapest to close.
The deployment, and the testing-mode trap.
The 2026 audit checklist
Transport (HTTPS)
[ ] TLS 1.3 supported, TLS 1.2 minimum
[ ] TLS 1.0 / 1.1 refused
[ ] Forward-secret cipher suites only
[ ] HSTS: long max-age, includeSubDomains, preload
[ ] Complete chain, correct SANs, OCSP stapling
Certificates
[ ] Issued lifetime within the ceiling in force at issuance
[ ] Lifetime at or below 100 days, or renewal automated before 2027-03-15
[ ] Issuance via ACME, renewal decoupled from lifetime
Key agreement
[ ] X25519MLKEM768 offered, X25519 retained as fallback
[ ] Enabled at the edge AND at the origin, if a CDN is in front
Mail transport
[ ] MTA-STS published in enforce mode
[ ] TLS-RPT published and reports actually read
[ ] DANE, if the zone is DNSSEC-signed
The CDN line is worth dwelling on. Vendors routinely enable modern TLS at the edge while the edge-to-origin connection stays on an older configuration. An external scan sees the edge. Your architecture diagram sees both, and the auditor will ask about the second.
Where it maps
Everything above lands in NIS2 Article 21(2)(h), ISO/IEC 27001:2022 A.8.24, and DORA Article 9, with the network-layer items also under NIS2 21(2)(e) and ISO A.8.20. What auditors accept as evidence for that clause.
The short version
Protocol versions and cipher suites were the whole job in 2024. In 2026 they are the entry ticket.
The three new items are certificate lifetime, hybrid key agreement, and the mail path. The third one is where almost everyone has a real gap.
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