Chrome to Enforce HTTPS by Default in 2026: What Security Teams Need to Know

Chrome to Enforce HTTPS by Default Starting October 2026

Google has announced that Chrome will enable "Always Use Secure Connections" by default beginning with Chrome 154 in October 2026. This change will require user permission before accessing any public site without HTTPS, marking a significant shift in the browser’s security posture.

Key Details

• Timeline: The setting will roll out to Enhanced Safe Browsing users in Chrome 147 (April 2026) before becoming default for all users in Chrome 154 (October 2026).
• Scope: The feature will apply to public sites only, excluding private/local network addresses (e.g., 192.168.0.1, intranet/).
• User Impact: Chrome will show a bypassable warning for non-HTTPS sites, with frequency limited to new or infrequently visited domains to minimize disruption.

Technical Rationale

Google’s decision stems from persistent security risks associated with HTTP, including:

• Man-in-the-middle (MITM) attacks: Attackers can hijack navigations to inject malware, exploit vulnerabilities, or conduct phishing. Google’s Threat Analysis Group has documented real-world exploits leveraging HTTP for targeted attacks.
• Invisible redirects: Many HTTP sites immediately redirect to HTTPS, masking the initial insecure connection from users and Chrome’s "Not Secure" warnings.
• Stagnant HTTPS adoption: While 95–99% of public site navigations now use HTTPS (per Google’s transparency report), the remaining 5% of HTTP traffic still poses significant risks. Private/local sites lag further, with adoption as low as 84% on Linux.

Impact Analysis

Security Benefits

• Reduces attack surface: HTTPS-by-default mitigates MITM risks for public sites, which are prime targets for exploitation.
• Encourages HTTPS migration: Organizations with overlooked HTTP sites (e.g., those using HTTP-to-HTTPS redirects) will be incentivized to adopt HTTPS fully.
• Local network improvements: Google’s Local Network Access permission allows HTTPS sites to bypass mixed-content blocking for approved local devices, enabling secure configurations.

Potential Challenges

• Enterprise/local network friction: Private sites (e.g., routers, IoT devices) may lack HTTPS certificates due to non-unique naming (e.g., 192.168.0.1), though these are lower-risk than public sites.
• User fatigue: While warnings are limited to new/infrequent sites, some users may still find them disruptive. The setting remains opt-out.

Recommendations

1. For Security Teams

   • Audit HTTP usage: Enable "Always Use Secure Connections" in Chrome today (chrome://settings/security) to identify sites requiring HTTPS migration.
   • Prioritize public sites: Focus on domains with HTTP redirects or mixed content, as these are most likely to trigger warnings.
   • Leverage local network permissions: Use Chrome’s Local Network Access API to secure HTTPS interactions with local devices.

2. For Developers/IT Admins

   • Review Google’s guidance: Consult the adoption guide for enterprise-specific mitigations.
   • Test in advance: Deploy Chrome 147 (April 2026) to validate compatibility with internal tools and private sites.

3. For Website Owners

   • Eliminate HTTP redirects: Ensure all public domains load directly over HTTPS to avoid warnings.
   • Obtain certificates for private sites: Explore solutions like Let’s Encrypt or internal CAs for local networks.

Looking Ahead

Google plans to further reduce barriers to HTTPS adoption, particularly for local network sites. Future updates may extend protections to private domains, though no timeline has been announced.

For now, security teams should treat this change as a catalyst to eliminate residual HTTP dependencies and harden web-facing infrastructure against MITM threats.

Posted by the Chrome Security Team (Chris Thompson, Mustafa Emre Acer, Serena Chen, Joe DeBlasio, Emily Stark, David Adrian).