But for all sensitive access I use internal Wireguard now. WiFi auth gets a client onto a restricted VLAN in the first place, but from there only a VPN will get to management webguis, sensitive services, or unrestricted internet access. Regrettably the design process for WPA3 was the same old mediocre industry affair. It's not worth trying to put many bandaids on vs just moving things to a higher level. As a practical matter WiFi also just isn't that fast vs high performance clients, it's not like WG has to handle tens of gigabits, so there isn't even any downside in performance.
WiFi auth at this point kinda feels like a polite lock on the screen door. Not useless at all, but anything really important should have other layers in front that are more secure by design from the ground up.
I’m asking incredulous and probing questions because I used to live life the way you are currently, and it’s frankly unhealthy for the human brain. If “home” feels like such an unsafe place to warrant your current measures, you need to either make serious changes to where home is, or your mental state. Neither is easy but at least one is necessary.
What government are you living under that is routinely compromising WPA3 from mobile vans?
Security measures should be evaluated based on their own merits, not by appealing to friendship or any other relationships. We can lock our front doors and have a healthy relationship with our neighbors! These two things aren't mutually exclusive. Though I will add that trusting government authorities not to routinely abuse their powers is a hard ask given their track record all across the globe, even in democratic countries.
WiFi is ubiquitous and is used to exchange sensitive information 24/7. Its compromise can result in financial, reputational, or even physical risk. Considering that raw signals can be intercepted outside of our homes, devices on the network should at the very least be mutually authenticated and their connections encrypted.
Also, let's not forget about the devices too. Say you trust the people you let into your home. Can you also trust their devices and the software that runs on it? Do you trust your work laptop and its "security" software to respect your privacy? Do you even fully trust your own devices? Do you have faith in current commercial hardware and software to respect boundaries, or even comprehend the concept of user ownership? Because the answer to all these questions increasingly sounds like a "no."
Fortunately, wired networking continues to work reliably, unlike frequently "New and Improved" wireless increments.
Same normal one as everyone else in a connected world? I find this interesting and do the same stuff for both home and work. You make a lot of mistakes and wrong assumptions, but a big one is failing at all to consider cost amortization. You're assuming this is a burden, but that's backwards. I need/want a decent network anyway. I want to use open source for core areas to avoid actual problems I've had (not theoretical) with lock-in going wrong anyway. There is absolutely real work and cost in setting that up, same as a good NAS, virtualization (or home k8s clusters some people do or whatever else), etc. But once you do, the marginal cost of doing more stuff with it is tiny, which of course is some part of the whole value in doing it in the first place. It's absolutely wise to pick where one spends their time and resources with care, and I have zero issues with leaning on COTS and other professional in plenty of areas. Self-hosting is both something I enjoy, something I think is important/valuable, and of professional interest.
>I’m asking incredulous and probing questions because I used to live life the way you are currently, and it’s frankly unhealthy for the human brain. If “home” feels like such an unsafe place to warrant your current measures, you need to either make serious changes to where home is, or your mental state. Neither is easy but at least one is necessary.
This is a lot of projection and confusion on your part I'm afraid. None of this has anything to do with "feeling unsafe" beyond the basic ways perhaps we should given the state of smart home devices, cloud service dependencies etc, and how valuable our digital lives and monitoring of them now are. As far as security you've literally got it backwards though: moving to an open less complex higher layer is simpler, more practical, more reliable, and thus it reduces vs adds mental burden. I don't need to think as much about whether some new aggressive smart home thing is trying to scan my network and what issues it might have (they are, they do, and no I do not get total veto on what comes in vs family desires/needs), about making use of still good but now old and never updated kit, about issues in the network hardware itself (like when some UniFi gear was leaking traffic between VLANs [0]), about new surprises in WPA, ever more automated attacks, and on and on. A minute to setup a tunnel once and a lot of that evaporates for years at a time. It significantly reduces the surface area of stuff that is critical to stay on top of vs "eh, check on updates once in awhile".
None of this comes from the strange state you describe yourself as in, but from curiosity, interest, and reasonable respect for the amount of risk against both my own limitations and positive features that I want to take advantage of in my life. Indeed if I didn't consider my home, office, and other work spaces fundamentally physically safe that would undermine the foundation of self-hosting! But physically safe with great neighbors and so on is separate from the connection to the entire rest of the planet, and the various black box objects we bring into said safe home made by profit seeking multinationals capable of communicating without our approval over said connection to the entire rest of the planet right? I hope you're making progress though!
----
0: https://community.ui.com/questions/BUG-NanoHDor-broadcast-an...
Devices are provisioned by assigning or generating a wireguard keypair in the API.
Next the peers are routed together by policy and by default can't access one another. There's support for bidirectional network groups or one-way firewall rules with NAT.
One area of improvement is multicast support with wireguard, it's doable, just not ready yet.
I've started to play around with having some things go exclusively into a Nebula mesh with OPNsense only running a lighthouse, but it's more work and rougher. And unlike WG to the gateway and leaning on VLANs for some older kit, really putting everything behind a virtual network they don't natively support requires sticking a translator between them and the rest of the network. Fun to play with a little and the potential is cool, but I don't think there are any prebaked options as smooth and cheap as would be ideal for that, and I suspect the ROI there at my level is getting pretty dang low. IPMI access is the main place I think might be worth it since that's just so sensitive yet simultaneously so useful in resolving issues all while having extremely mediocre security on its own.
Whereas WG to the gateway does leave the gateway as a point of failure, but I'm depending on that to a significant degree for now anyway. And it is fast, simple, reliable, easy to manage/reason about, and eliminates layer 2 auth from the picture entirely. Don't have to worry about someone plugging into some open ethernet port either for example and any necessary effort to secure those, not just WiFi. Threats may evolve but hopefully the options we have to combat them evolve in concert to some degree. Lots of other HNers are vastly more experienced in this then me, and I'm not unaware of some of the potential failure points, but it's hard sometimes to figure out how to balance risk vs resources we have to spend on them (not just money but time).
Also there are other good gateway/firewall options like VyOS, or just working directly off your favorite flavor of Linux or OpenBSD or whatever, that might fit your needs/preferences/tooling better than OPNsense. I don't mean to suggest that it is the best choice, it's just what I've settled in on as a good balance of other values.
If you feel strongly about it use a vpn. Wireguard is nice for this indeed. And indeed some IOT has pretty shit network security so you might want to care about securing that in your home or office network. But beyond that, your exposure should be pretty minimal even if you don't use a VPN.
And reality check: most people aren't network security experts. I'm certainly not one even though I've been active as a developer for a few decades and kind of know what I'm doing.
So, IMHO WPA3 is a waste of time. I don't care about it. It might be more secure by some unknowable degree. But since it is unknowable (for me), I can't be bothered to care. I'd on principle treat it as just as insecure as WPA 1 & 2. Or no network security at all. Which is good enough for me to run my SSL connections over them. And even if it is super duper secure, I don't necessarily trust the Chinese manufacturers supplying the router chips and firmware to do the right thing. In my experience, the vast majority of routers run years out of date firmware supplied via a very shady chain of suppliers for chips and software that I definitely don't trust.
So, WPA 3 is a security blanket. A false sense of security. If you have reasons to be paranoid, go for it. It probably helps. Just like tin foil hats, Faraday cages, and all the rest. I don't use those either. But for the rest of us who aren't network security experts with operator supplied routers at home and working in office environments as well as on the go with random third parties maybe taking care about network security a little bit in the networks we connect to, I treat all networks equally: 100% untrusted. I don't care about what acronym soup applies to the network or how shit-hot the graybeard that manages it is. I just blindly assume network security is mediocre at best and connect anyway. For me network security is about being able to use my laptop safely in a completely untrusted network. Because that's where I use it all of the time.
The point is that "NSA grade" likely means "NSA accessible". The major difference between WPA2 and WPA3 is the individual encryption. My guess would be that there is some backdoor during SAE and they could force a complete reconnect by temporarily jamming/disrupting all users on a network.
[1] https://arstechnica.com/information-technology/2013/09/the-n...
[2] https://twitter.com/matthew_d_green/status/14334701097425182...
Of course, the fact the NSA was aware of differential crypto analysis some years before the rest of us is another thing…
For all future connections, the AP can validate every client, and the client can validate that it is connecting to the same AP.
The AP could have an interface to 'revoke' access to any single client if necessary, and single use passwords could be used too.
That would give all the same benefits as WPA Enterprise (after the initial pairing), and all the ease of use of a preshared key.
Also, it means replacing an AP would require reconfiguring all the clients.
You could give each AP its own intermediate CA tracing back to the same root CA to avoid sharing private keys and allow easily revoking certificates signed by a compromised AP.
You would only need coordination for revoking client certificates (but you can't really avoid that regardless of model).
The parent suggestion is perfectly sound. More user-friendly means to mint certs would be grand. The caveat is that, if you can mint a cert from a low security password, what's to keep an attacker from attacking the password directly, rather than the cert? It might not let them snoop traffic, but it'd still let them on with the password.
Some commercial APs support this under different names but it's hard to make it work with RADIUS, which is usually necessary on larger installations.
But without preloaded certificates, the clients don't know that they're not connecting to a rogue access point.
Hotspot 2.0 was going to solve that part, but kind of died last year as the WiFi Alliance let their last KPI partnership die off.
That's interesting, first time I hear this. How would that be represented in the hostapd config file? Would it be WPA enterprise using a radius server, or would it actually use WPA-PSK?
But not you.
Because it would regress security back to inferior bearer authentication.
In contrast, imagine that the thing the guest enters into their laptop is a freshly-generated random code which expires within X minutes and can only be used once.
Or do what I do: run multiple APs. I have my primary one, which is very tightly secured and monitored, and only gives access to my local VPN. I have a guest one, which is only as secure as any average AP and gets you internet access, but no access to my LAN. If I used "smart" gadgets that I couldn't really control and trust, I'd set up a subnet just for them alone.
It's probably much more cost effective to do what you suggest, and that's exactly what I do. Multiple SSIDs (one for the household, another for IOT stuff, another for work and another for guests) and control access via VLANs.
And to donate to OpenWRT, of course!
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.
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.
For the use case cited -- blocking MAC spoofing, EAP-TLS doesn't quite solve it, it mainly only solves authentication. The outer layer is not wrapped with TLS and is instead based on an ephemeral session key. Additional work is needed to stop the spoofing. The RFC states explicitly that channel binding, which would help stop the MAC spoofing, is not implemented https://datatracker.ietf.org/doc/html/rfc5216. What it does prevent is a client from being man-in-the-middled.
What's even wilder is that on some access points, when set to bridge mode, with an upstream Radius Authentication Server, as described, they may be vulnerable to ARP spoofing of the upstream radius server IP. This is something we've reported to vendors and were told "won't fix". Names include Netgear and TP-Link, though we don't suspect all routers from them are affected by this. We have not tested with the unifi access point referenced in the article.
So to restate the attack, cause it's so ridiculous, you should know about it: an anonymous, unauthenticated wireless station associates without a password. Next it would begin the EAPOL negotiation but it instead then proceeds to perform ARP spoofing to claim the IP address of the upstream Radius that is supposed to only be routed over the uplink interfaces. Even without knowing the shared secret, it's possible for the client to pretend to be the radius server to the AP, and authenticate itself onto the network. One thing you want to be very sure of when setting up 802.1X Radius Auth, is that your access point is not going to be misconfigured to allow clients to do this.
The idea would be to rely on the client certificate authentication and not use MAC filtering at all. For example, you could have an EAP-TLS network that's unrestricted and not let Mallory on it. Or you could use RADIUS reply attributes to put Mallory on a restricted vlan.
I'm sure there are simpler ways to deal with the use case in mind, but I think this article just wants to have fun with NSA-grade WiFi.
For many radius clients used by a common consumer AP, it's been possible for the spoofed radius to just say "okay, authenticated" to authorize itself -- and the shared secret is never used. It's worth noting that RADIUS may use MD5 with that shared secret, which is vulnerable to cracking attacks as well but I have not had to go down the rabbithole that far.
It would be interesting to try this against the Unifi AP brand named in the article and see how it handles it. My understanding is they run a custom Openwrt image so maybe they provide source code.
It's actually maybe already possible to consider it a fraud
OSS golang reference code is available, https://news.ycombinator.com/item?id=38402289
VLAN tagging per SSID is a valid approach as well if a router supports it. Thats a lot stronger than how many routers implement their guest isolation.
As for Multi-PSK -- the use case is creating micro-segmentation in a network with zero-trust, where the identity on the network is rooted in that password.
Without Multi-PSK, if it's not clear, every device that has the WiFi password can sniff encrypted traffic with WPA2, make a Rogue AP to attack WPA3 in case its in use, and can perform ARP spoofing on the network to interfere with other devices.Could you name any enterprise APs that do this, short of running your own custom AP software? As far as I know (would love to be corrected on this), Unifi APs can't do this, and they're at the very least "prosumer".
*: In theory password identifiers (https://www.gabriel.urdhr.fr/2022/06/07/impact-of-the-differ...) could be used with WPA3-SAE, but I don't know how good the support is currently...
I'm honestly not sure if the second attack would work or if it would be AP specific, but I imagine most Wifi to wifi traffic through the same AP does not make a round trip through the Ethernet port. This wouldn't be an issue if the AP itself was applying and enforcing VLAN tags, but the MAC spoofing problem would still be an issue.
From https://en.wikipedia.org/wiki/NSA_Suite_B_Cryptography
The Suite B algorithms have been replaced by Commercial National Security Algorithm (CNSA) Suite algorithms:
- Advanced Encryption Standard (AES), per FIPS 197, using 256 bit keys to protect up to TOP SECRET
- Elliptic Curve Diffie-Hellman (ECDH) Key Exchange, per FIPS SP 800-56A, using Curve P-384 to protect up to TOP SECRET.
- Elliptic Curve Digital Signature Algorithm (ECDSA), per FIPS 186-4 Secure Hash Algorithm (SHA), per FIPS 180-4, using SHA-384 to protect up to TOP SECRET.
- Diffie-Hellman (DH) Key Exchange, per RFC 3526, minimum 3072-bit modulus to protect up to TOP SECRET
- RSA for key establishment (NIST SP 800-56B rev 1) and digital signatures (FIPS 186-4), minimum 3072-bit modulus to protect up to TOP SECRET
[0]: https://www.nsa.gov/Resources/Commercial-Solutions-for-Class...
Also, if you care about availability, don’t use a cloud RADIUS server — if the server or your ISP or your route or the relevant part of your network goes down, there goes your WiFi. If you’re using 802.1x, your wired network is toast, too.
And that's how you get spoofing management frames, deauthing, and all sorts of fun attacks.
Cause the moment you talk to unauthenticated and unencrypted machines, well, yeah. Payday.
So you cant do that, even if you really want to.
Plus we’re taking about WPA, which, AFAIK, still uses a horrible hack for EAP even in WPA3, and as you can see mentioned elsewhere in the comments, EAP makes a pretty strong showing in its quest to be the worst widely-used example of giving an unauthenticated party actual access to the network as part of the authentication flow.
Doing this right is not that complicated.
What could possibly go wrong?
How do you do this without trusting some external CA?
FreeRadius can help:
https://wiki.alpinelinux.org/wiki/FreeRadius_EAP-TLS_configu...
As for securing them, there's several labs security researchers provide for breaking into "enterprise wifi"
https://github.com/sensepost/shinai-fi https://github.com/r4ulcl/WiFiChallengeLab-docker
Love Let’s Encrypt — we’re sponsors — but using them for WiFi is a terrible idea. You need internal PKI for WiFi.
In this case you're getting an industrial-grade CA with a properly managed private key, etc. Still, fair. We usually include warnings about this, but looks like we forgot this time. Curse of knowledge. I'll see about getting a warning on there asap.
1) user attempts to connect to “home-wifi”
2) owner of “home-wifi” gets notification to confirm or deny access request
3) owner can optionally verify further
4) if approved, then between AP and client device it will create the client certificates with short expiration dates
5) if denied, then no access granted.
6) if user tries to connect multiple times and gets denied for all of them, then their device is blacklisted. No notification.
No more passwords. Minimal friction to adoption.
I'd be fine with a system where when someone tries to connect to my network, I need to open an app or go to a web page and pick from the list of attempts to allow.
It's not perfect, and it still leaves open a DoS by filling the DB with spam, but at that point you know something is wrong.
APs only have so much range (and I think you can configure it to cover a specific area). So can very easily find out who or what is trying to get in.
Idea was great in theory but in practice routers were often placed in the most inaccessible parts of a house (closet, ceilings, or walls)
Blackhat 2026: WPA free(not three) Enterprise, how to flood and bypass WPA3 with certificate forgery and dual pair attack in 5min!
The great thing with WPA Enterprise is that you can assign VLANs based on the client's login, just like a 802.1X switch. For instance my phone is sent to one VLAN, my company laptop to another, and my personal laptop to another. I can use a single SSID and get all the benefits of a multi-VLAN setup. For guests I provide a username and password for MSCHAPv2 authentication, while family devices are issued full certs.
What about IOT devices? I generally only use commercial wired gear (IP phones, cams, etc.) anyways with no internet access, and I'm of the belief that if it doesn't support WPA-Enterprise it shouldn't be on the network in the first place :). So that rules out all those data-mining smart speakers and so forth.
Friends don't let friends delegate AAA to an external provider like Smallstep or SSO to Okta. While outsourcing to a third party is fine for a limited test, it's not fine for anything enduring.
Once upon a time, when open, spoofable WiFi was the norm, there was a collective WiFi sharing app that took control of retail WiFi routers with WPA1 enterprise RADIUS support called Radiuz. [2]
1. https://github.com/smallstep/certificates
2. https://web.archive.org/web/20040617153148/http://radiuz.net...
Lots of institutions have Eduroam set so that students (and academics, and everybody else like me) are just authenticating against their Windows domain controllers, so going to "192-bit mode" would mean ripping out a bunch of stuff, replacing it, writing fresh documentation, testing thoroughly and then authorising, but since we're talking about the backend every educational establishment in the world would need to do this before you can ship WPA3 192-bit mode. So, that's not going to happen.
This is a dude playing with his home wifi. 192-bit WPA3 Enterprise is not for every use case, nor does the author or anyone else make this claim.
Your comment seems misplaced.
An actual over-engineered home wifi looks like this:
1. Use, at the very least, prosumer grade router access points. I use *sense and Aruba access points, but you don't need to get this serious.
2. Use heavy DNS filters. This will block a lot of malware by itself. Quad9 DNS is a good starting point.
3. Use a secure wifi password.
4. Don't enable upnp, etc.
5. Don't enable ssh or any kind of remote access.
6. Don't open any ports to the outside. This is the default ruleset for pretty much any firewall.
7. If you ever have guests who require wifi, segment these users on a guest wifi or vlan.
8. Reduce your reliance on wifi-powered devices. Favor zigbee smart home devices over wifi devices.
9. (Optional) segment your IoT devices on a vlan.
10. (Optional) use some kind of security package that includes layer 7 monitoring on your LAN.
11. (Optional) use some kind of security package that includes IPS/IDS.
A home router is generally protected on the WAN side.
Your threat model is to secure connections originating from the LAN side, which is the only way a threat actor can establish a connection into a default deny network.
Could a swore we moved to 1.3 a while ago
Also many I'm just not familiar enough with cryptography but that key size seems kinda small.....am I wrong?
Ik RSA uses a different algorithm but RSA it isn't uncommon to see keys 1024 or larger in size. I generated a key of 65,536 and 131,072 bits a few times to see if it would work or break any applications I was using. Also just to I can say "yeah back in my day we generated keys way bigger" cuz I know at least 1 other person in the world did it.
Is their any standard for securing a network both wired and WiFi using a post quantum algorithm?
Also where can I easily find switches that support these standards? AFAIK wpa3 enterprise dosnt always mean this standard is supported....or that some other standard is supported. Is their some database that lists every router/AP and the supported features?
A lot of the IoT stuff doesn't work with WPA3 or 5GHz, so it's useful even for that reason, but the main thing is screening them off from everything else.
I am setting up a NUC as a little home Proxmox server (for some other stuff mainly) but for "fun" I can actually see myself setting up a Samba 4 Active Directory domain controller and hooking FreeRADIUS up to that to do Enterprise for my main SSID, but we'll see!
Shouldn't it be possible to only enable “Always Trust.” in the "X.509 Basic Policy" setting, instead of allowing the certificate to be used for everything(including SSL)?
If you do trust the root cert for everything, couldn't the access point MITM all your traffic?
Not sure about the RADIUS server, but connections to the CA use TLS for SCEP and/or ACME DA so the CA root cert needs to be trusted for TLS. There may be some way to configure more narrow trust for just this one interaction, but I'm not aware of any such mechanism in the current releases of macOS/iOS/iPadOS/tvOS.
I believe this is due to the use of SHA-384, which is described as having 192 bits of "security strength"[0] against collision.
[0]: https://csrc.nist.rip/library/NIST%20SP%20800-107%20Recommen...
But, while not NSA approved, WPA3 itself has support for per-device passwords with WPA-SAE [0] (which isn't called WPA-METRIC outside of the USA...).
[0] https://en.wikipedia.org/wiki/Simultaneous_Authentication_of...
Do not download and install and fully trust root CAs from anyone on your iPhone.
If you want to self-host, see eg:
https://wiki.alpinelinux.org/wiki/FreeRadius_EAP-TLS_configu...
For home wifi this is totally overkill. Better security is always nice but, in this case, there's a significant usability & interop tradeoff for home use (though that may change over time... we'll see).
For business / enterprise settings, this has real value. Distributing a password to everyone doesn't scale and alternative EAP methods have huge security problems. For managed devices, certs can be pushed and EAP-TLS can be configured easily. And it's all seamless for end users[1].
For example, EAP-TLS mitigates "evil twin" attacks, where a rogue access point broadcasts your SSID. If you're using something like EAP-PEAP, which is password based, the user is sending a password to the RADIUS server. If they connect to a rogue AP, they just sent their password to the bad guy. If the password is their LDAP/AD/Okta password, that could be very bad.
There are a variety of mitigations for this sort of attack but, without getting into details, EAP-TLS is widely considered the most secure option. So, yea, if you're relying exclusively on wifi for security you're doing it wrong. But that doesn't mean you don't need to secure your wifi.
I remain disappointed that there's no standard mechanism for mapping between an SSID and a domain name to know which SAN to trust.
The disadvantage of WPA Enterprise though, especially with a hosted RADIUS server, is that it's somewhat more difficult to gain access to the network to fix things if they're broken -- if your internet connection is down then you can't authenticate, and if you can't authenticate then you can't fix whatever broke to bring the connection back up. I suspect you can guess how I discovered that problem :).
So overall: no. There might be a small increase in reliability in regular use (although I've not been able to tell the difference), but the reliance on an extra service makes for less reliable connections overall.
After all, reliability is a cross-cutting concern :)
Here's specifics, using hostap/wpa_supplicant style configuration: key management WPA-EAP-SUITE-B-192. (but then they talk about that); pairwise=GCMP-256, group_mgmt=BIP-GMAC-256; EAP=TTLS;
I mean RADIUS support isn't that hard - freeradius will do. TLS - well, need valid certs that work for EAP. (it's not as specialized as Passpoint/Hotspot-2, which requires custom certs that must be validated by a specific CA, but it still takes some steps). My own experiments across a number of clients showed that GCMP-256 support for pairwise and group management weren't that common before Wifi-6 took off. Suite-B 192 though isn't so hard to reach.
Hostly, I prefer WPA3-Enterprise with Fast Roaming. Sadly, typical household devices didn't work well with it (mixed with android devices, generally no for printers and other IOT), so I went back to two networks - WPA2/Personal with PMF=optional for those annoying devices that don't have working PMF, and WPA3/Personal for most devices - at least for household operations.
>Wi-Fi
No.