Your membership director sends the renewal letter every September, the same one she has sent for six years with the dates updated. It goes out on paper to about four hundred members who never renew online. Somewhere in the third paragraph is a URL that was typed in 2019, and it begins with http rather than https. This year, a good number of the people who type it in are going to get a full-page security warning instead of your dues page.
Chrome is turning on HTTPS-by-default for all users. The change has been rolling out in stages for most of a year, and the last stage, the one that reaches everybody, arrives with Chrome 154 in the second half of September, with the setting change rolling out through October.
Sourcing, briefly. Google announced the plan on its security blog in October 2025 and has shipped it in two phases. Chrome 147 enabled it for Enhanced Safe Browsing users in April 2026. Chrome 154 extends it to everyone. Google's post says October; Chrome's release schedule puts 154 at stable in late September. Either way it lands inside this quarter.
What the Change Actually Does
Chrome enables a setting called Always Use Secure Connections by default. When someone navigates to a public site over plain HTTP, Chrome shows a warning interstitial before loading it, the full-page red screen most people associate with a broken certificate.
The scope is narrower than the headline suggests. Three limits are worth knowing. Private and local network addresses are excluded, so an internal tool on an office network is unaffected. Chrome will not repeatedly warn about an HTTP site somebody visits regularly. And users can still switch the setting off, though almost nobody will.
This is not about your main website. If your association's primary domain has had a certificate for years, and it almost certainly has, nothing about the home page changes. The exposure is entirely in the long tail, and the long tail at an association is longer than most organizations realize.
Where the Problem Actually Lives
The things that break here are the things nobody has looked at in years, which is exactly why they break. Five categories cover almost every case we see.
- Old conference microsites. annualmeeting2019.yourassociation.org, built by a different vendor, still resolving, still linked from a dozen places, certificate long expired or never installed.
- Chapter and affiliate sites. Set up by volunteers on domains the national office does not control and cannot easily audit.
- Hardcoded http:// URLs in print and email. Renewal letters, membership brochures, conference programs, the footer of an email template nobody has edited since it was built. These are the ones that hurt, because the person following them is trying to give you money.
- Vanity and redirect domains. The short URL from a campaign three years ago, pointed at your site through a registrar that never had a certificate attached.
- Subdomains pointed at vendors. learn., careers., community., events. Each one delegated to a third party whose HTTPS configuration is their decision, not yours.
Why This Matters More for an Association Than a Business
Your audience arrives from paper more than most. Associations and nonprofits still run print renewal notices, conference mailers, annual reports and event programs. Every printed URL is frozen at the moment it went to press, and cannot be corrected the way a web link can.
Your archive is unusually deep. A ten-year-old company rebuilds its website and abandons the old one. A ten-year-old association keeps the 2016 conference program online because a member might need it, keeps the old chapter sites because the chapters asked, and keeps the microsite because somebody once said the URL out loud at a board meeting.
And the warning lands at the worst moment. Someone following a printed link is usually mid-task, renewing, registering, donating, submitting an application. A browser security warning at that moment does not read as a technical detail. It reads as evidence that something is wrong with your organization.
What to Do About It
This is a finite piece of work, and most of it can be done by whoever holds your DNS.
- List every domain and subdomain your organization owns. Not the ones you use, the ones you own. Registrar accounts and DNS zone files are the source of truth here, not memory.
- Load each one over plain HTTP and see what happens. You want an automatic redirect to the https version. Anything that loads over HTTP without redirecting, or throws a certificate error, goes on the list.
- Fix the redirect at the server, not in the page. A site-wide HTTP-to-HTTPS redirect plus HSTS handles the whole domain permanently, including URLs nobody remembers.
- Grep your email templates and print files for http:// , then fix the templates so next year's letter is correct even if nobody remembers this conversation.
- Decide what to retire. Some of those microsites do not need a certificate. They need to be archived and redirected to a page that still exists.
Not Every Association Has This Problem
If your organization owns exactly one domain, has never run a microsite, and has no printed materials in circulation, you can reasonably check the one redirect and move on. Not every association has a sprawl problem, and inventing one to justify a project would be dishonest.
It is also worth saying that this change is good. The warning exists because plain HTTP is unsafe on a public network, and a browser telling a member so is the browser working correctly. The goal is not to suppress the warning. It is to not deserve it.
The Related Problem You Will Find While Looking
Almost every organization that runs this audit finds at least one certificate nobody is managing. That matters more next year than it did last year, because the renewal window is shrinking.
Certificate lifetimes are stepping down on a published schedule. The CA/Browser Forum cut the maximum to 200 days in March 2026 and cuts it to 100 days in March 2027. Let's Encrypt, which issues the certificates behind a large share of association and nonprofit sites, is moving faster still, down to 64 days on February 10, 2027, with the authorization reuse window dropping to ten days.
One correction worth making, because the number gets repeated wrongly. You will see "certificates are dropping to 47 days" in a lot of coverage. That is 2029, not next year. And certificate authorities issue one day short of the maximum to avoid overrunning it, so the practical figures are 199 and 99 days rather than 200 and 100.
The consequence is operational, not technical. At 64-day certificates you are renewing roughly six times a year instead of once. Any certificate that a person installs by hand, bought from a reseller, pasted into a control panel, renewed when somebody remembers, stops being viable. Anything still manual should move to automated renewal during this audit, while you already have the list open.
What About Mixed Content
A reasonable question, and the answer is that this one is already handled. Browsers have blocked or automatically upgraded insecure resources loaded inside a secure page for several years now. If your page loads over HTTPS but pulls an image over HTTP, Chrome deals with it silently. That is not what changes this autumn.
The change is about the page itself being requested over plain HTTP, the top-level navigation, the thing a member types or clicks from a printed letter. It is a narrower problem than mixed content ever was, and a much easier one to fix completely.
Find Out What Your Members Will See
Give us your main domain and we will find the rest ourselves. We will tell you every hostname you own that still answers over plain HTTP, every one with a certificate about to expire, and every http:// link we can find in your own pages pointing at your own content. Every hostname comes back with a fix beside it, ordered by how likely a member is to hit it, starting with anything that appears on a renewal notice.