Routers are teaching users to ignore the warnings meant to protect them

Manufacturers still make customers click through certificate alerts on local admin pages, despite safer ways to give every router a trusted identity.

Router makers have known for years how to avoid the browser warnings that still greet many users when they sign in to local admin pages. Yet a surprising number still rely on self-signed certificates and tell customers to click through the alert, even though the warning is designed to signal possible impersonation. The problem is not abstract: browser fatigue is well understood in security, and a warning that appears every time an owner logs in becomes easier to ignore.

That is why the advice still found on some support pages is hard to defend. FRITZ! tells users they can import a router certificate into their computer to suppress the warning, while ASUS offers workarounds for the “Your connection is not private” message on its web interface. Both approaches acknowledge the flaw without fully removing it. The stronger answer is to make the secure path the default, rather than placing the burden on the customer.

The wider industry has already shown that better models exist. Since 2011, the CA/Browser Forum has been phasing out publicly trusted certificates for internal names and reserved IP addresses, pushing vendors towards cleaner identity practices. Plex took a different route for home media servers by assigning each device its own trusted certificate and hostname, avoiding the shared-key mistake that has caused trouble elsewhere. That matters because a router is the device best placed to answer local DNS requests for itself, making it technically straightforward to present a unique, verifiable name to the browser.

There is also a clear warning from past failures. Netgear’s shared router certificates were revoked after the private key was found in firmware, demonstrating how dangerous it is when many devices rely on the same credentials. More recently, CISA has warned about certificate revocations by DigiCert that can disrupt services when domain verification fails, while the UK’s NCSC has reported router compromise campaigns that alter DNS and DHCP settings to divert traffic. In parallel, CERT/CC has disclosed a Tenda firmware backdoor that could grant admin access without a password. Together, these cases underline why weak trust handling at the router level is more than a cosmetic issue.

FRITZ! is particularly well placed to fix this because it already has part of the machinery in place. Its boxes can obtain Let’s Encrypt certificates for unique MyFRITZ! addresses, and each device also carries an individual self-signed certificate rather than a shared one. The remaining gap is the default local experience: the company could make the router’s own hostname resolve to the LAN address, serve a redirect from the bare IP or short local name, and present the secure interface without asking users to normalise a warning. For first-time setup, a factory-issued self-signed certificate with a printed fingerprint would still be workable. The broader point is simple: the home router should not be the place where users learn to ignore the browser’s security model.