Google announced that Chrome will warn users before it first loads a public website over plain HTTP, by turning on the "Always Use Secure Connections" setting by default, and any site or internal application that still serves HTTP will put that warning in front of its users. The change completes a programme that began with automatic HTTPS upgrades and the opt-in HTTPS-First Mode. Google's plan treats public and private sites differently, and gives managed organisations policies to tune or enforce the behaviour. This guide sets out the official timeline, what users see, which sites and apps are affected, how to find them, and how to migrate or exempt them safely. It is for web, platform and endpoint teams; for server-side TLS settings see the TLS Server Configuration Baseline Guide.
This is an independent guide from NHI Mgmt Group, based on Google's public documentation as of November 2026. It is not sponsored or reviewed by Google. Product features change, so confirm settings against Google's current documentation.
Key takeaways
- Public HTTP sites get a warning first. With the public-sites variant on, Chrome warns before the first load of a public site over HTTP. The warning can be bypassed, and Chrome does not keep warning about sites a user visits regularly.
- Private sites are treated differently. Google's default variant does not warn for local IP addresses such as 192.168.0.1, single-label hostnames or shortlinks like intranet/. Internal apps on fully qualified names that resolve publicly are a different matter: test them.
- Timeline as announced: Chrome 147 (April 2026) for users opted into Enhanced Safe Browsing, then Chrome 154 (October 2026 in Google's post) for all users, with the setting remaining user-controllable.
- Enterprises have three policies. HttpsOnlyMode controls the setting (allowed, disallowed, force_enabled, force_balanced_enabled), HttpAllowlist exempts named hosts, and HttpsUpgradesEnabled controls automatic upgrades.
- The fix is HTTPS, not exemptions. Allowlisting keeps users working, but every exempted host is still open to interception. Use exemptions as a dated bridge while certificates and redirects are put in place.
What is changing and why
Chrome has three related behaviours. HTTPS Upgrades, announced on the Chromium blog in August 2023, automatically upgrades http:// navigations to https:// and falls back to HTTP if the upgrade fails, for example on an invalid certificate. HTTPS-First Mode, shown in settings as "Always use secure connections", asks for explicit permission before connecting to a site insecurely. The new step is turning the public-sites variant of that setting on by default.
Google's stated reason is that a single insecure navigation can be hijacked to deliver malware, exploits or social engineering, that tools for this are readily available, and that HTTP has been used in targeted attacks. Many HTTP requests are invisible to users because they redirect immediately to HTTPS, so the "Not Secure" address bar label never appears; an attacker on the path can intercept that first request. In ATT&CK terms the risk is adversary-in-the-middle (T1557) and content injection (T1659) leading to drive-by compromise (T1189). Google reports that HTTPS share of main-frame page loads plateaued at about 95 to 99 percent from around 2020, so the remaining HTTP traffic is a long tail that only a default change will move.
The two variants
| Setting option (Chrome Help wording) | Policy value | Warns for public HTTP sites | Warns for private HTTP sites |
|---|---|---|---|
| Warns you for insecure public sites | force_balanced_enabled (Balanced mode, supported from Chrome 129) | Yes | No |
| Warns you for insecure public and private sites | force_enabled (Strict mode, supported from Chrome 112) | Yes | Yes |
| Setting off | disallowed (disables the mode) | No interstitial; "Not Secure" label only | No |
Chrome Help notes that under Android Advanced Protection the setting is turned on with the public and private option selected, so high-risk users may already see warnings for intranet HTTP.
Official timeline and current status
| Milestone | What happens | Source |
|---|---|---|
| August 2023 | HTTPS Upgrades experiment in Chrome 115; plan to make HTTPS-First Mode the default eventually | Chromium Blog, 16 August 2023 |
| Chrome 141 | Default-on experiment for a small percentage of users; median user saw fewer than one warning a week, 95th percentile fewer than three | Google Online Security Blog |
| Chrome 147 (April 2026) | Public-sites variant enabled for users opted into Enhanced Safe Browsing (over 1 billion users, per Google) | Google Online Security Blog |
| Chrome 154 (October 2026 in Google's announcement) | Public-sites variant enabled by default for all users | Google Online Security Blog |
Status on 8 November 2026: the Chromium release schedule lists a Chrome 154 stable date of 22 September 2026, earlier than the month in Google's announcement. Google's post describes the plan; it does not confirm per-user rollout, and Chrome features are often enabled gradually after a release. Treat the default as arriving now and check chrome://settings/security on a representative unmanaged device to see the current state. Managed policy overrides the default either way.
Who and what is affected
| Asset | Likely effect | Priority |
|---|---|---|
| Public websites or landing pages still on HTTP | Warning on first visit by new visitors; lost trust and conversions | High |
| Public sites that serve HTTPS but are linked as http:// without redirect or HSTS | Usually upgraded automatically; first request still exposed until HSTS is in place | Medium |
| Internal apps on fully qualified hostnames (app.corp.example.com) over HTTP | May be classed as public depending on how the name resolves; test | High |
| Internal apps on private IPs, single-label names or shortlinks | No warning under the default public-sites variant; warnings under Strict mode | Medium |
| Device admin pages (printers, NAS, cameras, OT HMIs) | Mostly private IPs; HTTPS pages that call them hit mixed content blocking | Medium |
| Captive portals, legacy SSO pages, HTTP-only APIs called from pages | Interstitials or blocked subresources | Variable |
Google also describes Chrome's local network access permission, which lets an HTTPS site reach local devices after the user grants permission. That helps vendors move device configuration portals to HTTPS without breaking the local call.
Finding affected systems and identities
- Turn it on early in IT. Google advises developers and IT staff to enable the setting now. Push HttpsOnlyMode = force_balanced_enabled as a recommended policy to an IT ring, then force_enabled to a smaller test ring to see private-site impact too.
- Mine proxy and DNS logs. List destinations reached over TCP 80 without a following redirect to 443, grouped by hostname and user count. Separate public names from private IP and single-label destinations.
- Scan your own estate. From an external attack surface inventory and internal web inventory, record for each host: HTTPS available, certificate valid and trusted, HTTP to HTTPS redirect, HSTS header present. See the HSTS and HSTS Preload guide.
- Check embedded HTTP. Crawl HTTPS pages for http:// subresources and form actions; mixed content is blocked or upgraded regardless of this change, so these are existing defects.
- Find exemptions already in place. Review any existing HttpAllowlist and InsecureContentAllowedForUrls entries and their owners.
- Collect help desk signals. Tag tickets mentioning the Chrome warning page during pilot rings to catch apps logs missed.
Migration options
| Situation | Recommended action | Bridge if needed |
|---|---|---|
| Public site on HTTP | Issue a certificate (automate with ACME), redirect all HTTP to HTTPS, add HSTS | None advisable: public users are unmanaged |
| Internal app on a fully qualified name | Certificate from an internal or public CA trusted by managed devices, redirect, HSTS once stable | HttpAllowlist entry for the exact host, with an expiry in your change record |
| Internal app on private IP or single-label name | Move to a named host with a certificate; short names complicate certificates anyway | Default public-sites variant does not warn; avoid force_enabled until migrated |
| Device admin interface | Enable the device's HTTPS option or upgrade firmware; restrict management to an admin network | HttpAllowlist pattern for the device subdomain |
| Vendor SaaS still on HTTP | Raise with the vendor as a security finding | Allowlist only if the business accepts the risk in writing |
Policy decisions
- HttpsOnlyMode: force_balanced_enabled matches Google's default and is the sensible baseline for most organisations. force_enabled (Strict) suits high-risk users and organisations that have migrated intranet apps. disallowed turns the protection off and should be rare. Unsupported values fall back to allowed, so check client versions.
- HttpAllowlist: hostnames or patterns such as [*.]example.com that will not be upgraded and will not show an interstitial. Names must be canonical (lowercase, IDNs as A-labels). Blanket wildcards such as * are not allowed, and the policy does not apply to HSTS upgrades.
- HttpsUpgradesEnabled: leave unset or true. Setting false disables automatic upgrades and should only be a temporary fix for a broken upgrade path, such as a host whose HTTPS port serves a different application.
- InsecureContentAllowedForUrls: separate from this change; it allows blockable mixed content on listed sites and should be kept to a minimum.
Small versus large organisations: a small organisation with a handful of internal apps can usually issue certificates and skip allowlisting. A large estate should run a register of HTTP hosts with owners, use HttpAllowlist for a fixed period per host, and report the list shrinking month by month. Certificate automation is the enabler; see the ACME and Automated Certificate Management Guide.
Where identity fits
Every new HTTPS endpoint means a certificate and private key, which are machine identities that need an owner, automated renewal and inventory. Rushing internal apps onto long-lived, manually issued certificates swaps a warning today for an outage at expiry. See the Certificate Expiry Outages and 47-Day TLS Certificates Guide.
Testing and rollback
- Ring 0 (IT): HttpsOnlyMode force_balanced_enabled, then force_enabled for a subset, for two weeks.
- Remediate or allowlist: fix hosts found; add time-boxed HttpAllowlist entries for the rest.
- Ring 1 (pilot business users, 5 to 10 percent): apply the chosen baseline and monitor tickets and proxy logs.
- Broad rollout: apply to all managed browsers. Because these policies support dynamic refresh, changes apply without a browser restart.
- Verify: confirm policy state in
chrome://policyon sample devices.
Rollback: add the failing host to HttpAllowlist rather than disabling the mode for everyone. If a whole class of hosts breaks, move the affected group back to the allowed value temporarily. Users can bypass the warning in any case, so the change rarely blocks work outright; the main risk is users learning to click through warnings, which is why fixing hosts matters more than suppressing warnings.
Detection and measurement
- Distinct public hostnames reached over HTTP from managed devices per week: trending to zero.
- Internal HTTP applications in the register, and the share with an owner and a migration date.
- HttpAllowlist entries, and the number past their expiry.
- Your own public hosts with valid HTTPS, redirect and HSTS: target 100 percent.
- Help desk tickets citing the Chrome warning, per week during rollout.
Risks of doing nothing
- Customer-facing warnings: new visitors to any remaining HTTP public page see a warning before the page loads.
- Warning fatigue: internal users trained to click through interstitials are easier targets for real interception and phishing.
- Interception stays possible: HTTP pages and first requests without HSTS remain open to tampering on hostile networks (T1557, T1659).
- Uncontrolled exceptions: users may switch the setting off themselves on unmanaged profiles; on managed devices, decide by policy rather than leaving it to users.
Common failure patterns
- Allowlisting a whole internal domain with a broad pattern and never removing it.
- Setting HttpsUpgradesEnabled to false estate-wide to fix one broken host.
- Moving an app to HTTPS without a redirect and HSTS, so old http:// bookmarks still trigger the first insecure request.
- Issuing manual one-off certificates for dozens of internal apps with no renewal automation.
- Assuming intranet apps are "private" when their fully qualified names resolve in public DNS.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-8, SC-8(1), SC-23 | Transmission confidentiality and integrity; session authenticity |
| NIST SP 800-53 Rev 5 | CM-6 | Managed browser configuration settings |
| NIST CSF 2.0 | PR.DS-02 | Data in transit protected |
| CIS Controls v8.1 | 3.10 | Encrypt sensitive data in transit |
| MITRE ATT&CK v20 | T1557, T1659, T1189 | Interception, content injection and drive-by compromise |
Practitioner checklist
- Inventory every public and internal host still serving HTTP, with an owner for each.
- Enable HttpsOnlyMode force_balanced_enabled for IT now and record what breaks.
- Fix your public sites first: certificate, redirect, HSTS, and no mixed content.
- Move internal apps to named hosts with automated certificates trusted by managed devices.
- Use HttpAllowlist only for exact hosts, with an expiry date in the change record.
- Keep HttpsUpgradesEnabled on, and keep InsecureContentAllowedForUrls short.
- Decide whether high-risk groups should run Strict mode (force_enabled) once intranet apps are migrated.
- Track the five metrics monthly and report the HTTP host register shrinking.
Standards and references
- Google Online Security Blog: HTTPS by default
- Chromium Blog: Towards HTTPS by default
- Google Chrome Help: Always use secure connections setting
- Chromium: HttpsOnlyMode policy definition
- Chromium: HttpAllowlist policy definition
- Chromium: HttpsUpgradesEnabled policy definition
- Chromium Dash: Chrome 154 milestone schedule
Related NHI Mgmt Group resources: TLS Server Configuration Baseline Guide · HSTS and HSTS Preload · Security Headers Guide · Browser Security Hardening Guide · ACME and Automated Certificate Management Guide