How should an SME introduce HSTS without stranding a subdomain?

Start with the actual browser decision

HSTS is a browser instruction carried by an HTTPS response. After receiving a valid Strict-Transport-Security header, a supporting browser remembers the host and upgrades later HTTP attempts to HTTPS for the specified max-age. It also treats a certificate error as a hard failure rather than an exception that a visitor can click through. This can reduce exposure when somebody follows an old HTTP link, but it cannot repair an expired certificate or a misconfigured HTTPS endpoint. The business decision is therefore whether every affected host can serve a trustworthy HTTPS connection throughout the policy period.

A normal HTTP-to-HTTPS redirect and HSTS solve different moments in the journey. On a first visit without a preloaded policy, the browser may still make an HTTP request before seeing a redirect and then the HTTPS header. HSTS protects subsequent requests after the browser has learned the rule. Preloading can cover the first contact, but entry into a browser preload list has broader and harder-to-reverse effects. Do not describe a redirect, a header, or a preload submission as proof that the whole journey is safe; test what a fresh browser and a returning browser actually do.

Write down the proposed scope before changing configuration. A policy sent by shop.example.com applies to that host, while includeSubDomains extends a policy to names beneath the host that sent it. A policy at example.com with includeSubDomains can therefore affect the shop, booking and old campaign hosts under it. The parent policy is learned only after that parent is visited unless it is preloaded; each subdomain may also keep its own independently learned policy. Draw this boundary on a host map so that marketing, support and IT are discussing the same affected names.

The max-age clock is refreshed whenever a browser receives the header again, so a supposedly temporary setting can persist for active visitors if the site keeps sending it. Do not assume a short initial value automatically expires after the first trial day. Mark the planned review date in the configuration change and arrange an explicit decision to keep, extend or remove the rule. When operations hands over to another provider, include the HSTS state in the handover, because a new provider must preserve valid HTTPS even if it did not create the original policy. This is particularly relevant when the domain owner and website supplier are different parties.

Inventory hosts and failure paths

Start from DNS records, edge and hosting configuration, certificate inventories, old redirect rules and links found in customer communications. Include names that are rarely used: a returns portal, a supplier login, a one-off promotion, a payment callback, or a legacy subdomain that still resolves. A wildcard certificate is not a substitute for checking where each hostname terminates, whether the certificate is actually served there, and whether the application works on HTTPS. Record the owner, expected users, current HTTP behaviour, certificate coverage and renewal owner for each hostname.

Test the complete path rather than accepting a green lock on the homepage. Visit a representative deep link on HTTPS, confirm the certificate matches that exact hostname, follow redirects, submit a harmless test enquiry where appropriate and check that resources and callbacks still work. Inspect responses from the public edge, not only the origin server: a CDN, load balancer or alternate host can add, remove or duplicate the header. Test both the bare domain and www host when both exist. A plan to retire a forgotten host must be completed before a broad policy makes its HTTP-only page unreachable.

Separate an actual HTTPS failure from a browser that remembers an older policy. Use a clean browser profile to observe first contact, then revisit after receiving the header; capture the response header and final URL in each case. A server header on an HTTP response does not establish HSTS, because the browser learns the policy from HTTPS. A browser profile that previously saw a longer max-age may remain affected after a quick server-side change. That is why a staging hostname and a controlled trial with known browser state are more informative than repeatedly refreshing one administrator tab.

Stage the rule and define a stop condition

Begin with a short-lived policy on a host whose HTTPS path is proven. Chrome guidance gives max-age=3600 as an example of an initial stage and 604800 as a subsequent stage after a quiet period. These are examples of a staged approach, not a promise that one week of monitoring is sufficient for every business. Pick monitoring windows that cover the services actual usage cycle, such as a monthly invoicing portal or a seasonal campaign. Increase the duration only after service owners confirm that affected journeys and certificate renewal controls work.

Treat includeSubDomains as a separate expansion, not a routine suffix to paste into a configuration file. Before applying it at the parent domain, produce a signed-off list of every current and planned subdomain and show HTTPS evidence for each live host. Include externally operated marketing or support tools if they use names beneath your domain. If a vendor cannot support HTTPS correctly, choose a narrower host-only policy while the dependency is resolved. A customer encountering a hard certificate error on that vendor hostname will not care which team owns it.

Keep a rollback plan that is honest about browser memory. Serving max-age=0 over working HTTPS tells a browser to remove that hosts learned policy, but browsers must reach that valid HTTPS response to receive it. It does not remove a separate policy already learned for another host; nor is it a practical instant reversal of a shipped preload entry. If a certificate is broken, the immediate repair is to restore valid HTTPS, not to rely on a header that the affected browser cannot safely receive. Keep emergency certificate and routing contacts beside the rollout record.

Work through a mixed-host example

Imagine a shop whose main site, account area and booking subdomain all use HTTPS, while an old event subdomain still serves a landing page over HTTP. The owner wants one strong parent-domain HSTS setting. The host inventory reveals that applying includeSubDomains at the parent would upgrade attempts to visit the event host and make that page fail until HTTPS is fixed or the host is retired. The reasonable first decision is to correct or close the event host, verify the other journeys, then trial a short parent policy. The example is a planning exercise, not a claim about a real client.

Now add a supplier portal visited only at month end. A one-day trial that sees no complaints tells little about that portal. Schedule a test account and an owner to exercise its login, download and logout before the policy period is increased. If it runs under a third-party service, ask for evidence of the public hostname and renewal process rather than assuming the vendor brand guarantees your custom domain. This small scheduling detail changes the decision: the policy can advance after coverage of actual use, not merely after the clock has run for a week.

Preloading belongs at the end of this journey. MDN says the preload directive requires includeSubDomains and at least a one-year max-age; submitting a domain to a preload service is an additional step, not something that happens just because the header contains the word preload. Check the current preload service requirements and the consequences of removal before committing. For a small business that cannot confidently account for future subdomains, a properly tested non-preloaded policy may be the more responsible current state. Record that as a conscious scope choice rather than presenting an audit score as the business goal.

Record acceptance evidence

A useful acceptance record contains the host inventory version, the exact header observed on a public HTTPS response, the date and browser state of first-visit and repeat-visit tests, certificates checked against hostnames, representative journeys exercised, exceptions, and an owner for each open issue. Record the chosen max-age and why it covers the tested operational cycle. Monitor HTTPS failures, certificate expiry signals and customer reports during each stage. These records let a later maintainer distinguish an intentional policy from an accidental proxy setting, and they make the next increase a reviewable decision rather than a blind configuration change.

One final check is to explain the remaining limitation to decision makers. HSTS is a strong browser transport rule once learned, but it is not a full website security review, a certificate monitoring service, or evidence that every back-end connection is encrypted. If the immediate problem is a failing certificate or missing HTTPS endpoint, fix that defect first. If the issue is an old HTTP link, keep its HTTPS redirect working even after HSTS is deployed. A clear boundary helps the owner fund the right fix and avoids treating a security header as a substitute for operating the site.