Is enabling HSTS preload a low-risk, easily reversible setting?

Is enabling HSTS preload a low-risk, easily reversible setting?

The advice to "just turn on HSTS preload for security points" treats a near-permanent commitment as a casual toggle. HSTS (HTTP Strict Transport Security, RFC 6797) tells browsers to access your origin over HTTPS only. The preload directive goes further: you submit your domain to a list compiled into Chrome, Firefox, Safari, and Edge binaries. Once shipped, every browser hardcodes HTTPS-only for your domain — including all subdomains if you set includeSubDomains.

The asymmetry is the trap. Adding a domain to the preload list takes weeks to propagate through release channels. Removing it takes months, and during that window any subdomain that cannot serve valid HTTPS becomes completely unreachable — not a warning, a hard failure with no click-through. Forgotten internal subdomains, legacy HTTP-only services, and acquired domains are the classic casualties.

The spec authors warn explicitly that preload is a one-way door in practice. The prerequisites — valid certificate on every subdomain, full-site HTTPS, max-age of at least one year — exist to force this consideration.

— Preload is compiled into browser binaries
— Removal lag is measured in months
— includeSubDomains breaks any non-HTTPS subdomain silently

Further reading: RFC 6797, §11; hstspreload.org submission requirements.
Bottom line: HSTS preload is a durable commitment, not a quick win. Audit every subdomain before submitting.