> Because you need certificates, your Smart Home devices won’t support WPA3 Enterprise. Home printers won’t support it. A lot of things won't support it. In fact, it’s a miracle that some consumer-grade routers and access points support it at all.
It's not really a miracle. It's just much easier to do from the access point side because the whole authentication process is basically offloaded to the radius server. It doesn't add a lot of complexity to the actual access point or router. The radius server itself is usually not included with these solutions, they're just capable of talking to one. It's just an easy to achieve bullet point for a feature list.
On client devices however it's a huge pita building a mechanism to manage client certificates, the verification chain and related requirements. It also has to be able to verify the radius server's identity so it needs a full list of fully up to date root CAs (including private PKIs and a way to add them too) and be able to check their revocation. And you need accurate time while not actually having internet access yet. And then there's automatic issuing. Most businesses don't just hand you a certificate, it's issued on the fly by a company HSM after the client device first generates its private key and then installed automatically by MDM after it determines your device is trusted enough. Like obeying security settings like encryption, having the required Antimalware installed and updated etc. It's also automatically revoked if that is no longer the case.
If you just hand it to a user and let them use it wherever they want it's not a lot better than a password really. So nobody actually does this in the real world. So the endpoint needs to be able to talk to various MDMs which is certainly feasible on a phone or computer but not on a simple printer, IP cam or smart device.
> On client devices however it's a huge pita building a mechanism to manage client certificates...
Yep.
This is why "replacing" PSK-protected WiFi with EAP-PEAP, and open WiFi with EAP-TLS was absolutely THE way for the WiFi people to go. (With EAP-PEAP you have the option of setting (and revoking) per-device credentials. With EAP-TLS, you get an open-to-anyone network with data encrypted over the air.)
Despite what the nerds at Google would have you believe, using either EAP mechanism without verifying the cert of the RADIUS server is totally, completely supported by the spec. It's nuts that Google didn't (and maybe still doesn't?) let you operate in the "don't bother verifying the RADIUS server cert" mode, because in the EAP-PEAP mode it's no worse than standard PSK, and in the EAP-TLS mode it's strictly better than Open WiFi.
It's not really a miracle. It's just much easier to do from the access point side because the whole authentication process is basically offloaded to the radius server. It doesn't add a lot of complexity to the actual access point or router. The radius server itself is usually not included with these solutions, they're just capable of talking to one. It's just an easy to achieve bullet point for a feature list.
On client devices however it's a huge pita building a mechanism to manage client certificates, the verification chain and related requirements. It also has to be able to verify the radius server's identity so it needs a full list of fully up to date root CAs (including private PKIs and a way to add them too) and be able to check their revocation. And you need accurate time while not actually having internet access yet. And then there's automatic issuing. Most businesses don't just hand you a certificate, it's issued on the fly by a company HSM after the client device first generates its private key and then installed automatically by MDM after it determines your device is trusted enough. Like obeying security settings like encryption, having the required Antimalware installed and updated etc. It's also automatically revoked if that is no longer the case.
If you just hand it to a user and let them use it wherever they want it's not a lot better than a password really. So nobody actually does this in the real world. So the endpoint needs to be able to talk to various MDMs which is certainly feasible on a phone or computer but not on a simple printer, IP cam or smart device.