<b>What actually happens if you submit a domain to the HSTS preload list and later need to serve plain HTTP?</

<b>What actually happens if you submit a domain to the HSTS preload list and later need to serve plain HTTP?</b>

The honest answer is: you have a problem that can outlive your control of the domain.

HTTP Strict Transport Security (HSTS, RFC 6797) is a response header instructing browsers to only ever reach a host over HTTPS for max-age seconds. Its flaw is the first visit: before the browser has seen the header even once, an attacker can downgrade the initial request. The preload list closes that gap by hardcoding domains into the browser binary itself, so HTTPS is enforced from the very first connection — including the includeSubDomains directive.

The trap is removal latency. Getting onto the list (via hstspreload.org) requires max-age of at least one year and the preload directive. Getting off requires a separate removal request, and the change only reaches users as browsers update and propagate — historically weeks to many months. Older or un-updated browsers may enforce it far longer.

The operational hazard is concrete: includeSubDomains will break any subdomain that cannot serve valid HTTPS — internal tools, legacy hosts, third-party CNAMEs. Operators have shipped preload, then discovered a subdomain they forgot, with no fast escape.

Further reading: RFC 6797 §11, §12; the Chromium HSTS preload submission policy.

Bottom line: preload is a near-irreversible commitment to HTTPS-everywhere including all subdomains — audit your full subdomain inventory before submitting, not after.