Defaults.Exposed › Reports

HSTS Adoption 2026: The Half-Locked Door

Published 2026-08-18

Figures as of 2026-08-16 · methodology v9. This is a recurring report; each edition re-measures the same population so the numbers can be tracked over time. All figures are aggregate — we never publish an individual business’s grade or name an individual registrant’s domain.

The headline: more than half of HTTPS domains skip HSTS, and most of the rest configure it halfway

Of 329,886,554 domains that served an HTTPS response our census could evaluate, 185,452,267 — 56.2% — sent no Strict-Transport-Security header at all. And among the 144.4 million that did, only 4.1% published a policy strong enough to qualify for browser preload lists. The header that turns “usually encrypted” into “always encrypted” is either missing or watered down almost everywhere we looked.

We have written before about which security headers the web sends and which it skips — our HTTP security header report card covers presence across the whole header family. This report is the quality cut for one header. Not “does the domain send HSTS,” but “does the HSTS it sends actually do the job.”

The short answer: mostly, no. The most common HSTS deployment on the internet is the minimum viable one — no includeSubDomains, no preload, and in a meaningful share of cases a max-age so short the protection lapses within months of the last visit.

Key numbers

• 56.2% of HTTPS-serving domains send no HSTS header — 185,452,267 of 329,886,554 evaluated in the August 2026 census.
• 144,434,287 domains deploy HSTS; the large majority use the basic form with neither includeSubDomains nor preload.
• Only 4.1% of HSTS deployers publish a preload-ready policy (preload directive plus max-age of at least one year): 5,959,894 domains.
• As a share of the whole evaluated HTTPS population, preload-ready HSTS is 1.81%.
• The short max-age cohort persists: 13,237,687 basic HSTS domains set max-age below six months — protection that expires quickly once visits stop.
• 1,020,612 domains request preload with a max-age too short to qualify — a self-disqualifying configuration that appears widely.

What does HSTS actually do?

Strict-Transport-Security is a one-line HTTP response header that tells the browser: for the next N seconds, never talk to this domain over plain HTTP, even if the user types http:// or clicks an old link. The browser upgrades every request to HTTPS internally, before anything touches the network. (HSTS is defined in RFC 6797, published in 2012 — industry context, not census data.)

That matters because HTTPS without HSTS has a gap. A site can redirect HTTP to HTTPS perfectly, but the redirect itself happens over plain HTTP. An attacker on the same network — hotel Wi-Fi is the classic setting — can intercept that first cleartext request and keep the victim on an attacker-controlled connection. This is SSL stripping, and it works against sites that “have HTTPS.” HSTS closes the gap for every visit after the first one.

The header takes three knobs, and the knobs are the whole story of this report:

• max-age — how long, in seconds, the browser remembers the rule. When it lapses, protection resets to zero until the next visit.
• includeSubDomains — extend the rule to every subdomain, so login.example.com and any forgotten test host get the same treatment.
• preload — a request to be baked into the browser’s shipped list of HSTS domains, which closes the one remaining hole: the very first visit. Browsers ship with the Chromium preload list built in, and inclusion requires a max-age of at least one year (31,536,000 seconds), includeSubDomains, and the preload directive — industry criteria from hstspreload.org, not something our census defines.

A domain can turn none of the knobs, some of them, or all of them. We counted.

How many domains use HSTS in 2026?

Nearly four in ten. Of the 329,886,554 domains whose HTTPS response the August 2026 census could evaluate, 144,434,287 sent a Strict-Transport-Security header — 43.8%. The other 185.5 million serve HTTPS with the door only half locked: encrypted when the visitor arrives encrypted, strippable when they don’t.

Here is the full picture, configuration tier against max-age band:

(Denominator for the deployer shares: the 144,434,287 domains sending any HSTS header.)

Two things stand out. First, even within the deployer base, the basic tier is by far the most common configuration — a short max-age with no subdomain coverage and no preload. That is genuine protection — a returning visitor to the exact hostname is safe — but it leaves subdomains strippable and does nothing for first visits.

