> If their track record is quality (i.e. no bugs) They're a (consumer) router manufacturer. I don't care how good they are within that field, no, their track r

> If their track record is quality (i.e. no bugs) They're a (consumer) router manufacturer. I don't care how good they are within that field, no, their track record is NOT quality. Worse yet, 90% of their code comes from the same vendors as every other router manufacturer. > you can extrapolate that their process is pretty good at dealing with security problems as well. That is a complete non sequitur; plenty of businesses have made useable, functional (widely-used!) software but had a head-in-the-sand approach to security. > Of course, nothing is unhackable. Exactly, which is why only things which must be exposed to the public should be exposed to the public. The rest of your argument is assuming the attack surface is the same whether remote management is on or off; or that the amount of attack surface doesn't matter. Either way is simply not correct. By the way, an issue in the "transceiver" would require physical proximity. I'm not sure what the "WAN layer" is, but if you mean like... the Ethernet port and interface, that would require physical access. If the remote management was off, you would likely be targeting nothing more than the units IP/TCP, UDP, whatever stack. With the remote management ON, you could target that, you could target the HTTP server, or you could target the admin panel running on it. Each of those are much more likely to have security holes for several reasons, but moreover there's simply no reason for them to be accessible publicly, while the routing and NAT functions are necessary to the purpose of the device.