When Mozilla and Chrome removed DigiCert G1 from their browser trust stores on April 15, 2026, the internet lit up with guides about which TLS certificates to renew and how to avoid warning pages on your web properties. That content is useful for web teams and DevOps engineers.
There is one important distinction that almost none of the coverage explained: browsers and operating systems each have their own trust stores, and they are not the same thing. RADIUS authentication, the protocol behind every WPA2-Enterprise and WPA3-Enterprise Wi-Fi network, does not go through the browser. It goes through the OS network stack. So, when Chrome dropped G1 on April 15, your Wi-Fi kept working. The OS still trusted G1.
The part nobody is writing about is what happens when the OS stops trusting G1. That is the actual risk for Wi-Fi administrators. And unlike the April 15 browser change, it can happen at any time, on any OS, with no prior notice.
How Enterprise Wi-Fi Validates the RADIUS Server
To understand the risk, it helps to see what happens when a managed laptop or phone connects to your corporate Service Set Identifier (SSID).
WPA2-Enterprise and WPA3-Enterprise use the 802.1X protocol, which requires mutual authentication. The device proves its identity to the network. The network also proves its identity to the device. That second part, the network authenticating itself to the device, is how your devices know they are talking to your real RADIUS server and not a rogue access point set up by an attacker trying to intercept credentials.
The device verifies the RADIUS server’s identity by examining the server’s certificate and confirming that it was signed by a Certificate Authority the device trusts. Where does the device keep that list of trusted CAs? In the operating system’s root certificate trust store. Not the browser’s. The OS’s.
SecureW2 CloudRADIUS has historically presented a certificate signed by DigiCert Global Root CA G1. SecureW2 has already moved the server to DigiCert Global Root G3. But the devices on your network still have network profiles that say ‘I trust G1.’ Until those profiles are updated to also trust G3, devices will not recognize the server’s new certificate when G1 is removed.
Browser Trust Stores vs. OS Trust Stores
Your browser and your operating system each maintain their own separate list of trusted Certificate Authorities — and they don’t always make the same decisions.
The Browser Trust Store
Every major browser, including Chrome, Firefox, Safari, and Edge, maintains its own list of root Certificate Authorities it considers trustworthy. This list is separate from the operating system’s list. Browsers can add or remove CAs from this list independently, and they have increasingly been doing so to enforce stricter security standards.
On April 15, 2026, Mozilla and Google Chrome removed DigiCert G1 from their browser trust stores. When you visit a website whose certificate chains to G1 in those browsers, you now get a security warning. This affects HTTPS connections on websites and web applications.
RADIUS authentication is not an HTTPS connection. It never goes near the browser. So, the April 15 change did not affect your Wi-Fi. Your devices kept authenticating to CloudRADIUS without disruption because the OS trust store, which RADIUS checks, had not changed.
The OS Trust Store
Microsoft, Apple, and Google each maintain their own root trust programs for their operating systems. Windows has the Microsoft Trusted Root Certificate Program; macOS and iOS have the Apple Root Certificate Program; Android has its own root store managed by Google. These programs determine which CAs are trusted at the OS level. They operate independently of browser trust decisions.
Historically, OS vendors have been slower to remove root CAs than browser vendors. But they do remove them, especially when a CA is associated with a security incident. DigiCert experienced a significant breach in recent years that raised questions about the integrity of older certificate chains, including G1. When a CA is linked to a breach, OS vendors have both the motive and the precedent to remove it from the OS trust store before the CA’s nominal expiration date.
When an OS vendor removes G1 from the OS trust store, the effect on RADIUS authentication is immediate and total. Every device running that OS, with a network profile that only trusts G1, attempts to connect to your RADIUS server, fails to validate the server certificate, and drops the connection. The device reports a generic Wi-Fi error to the user. The RADIUS logs show an authentication failure. No error message explains that a root CA was removed. The help desk starts receiving calls.
The Shift to Shorter CA Lifecycles
The DigiCert G1 retirement is part of a broader shift in how the industry thinks about Certificate Authority trust. It is worth understanding because this will not be the last CA migration you do.
Every CA, even a well-known public one, holds a private key. That private key is what makes the CA trustworthy. If it were ever compromised, an attacker could sign fake certificates and impersonate any server that relies on that CA. For a long time, keeping a CA private key secure for 20 or 30 years seemed achievable. Two things have changed that assumption.
First, quantum computing is advancing toward the point where current encryption algorithms protecting those private keys could eventually be broken. The industry is not waiting to find out when that becomes practical. The response is shorter CA lifecycles, so that any given CA is in active use for only a few years rather than decades. G3 is part of this direction.
Second, the DigiCert breach accelerated the timeline for G1 specifically. When a CA is associated with a compromise, the gap between ‘technically valid until 2031’ and ‘effectively retired now’ collapses very quickly.
The practical implication for IT administrators is that CA migrations will recur on shorter and shorter cycles. The organizations that treat this migration as a one-time inconvenience will face the same scramble again in a few years. The organizations that build a clean, repeatable process for pushing updated network profiles will find each future migration progressively easier.
Why RADIUS Uses a Public CA Like DigiCert
A reasonable question at this point is: why does CloudRADIUS use a public CA at all? If SecureW2 used a private CA that it controlled directly, the G1 lifecycle decision would not matter.
The answer is that CloudRADIUS is a shared service. The same RADIUS server infrastructure handles authentication for many different organizations. The server certificate it presents needs to be trusted out of the box by every device across all of those organizations, running every major OS, and managed by dozens of different IT teams.
A private CA only works if every device already has that CA’s certificate installed. For a single organization managing a closed device fleet, that is manageable.
For a cloud RADIUS service used by organizations ranging from universities to hospitals to technology companies, requiring every device to have a custom private CA installed before it can connect is not practical. A well-known public CA like DigiCert G3 ships pre-trusted on every major device OS. The only setup required is the network profile update this migration involves, not a custom CA deployment across millions of diverse devices.
The Two Deadlines (And the One Nobody Is Talking About)
| Date | What Happens | Risk |
| April 15, 2026 | Mozilla and Chrome remove G1 from browser trust stores. Wi-Fi is not yet broken, but OS vendors are watching. | High |
| Any day between now and Oct 1 | Windows, macOS, or Android removes G1 from the OS trust store. No notice required. RADIUS authentication breaks for every device on that OS with a G1-only profile — overnight. | Unpredictable / Critical |
| October 1, 2026 | SecureW2 hard cutover. CloudRADIUS stops presenting G1-signed certificates. Every device still on a G1-only profile fails RADIUS authentication. No exceptions. | Certain outage |
Most communications about this migration focus on October 1 as the SecureW2 hard cutover deadline. That date is real and absolute. But the more dangerous deadline is the one with no fixed date: the day an OS vendor decides to remove G1 from its trust store.
Microsoft already migrated its own Entra identity services from DigiCert G1 to G2 in January 2026, a move that affected authentication across Microsoft 365 and Azure environments. That migration required admin action to avoid authentication failures, and organizations that were not prepared had outages. OS-level trust removal is the next step in the same direction.
The window to act safely is open right now. Every device on your network can receive a profile update today through Mobile Device Management (MDM). That window may close without notice.
Which MDM Platforms Are Affected?
The migration affects every MDM platform used to manage Wi-Fi profiles. The specific steps differ by platform, but the outcome is the same in each case: you add DigiCert Global Root G3 as a trusted RADIUS CA to your existing Wi-Fi or network profile, alongside G1. You are not removing G1 yet. Both need to be trusted simultaneously during the transition period.
BYOD Devices: A Different Process
BYOD devices are not enrolled in MDM, so the profile cannot be pushed silently. The process has two phases.
First, the admin updates the JoinNow network profile in the Management Portal to include G3 trust and republishes it. Then, BYOD users re-run the JoinNow enrollment tool on their device, which automatically delivers the updated trust profile. Users who do not re-enroll before October 1 will lose Wi-Fi access at cutover.
If your JoinNow BYOD onboarding profile was last published after November 2024, G3 trust is very likely already included. Check the Certificates section of the network profile in the JoinNow Management Portal to confirm.
What Happens to Devices That Are Not Updated?
On the day G1 stops being trusted, whether that is due to an OS vendor decision or the October 1 SecureW2 cutover, every device with a G1-only network profile will try to authenticate to CloudRADIUS, fail to validate the server certificate, and be unable to connect to the corporate SSID.
Your first move will be to push a corrected profile via MDM. Here is the problem: if your MDM management traffic runs over the same corporate Wi-Fi network that just stopped working, you cannot reach the devices. You cannot push a fix to a device that cannot receive it. Wired fallback works if your environment supports it across all device types, but most modern offices do not have Ethernet at every desk, and most mobile devices lack wired ports.
For BYOD devices, there is no silent push option. The user must either visit the help desk or use cellular data to re-run JoinNow. At scale, that means hundreds or thousands of coordinated user actions after an outage, which is a categorically different problem from coordinating those same actions before a deadline.
Every device with an unmigrated profile fails at the same moment. This is not a gradual problem where some users are inconvenienced. It is a simultaneous outage across all unmigrated endpoints.
Act Now, While Your Devices Are Still Reachable
The migration itself is not complex. It is a profile update that end users never notice. The complexity comes entirely from trying to do it after the deadline, when the channel you need to push the fix has gone down.
Here is the sequence:
- Download the DigiCert Global Root G3 certificate from the JoinNow Management Portal under RADIUS > RADIUS Configuration > Server Root CA > Download.
- Push the updated Wi-Fi profile via MDM for all managed devices. Add G3 as a trusted RADIUS CA alongside G1. Do not remove G1 yet.
- Update and republish your JoinNow BYOD network profile, then communicate the re-enrollment deadline to BYOD users well ahead of October 1.
- Track re-enrollment progress in Data and Monitoring > General Events. Filter for ‘Certificate Issued’ events.
- Email SecureW2 support at support@securew2.com when migration is complete on your side. Support will complete the server-side cutover for your account.
The full step-by-step configuration guide for every MDM platform is at try.securew2.com/2026-radius-ca-migration. If you need help confirming whether your account is affected or want support walking through the migration, reach out to support@securew2.com
