What is the one risk nobody mentions about HSTS preloading?

What is the one risk nobody mentions about HSTS preloading?

HSTS (HTTP Strict Transport Security, RFC 6797) lets a site command browsers to use only HTTPS for a given duration via the Strict-Transport-Security header. But the header has a bootstrap flaw: the very first visit, before any header is seen, can be intercepted and downgraded. The preload list closes this gap — and introduces a sharper edge.

The preload list is a hardcoded set, compiled into Chromium and inherited by Firefox, Safari, and Edge, of domains that should be HTTPS-only from the first byte, no header required. To qualify, a site must serve the header with max-age of at least 31536000 (one year), the includeSubDomains directive, and the preload token.

Here is the under-discussed risk: removal is slow. Adding a domain is a code change shipped in a browser release; removing it is the same, plus the long tail of users who never update. A domain that preloads includeSubDomains commits every current and future subdomain to HTTPS. If an internal subdomain — a legacy device, an IoT management page, a vendor appliance — cannot serve a valid certificate, it becomes unreachable, and the fix takes browser-release cycles, often months.

Evidence vs. speculation: this is documented at hstspreload.org, which explicitly warns that submission is a long-term, hard-to-reverse commitment.

Further reading: RFC 6797 §11, §14; hstspreload.org submission policy.

Bottom line: Preloading eliminates the first-visit downgrade window, but it is a one-way door — audit every subdomain's TLS readiness before submitting, because rollback is measured in months, not minutes.