Common signs include users still reaching the site over plain HTTP, mixed use of insecure URLs in bookmarks or redirects, and subdomains that were not covered by the certificate or includeSubdomains directive. If the header is absent on responses, or max-age is too short, browsers may not treat the site as HTTPS-only consistently.
Why HSTS fails quietly even when it is configured
HSTS only protects a site after the browser has actually learned and retained the policy for the host. If the header is missing on some responses, the max-age is too short, or the policy was never applied to the right hostnames, users can still fall back to HTTP or remain exposed during first contact. The practical test is whether every relevant browser path is consistently forced onto HTTPS.
A site can appear "mostly secure" while still failing at the edges. That usually shows up as inconsistent redirects, cached bookmarks that resolve to HTTP first, or subdomains that were never included in the policy. NIST Cybersecurity Framework 2.0 is useful here because the issue is not only transport encryption, but whether the protective control is operating reliably across the full user path.
If the browser never sees a valid HSTS policy for a hostname, the control does not engage for that hostname. That means the failure can be structural, such as missing includeSubdomains coverage, or operational, such as a redirect chain that still allows an initial HTTP hop before the browser upgrades future requests.
What broken HSTS looks like in real user traffic
One of the clearest signs is any successful user access over plain HTTP after HSTS should have been established. That may be visible in logs, support reports, browser dev tools, or security telemetry. If users can still reach the site through an HTTP URL without being forced to HTTPS, the policy is not being enforced as intended.
Another sign is inconsistency by entry point. Home page traffic may look fine while deep links, old bookmarks, vanity domains, alternate subdomains, or legacy redirects still resolve insecurely. This often means the header is only present on some responses, the certificate coverage does not match the full host set, or the browser has not yet received a long enough max-age to remember the rule.
Configuration mistakes also show up when subdomains are treated as an afterthought. If a parent domain is protected but a child host is left out, browsers may continue to allow HTTP to the uncovered subdomain. That is especially important for sites with mixed DNS ownership, third-party services, or older hosts that were never folded into the same policy. The CA/Browser Forum baseline expectations around certificate issuance and revocation matter here because incomplete hostname coverage can undermine the policy even when the main site appears correctly secured.
For practitioners, the useful distinction is between "header present somewhere" and "policy effective everywhere". HSTS is behaving correctly only when the browser can consistently upgrade all intended hostnames, including subdomains and repeat visits, without relying on the user to remember HTTPS manually.
How to verify the control is actually working
Verification should be path-based, not just configuration-based. Check the live response headers on the primary host and every relevant subdomain, confirm that max-age is long enough to persist between visits, and confirm that the browser receives the policy on the redirect target as well as the final page. If you only test the landing page, you can miss the exact path that users and crawlers actually follow.
It is also worth testing browser behavior after policy expiry, after clearing cache, and from a fresh profile. If the site still relies on an initial HTTP request, the browser cannot protect first-time visitors until the policy is re-established. Where certificate scope is involved, validate that all intended names are covered and that no subdomain is left outside the HTTPS-only boundary.
A practical control signal is whether HTTP is ever reachable in normal operation. If HTTP remains accessible for any production hostname, the control is either incomplete or dependent on assumptions that are too fragile. The right verification target is not "does HTTPS work", but "can the site still be reached over HTTP in any ordinary user path".
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC — Identity Management, Authentication and Access Control | HSTS is a transport access control for secure web sessions. |
| Recommendation — Enforce HTTPS-only access and verify browsers cannot use HTTP paths. | ||
| CIS Controls v8 | 6 — Access Control Management | HSTS failures expose insecure access paths that access controls should eliminate. |
| 15 — Service Provider Management | Subdomain and redirect gaps often involve third-party or externally managed hosts. | |
| Recommendation — Remove any production HTTP access paths and validate HTTPS enforcement. Confirm every externally managed hostname follows the same HTTPS policy. | ||
Practitioner Guidance
What to verify: Confirm the HSTS header is present on the exact hostnames users hit, not just on the canonical homepage. Then test a fresh browser session to make sure the policy survives real user navigation, redirects, and bookmarked URLs.
Common mistake: Teams often validate the certificate and stop there. HSTS can still fail if max-age is too short, the header is only on some responses, or child domains are outside the policy scope.
Practitioner takeaway: Treat HSTS as effective only when it removes HTTP as a usable path across the whole hostname set, because partial coverage is a control gap, not a minor configuration flaw.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
