HSTS Preload

HSTS preload is a browser-enforced list that hardcodes HTTPS for a domain before the user ever visits it. It is useful for high-assurance sites, but it should only be used when every covered host can reliably serve HTTPS. A mistake here can lock out users for an extended period.

Expanded Definition

HSTS preload is a browser trust mechanism that tells major browsers to assume HTTPS from the first connection, without waiting for a redirect or prior visit. It sits above ordinary HSTS because the policy is distributed through browser preload lists rather than learned dynamically from the site itself.

This makes it a strong fit for domains that can guarantee HTTPS across the entire host set, including the apex domain and any subdomains covered by the preload commitment. The boundary matters: a preload entry is not a cosmetic security flag, it is an operational promise that every relevant hostname will remain HTTPS-capable for the long term. If a host cannot consistently terminate TLS, preload can turn a local configuration issue into a user-facing outage.

Guidance-vs-consensus note: the security industry broadly agrees that preload improves first-visit protection, but there is no consensus that it should be used by default. The implementation reality is that the safety margin depends on disciplined certificate lifecycle management, DNS control, and change management across all covered hosts. For the formal browser-side criteria, see the HSTS preload submission guidance.

Examples and Use Cases

• A public login domain uses preload so new visitors are protected from SSL stripping before any redirect can occur.
• A customer portal with a stable DNS footprint adds preload after confirming every subdomain it serves can sustain HTTPS without exception.
• A security team avoids preload on a domain that still hosts legacy services on some subdomains, because one weak host can create a long-lived access problem.
• An organisation uses preload to reduce dependency on first-request redirect logic, which can be fragile on hostile or poorly configured networks.
• A platform team treats preload as a release decision, not a single web-server setting, because certificate renewal, hostname inventory, and rollback planning all affect success.

The main tradeoff is resilience versus convenience: preload strengthens initial trust, but it also reduces flexibility when a domain portfolio is incomplete or changes frequently. That is why some teams keep it for a small set of high-assurance properties rather than applying it broadly.

Security Implications

Without preload, a user’s first visit still depends on an initial HTTP-to-HTTPS upgrade path, which leaves room for downgrade interference on hostile or intercepted networks. Preload closes that first-connection gap, so it directly reduces exposure to SSL stripping and related redirect-bypass conditions.

The downside is that misconfiguration becomes more expensive. If any hostname in the preload scope loses valid HTTPS service, browsers will continue insisting on HTTPS until the preload status is removed and browser updates propagate. That can strand legitimate users, break account access, and create a recovery window that is longer than a normal certificate incident.

A common practitioner mistake is to treat preload as a site-level setting rather than a domain-wide commitment. In practice, the failure mode is usually not the main marketing site but an overlooked subdomain, an expired certificate, or an internal dependency that was never meant to be public-facing.

Domain and Governance Relevance

HSTS preload matters most where browser trust, certificate operations, and host inventory are tightly coupled. It is fundamentally a web security control, but it also has governance implications because the decision to preload creates a long-lived operational obligation across the full domain surface.

For identity-bearing properties such as login portals, password reset endpoints, and certificate-backed service endpoints, preload can strengthen the trust chain users rely on before authentication even begins. That makes it relevant to identity assurance, but only indirectly: the control protects transport and entry conditions, not identity proofing itself.

For teams managing non-human identities, preload can matter when machine-facing endpoints or token exchange services are exposed on the same domain space. In those cases, the real governance issue is whether all dependent hosts can sustain uninterrupted HTTPS across certificate rotation, subdomain changes, and decommissioning.

Related resources from NHI Mgmt Group

• ld.so.preload
• Preload Script
• Shared Preload Libraries