Second, the strongest cell in the table, preload directive with a year-plus max-age, holds 5,959,894 domains. Against the deployer base that is 4.1%. Against every HTTPS domain we evaluated, it is 1.81%. The configuration that browser vendors consider the finished state of HSTS is a rounding error on the wider web.

Why does a short max-age undermine HSTS?

Because HSTS is a memory, and max-age is how fast the browser forgets.

Set max-age=31536000 and a visitor from last summer is still protected today. Set max-age=300 — five minutes, a value that appears in tutorials as a “safe testing” starting point — and the protection is gone before the user finishes reading the page they loaded. Every fresh visit after expiry starts from the same unprotected state as a site with no HSTS at all.

Our census found 13,237,687 basic-tier deploying domains with a max-age under six months. Some of those are deliberate, cautious ramp-ups; the deployment guides genuinely do recommend starting low and raising it. But a ramp-up is supposed to end. A short max-age observed in a one-shot census is indistinguishable from a ramp-up that never ramped: someone followed step one of the tutorial, shipped it, and moved on. Given that the low-max-age cohort runs into the millions, we suspect most of these ladders are missing their top rungs.

The middle band is nearly empty, which supports that reading. Only a small fraction of deployers sit between six months and a year. Deployments cluster at “long, done properly” and “short, probably forgotten”, with almost nobody in transit between the two.

The preload paradox: asking for protection you can’t receive

The strangest cohort in the data is the 1,020,612 domains that publish the preload directive with a max-age below the one-year threshold — 866,396 of them below six months. That is 14.6% of every domain asking for preload.

The preload directive is a request to be hard-coded into browsers. The published inclusion criteria (industry knowledge, per hstspreload.org) require max-age of at least 31,536,000 seconds. These million-plus domains are simultaneously asking for the strongest protection HSTS offers and disqualifying themselves in the same line of text. The request can never be granted as written. Nothing warns them; the header is syntactically fine, browsers apply what they can, and the preload application would simply be rejected if anyone ever submitted it.

It is a small cohort by census standards and a perfect specimen of the pattern this whole series keeps finding: the distance between deploying a control and deploying it correctly is where the internet actually lives. A million domains copied the strong-looking header without the number that makes it strong.

One honest limit on this section: we measured the header, not the list. A domain sending preload may or may not have applied for inclusion, and a handful of domains are on the preload list without our census seeing the directive at scan time. What we can say precisely is what each domain asked for, and whether its own header meets the published bar.

What would it cost to fix?

Nothing, which is the recurring punchline of this series. HSTS is one response header. Moving from the basic tier to a year-long max-age is editing a number. Adding includeSubDomains is one word — though it is the one change on this page that deserves genuine caution, because it commits every subdomain you own, including the internal one somebody stood up on plain HTTP in 2019, to HTTPS-only. Test before you turn that knob. That caution is the likely honest explanation for part of the basic-tier majority, and it is a better reason than forgetfulness. It is not a reason for a five-minute max-age on your apex.

The barrier, as usual, is not cost. It is that nobody told the owner the header they copied in was set to expire.

How we measured this

• Source: the August 2026 Defaults.Exposed census round (figures as of 2026-08-16, methodology v9), which scanned 432 million domains and graded 376.9 million.
• Denominator: 329,886,554 domains that served an HTTPS response whose headers the census could evaluate — the sum of every row in our HSTS tier data, including the no-HSTS cohort. This is the only denominator used in this article. It is smaller than the 376.9 million graded total because not every responding domain presents an evaluable HTTPS response.
• What we recorded: the Strict-Transport-Security header returned by the domain’s apex at scan time, bucketed by directive tier (max-age only / includeSubDomains without preload / preload directive present) and max-age band (under 6 months / 6 months–1 year / 1 year or more).
• Preload directive ≠ preload list. We measured the header a domain publishes, not membership on the Chromium preload list. “Preload-ready” in this article means the domain’s own header meets the published inclusion bar (preload directive, max-age ≥ 1 year); actual list inclusion also requires includeSubDomains, valid certificates and correct redirect behaviour, and a submitted application — none of which this census adjudicates.
• Per-host scope: HSTS is a per-host policy and we measured the registrable domain’s apex. A domain whose www host sends a different (or absent) policy is represented here by its apex only.
• Single vantage, point in time: headers were observed from our EU measurement infrastructure during the census window. Sites that vary headers by geography, client, or CDN edge may present differently elsewhere.
• Industry facts (RFC 6797’s 2012 publication date, the hstspreload.org inclusion criteria, the 31,536,000-second threshold) are public vendor/standards knowledge, labelled as such, not census measurements.
• Aggregate only. We never name, grade or publish data about an individual registrant’s domain.
• Data is stored and processed within the EU.

