Google’s HTTPS update: What it means and how to prepare

On 28 October 2025, Google announced that Chrome will enable “Always Use Secure Connections” by default, starting with Chrome 154 in October 2026. Before that, the change rolls out to users who’ve opted into Enhanced Safe Browsing beginning April 2026 (Chrome 147). In practice, Chrome will ask for user permission before the first visit to any public site that doesn’t support HTTPS. 

At Red Sift, we welcome this move. It’s a pragmatic nudge that protects users from hijacked navigations and silent HTTP→HTTPS downgrades, risks that persist even though most of the web already uses HTTPS. Google’s data shows adoption plateaued at ~95–99% years ago; getting the rest of the way requires default-secure behaviour from browsers.

• Now → April 2026: Chrome continues experimenting and outreach; Enhanced Safe Browsing users get the new default in Chrome 147 (April 2026).
• October 2026: “Always Use Secure Connections” is on by default for everyone in Chrome 154. Users can still opt out in settings.

This shift builds on Chrome’s long-stated goal of moving towards HTTPS by default and past introductions of HTTPS-First/Always-Use-Secure-Connections modes and enterprise policy controls.

• Prevents invisible risks. Many HTTP navigations immediately redirect to HTTPS; the initial hop is still attackable. By prompting before the first HTTP visit to a public site, Chrome blocks that foothold.
• Reduces user friction smartly. Chrome avoids warning repeatedly about sites users visit often, keeping prompts below a few per week for nearly all users in Google’s experiments.
• Unblocks legacy use cases. New Local Network Access permissions let HTTPS pages talk to devices on your LAN without mixed-content breakage, making it more feasible to migrate admin portals and device set-ups to HTTPS.

1. Inventory all public HTTP endpoints (including forgotten subdomains and microsites). Prioritise anything that still does HTTP-only or performs an HTTP hop before redirecting to HTTPS.
2. Enable HSTS (Strict-Transport-Security) with an appropriate max-age, add includeSubDomains, and consider preloading once you’re confident. HSTS tells browsers to only use HTTPS for your domain.
3. Eliminate mixed content. Audit pages so every resource (scripts, images, iframes, APIs) loads over HTTPS. Mixed content undermines the protection HTTPS provides.
4. Harden TLS. Use modern protocols/ciphers and follow recognised deployment best practices (e.g., SSL Labs guidance).
5. Plan for internal/IoT scenarios. Where certificates for private names are tricky, evaluate migration patterns (e.g., device portals on DNS names you control, with valid certs) and use Chrome’s Local Network Access permission model where appropriate.
6. Prepare help content. Update your support docs and status pages so end-users understand any Chrome warning they might see if they hit legacy HTTP links before you finish migration.
7. (Enterprise) Validate policy posture. If you manage Chrome via policy, review controls mentioned in Chrome’s HTTPS-by-default guidance (e.g., HttpsOnlyMode / allowlists) and set a plan that fits your risk tolerance.

In 2022 we acquired Hardenize to extend Red Sift’s portfolio beyond email into comprehensive web and TLS posture monitoring, creating Red Sift ASM. Paired with Red Sift Certificates, you get end-to-end control: automatically discover stray HTTP(S) services and unmanaged certs, validate certificate hygiene, enforce HSTS and modern TLS, track expiries, automate renewals, and watch for configuration drift—before Chrome’s defaults start prompting your users.

• Asset discovery and shadow IT: Find public hosts and subdomains you didn’t know you had—including those still serving HTTP.
• TLS/HSTS readiness: Continuous checks for cert validity, expiries, protocol/cipher posture, HSTS presence, and redirect integrity.
• Mixed-content and dependency hygiene: Surface insecure resource loads and third-party calls that can trigger warnings or weaken security.
• Governance at scale: Track progress to 100% HTTPS across brands and regions; exportable reports for execs and auditors.

While this update is about the web layer, it complements brand and email trust (e.g., DMARC/BIMI) by ensuring what users click is protected end-to-end. A secure site and a verifiably trusted email sender are two halves of the same brand-safety story.DMARC/BIMI) by ensuring what users click is protected end-to-end. A secure site and a verifiably trusted email sender are two halves of the same brand-safety story.

• What users will see: If they try to visit a public site over HTTP for the first time, Chrome will warn and ask for consent before proceeding. Returning visits won’t be nagged repeatedly.
• Why some internal portals aren’t warned: Private addresses behave differently because of certificate challenges and lower exploitability, but they still deserve a migration plan.
• Why “redirects to HTTPS” isn’t enough: The initial HTTP hop can be intercepted—Chrome’s change removes that silent risk.

This is the right default at the right time. The last few percent of HTTP navigations represent an outsized share of real-world risk. By setting a secure-by-default baseline—without overwhelming users with prompts—Chrome is helping close long-standing gaps. We’re fully aligned with that goal and ready to help organisations get to 100% HTTPS coverage, cleanly, measurably, and fast. 

If you’d like a quick readiness assessment of your public web estate ahead of Chrome 147/154 with Red Sift ASM, we can run a targeted scan and share a remediation plan tailored to your domains. It’s quick and easy, book a free demo today.book a free demo today.