Chrome HTTPS Warnings from October

In October 2026, Google Chrome changes a default that has been optional for years. Starting with Chrome 154, the browser will switch on "Always Use Secure Connections" for everyone. From that point, Chrome will try HTTPS first for every address, and before loading a public website that only answers over plain HTTP, it will stop and show the visitor a warning page asking whether they really want to continue.

This is a future-dated change, and that is the point of writing about it now. For most Monaco businesses it will be a non-event, because their site already runs on HTTPS. For a minority — usually the ones who last touched their website several years ago — it will quietly turn a working page into a "this site is not secure" screen, and nobody in the company will know until a client mentions it.

What is actually changing

Chrome has had an opt-in setting called "Always Use Secure Connections" since 2022. Google's announcement lays out a two-step rollout: in April 2026, Chrome 147 enabled it by default for users who had opted in to Enhanced Safe Browsing (Google puts that group at around a billion people). In October 2026, Chrome 154 enables it for all users by default.

The behaviour is deliberately narrow:

• It applies only to public sites — normal domains such as example.com or yourbusiness.mc. Local addresses, intranets and single-label hostnames are excluded, because certificates for those are hard to obtain.
• The warning is bypassable: the visitor can click through. But it is a full interstitial, not a small icon.
• Chrome will not nag about sites the user visits regularly. Google's own testing found the median user sees fewer than one warning a week.
• Users can turn the setting off, but the overwhelming majority never change browser defaults.

Google's figures show HTTPS already accounts for 95–99% of page loads depending on the platform, which is why it feels safe enough to flip the default. The remaining few percent is where the trouble lives.

Why the last few percent matters in Monaco

A Monaco business website is rarely a high-traffic site. It is a low-traffic, high-value site: a handful of visits a day, several of which are a prospective client, a landlord, a family office or a journalist checking whether you are real. A security warning at that exact moment is disproportionately expensive. Nobody clicks "continue anyway" on a wealth manager, a clinic or a yacht broker. They close the tab.

The businesses most exposed are the ones you would expect: a boutique whose site was built in 2017 and has run untouched since; a restaurant whose booking page sits on a subdomain nobody maintains; a professional practice with a "temporary" page that became permanent. These are not careless companies. They are companies for whom the website was a one-off project rather than an ongoing system, which is precisely the gap that website maintenance is meant to close.

The cases people miss

The main site is usually fine. Where we consistently find plain HTTP is around it:

Old links in the wild. Printed brochures, business cards, email signatures, Google Business Profile entries and social bios written years ago often still say http://. If your server redirects HTTP to HTTPS correctly, Chrome handles the upgrade silently. If the redirect is missing or broken on one subdomain, that old link becomes a warning.

QR codes. Every restaurant menu, hotel welcome card and event poster in the Principality now carries a QR code, and many were generated once and never checked. A QR code encoding an HTTP address to a page without a valid certificate will produce the warning on a guest's phone. For hospitality this is worth a ten-minute audit on its own — it is one of the recurring issues we see in hospitality and restaurant websites.

Secondary domains. Campaign landing pages, the .com you bought alongside the .mc, the old brand name that still forwards traffic. Forwarding domains are often configured at the registrar level with no certificate at all.

Mixed content. A page served over HTTPS that loads a script, image or font over HTTP. Chrome already blocks or upgrades most of this, but a page that depends on an HTTP-only third-party resource can break in ways that look like a design fault rather than a security one.

Expired certificates. Not the same problem, but the same symptom. A site that had HTTPS and let the certificate lapse is worse off than one that never had it, and with certificate lifetimes now shortening on a published schedule, "someone renews it manually" is no longer a safe answer.

A thirty-minute check anyone can run

You do not need a developer for the first pass.

1. Open your website in Chrome. Go to Settings, then Privacy and security, then Security, and enable "Always Use Secure Connections" today. You will now see exactly what your visitors will see in October.
2. Type your address in every form you have ever published: with and without www, with http:// explicitly, and any second domains. Each one should land on an HTTPS page with a padlock and no warning.
3. Scan every QR code you have in print with your phone. Check what address it encodes, not just where it eventually lands.
4. Search your own email signature, Google Business Profile and social media profiles for http://.
5. Write down anything that produced a warning, a redirect chain, or a page that looks broken.

If that list is empty, you are done. If it is not, the fixes are usually small: a redirect rule, a certificate on a forgotten subdomain, a corrected link. What you want to avoid is discovering the list from a client's screenshot in November.

If the site itself is the problem

Occasionally the audit reveals something larger — a site on hosting that cannot issue certificates, a platform that is no longer supported, or a build so old that patching it costs more than it is worth. In that case the honest advice is not to bolt HTTPS onto something that will fail the next test too. A properly built site gets HTTPS, automatic certificate renewal, redirects and security headers as standard, not as extras; it is simply how we approach any web development project.

For Monaco-registered businesses, a rebuild of that kind may be eligible for support through the Government's digital programmes — we have written separately about Fonds Bleu subsidised website projects. Eligibility and conditions change, so verify the current rules with the Digital Economy team before planning around them.

Timing

October is also when the Assises de la Cybersécurité fills the Grimaldi Forum, which is a fair reminder that in Monaco security posture is increasingly something clients, partners and insurers ask about. A browser warning on your homepage is the most visible possible way to fail that question, and one of the cheapest to fix.

You have a few weeks. If you would like us to run the check for you and tell you plainly whether anything will break, get in touch.