What this means for IT managers, security teams, and business owners

HSTS without a long max-age is not a finished deployment — it is a first step that was never completed. If your organisation’s domains have HSTS headers with sub-six-month max-age values, the practical protection for infrequent visitors is close to zero. The 13.2 million domains in this cohort are not protected sites with a minor configuration detail to tidy; they are sites where the HSTS protection resets between visits, leaving every returning user who hasn’t visited recently in the same exposed position as a site with no HSTS at all.

For organisations with subdomains — and almost every organisation with a meaningful web presence has subdomains for login, API, staging, or regional sites — the includeSubDomains gap is the higher-priority item. A site that sends HSTS on its apex but not its login. subdomain has protected the homepage while leaving the most sensitive path unprotected. Test every subdomain for HTTPS before adding the directive, but add it. The omission is not a safe state.

The preload paradox — 1,020,612 domains asking for browser preload protection while simultaneously disqualifying themselves in the same header — is a precise illustration of why security configuration without review is not security. If you have deployed HSTS with a preload directive, check whether your max-age is at least 31,536,000 seconds. If it is not, you have asked for the strongest HSTS protection available and specified a number that makes it unreachable. The fix is changing one integer.

Data to cite

• “56.2% of 329,886,554 HTTPS domains evaluated in the August 2026 census — 185,452,267 domains — send no Strict-Transport-Security header, leaving them vulnerable to SSL-stripping attacks on every new visitor’s first request.” — defaults.exposed August 2026 Domain Security Census (432M domains)
• “Of the 144,434,287 domains that deploy HSTS, only 4.1% — 5,959,894 domains — publish a preload-ready policy with a max-age of at least one year and the preload directive.” — defaults.exposed August 2026 Domain Security Census (432M domains)
• “13,237,687 domains deploy HSTS with a max-age under six months — protection that resets between visits, leaving returning users as exposed as sites with no HSTS at all.” — defaults.exposed August 2026 Domain Security Census (432M domains)
• “1,020,612 domains publish the HSTS preload directive with a max-age too short to qualify for browser preload lists — simultaneously asking for the strongest HSTS protection and disqualifying themselves in the same header line.” — defaults.exposed August 2026 Domain Security Census (432M domains)
• “Only 1.81% of HTTPS domains measured in the August 2026 census have a preload-ready HSTS policy — the configuration that browser vendors consider the complete implementation of HSTS is a rounding error on the wider web.” — defaults.exposed August 2026 Domain Security Census (432M domains)
• “The most common HSTS deployment on the measured internet is the basic form with no includeSubDomains and no preload — genuine protection for returning visitors to the exact hostname, but nothing for subdomains, first visits, or visitors whose last visit predates the max-age.” — defaults.exposed August 2026 Domain Security Census (432M domains)

FAQ

What percentage of websites use HSTS in 2026? 43.8%, measured as domains rather than websites: 144,434,287 of the 329,886,554 domains that served an evaluable HTTPS response in our August 2026 census sent a Strict-Transport-Security header. The remaining 56.2% serve HTTPS without instructing browsers to require it.

What max-age should I set for HSTS? The finished state is at least one year — 31,536,000 seconds — which is also the minimum for browser preload eligibility (industry criteria from hstspreload.org). Starting lower while you confirm nothing on your domain still needs plain HTTP is sensible; the mistake we see at scale is never coming back to raise it.

Is HSTS preload worth it? Preload is the only mechanism that protects a visitor’s very first request, before your header has ever been seen, which closes the SSL-stripping window completely. Only 4.1% of HSTS deployers in our census publish a preload-ready policy. The commitment is real — removal from the preload list is slow — so it belongs at the end of a deliberate rollout, not the beginning.

Does HSTS work without includeSubDomains? Yes, for the exact hostname that sent the header. But every subdomain without its own policy stays strippable, and login pages, APIs and forgotten test hosts live on subdomains. The large majority of HSTS deployers we measured omit the directive. Add it once you have verified all subdomains serve HTTPS — it applies to every one of them the moment it ships.

Can I have the preload directive with a short max-age? You can publish it, and 1,020,612 domains in our census do — 14.6% of all preload-directive publishers. But the published inclusion bar requires a max-age of at least one year, so the request is self-disqualifying: browsers honour the short max-age they were given, and the preload application could never be accepted as written.

What should I do right now to improve my HSTS configuration? Three steps in order: (1) If your max-age is under 31,536,000 seconds, change the number — it is a single integer edit. (2) If you have no includeSubDomains, audit your subdomains for HTTPS and add the directive once you have confirmed they all serve it. (3) If you want full first-visit protection, add the preload directive and submit to hstspreload.org — but only after steps 1 and 2, because preload is irreversible on a short timescale. Skipping to step 3 while missing steps 1 or 2 describes exactly the 1,020,612 self-disqualifying domains in this census.

How does HSTS adoption compare to the July 2026 census? August 2026 is the immediately following measurement. The 56.2% no-HSTS figure and the 4.1% preload-ready figure reflect the state at 16 August 2026 across 329,886,554 evaluated HTTPS domains. Improvement in HSTS quality is driven primarily by platform upgrades rather than individual operator action — which is why the numbers move slowly and the middle tiers (six months to one year) remain nearly empty.

Why does HSTS matter for GDPR and compliance frameworks? HSTS is required by NIST SP 800-52 Rev 2 for US federal agencies and referenced in UK Cyber Essentials guidance as part of secure HTTPS configuration. Under GDPR, a site that serves personal data and does not instruct browsers to require HTTPS may face scrutiny on whether it has implemented “appropriate technical measures” under Article 32, since the absence of HSTS leaves encrypted transport optional rather than enforced. This is regulatory context, not legal advice.

Related reading

• The HTTP security header report card — presence rates across the whole header family; this article is the depth cut on one of them.
• Why does my website say “Not Secure”? — the visitor-facing side of the HTTPS story.
• Weak and outdated TLS — what the encrypted connection itself is made of, once HSTS gets you onto it.
• The internet security grade curve — where header hygiene sits inside the full A–F distribution.

See where your own domain stands

Check your domain free at defaults.exposed — see exactly how your domain scores on HSTS configuration, including your current max-age tier, whether you have includeSubDomains, and whether your preload directive qualifies. Takes 30 seconds. No account needed. Read the flagship State of Domain Security 2026 report.

Aggregate data only. Data stored and processed in the EU.

How to cite this report

Press / blog: defaults.exposed (2026). HSTS Adoption 2026: The Half-Locked Door. defaults.exposed August 2026 Domain Security Census (432,127,908 domains scanned, asOf 2026-08-16). Retrieved from https://defaults.exposed/en/articles/hsts-adoption-the-half-locked-door

Academic: defaults.exposed. (2026, August 18). HSTS Adoption 2026: The Half-Locked Door. In defaults.exposed Domain Security Census: August 2026. https://defaults.exposed/en/articles/hsts-adoption-the-half-locked-door

In-line citation: (defaults.exposed, August 2026 Domain Security Census, n=329,886,554 HTTPS-evaluated domains)

About the defaults.exposed August 2026 Census

The defaults.exposed Domain Security Census is a recurring independent measurement of the public domain namespace. The August 2026 edition scanned 432,127,908 domains between 1–16 August 2026 and graded 376,928,781 of them using methodology v9. Scans are conducted from EU infrastructure. No individual domain, registrant, or business is named in any report. All figures are aggregate distributions. Data is stored and processed within the EU.

Methodology: defaults.exposed/en/articles/domain-security-scoring-methodology-v9 Full census report: defaults.exposed/en/articles/the-state-of-domain-security-2026