Huh. I have worked with Kubernetes so I guess it's possible that's a second place with client certs and I never noticed.

The big employers didn't use EAP-TLS with client certs. The University of course has Eduroam (for WiFi), and I guess in principle you could use client certs with Eduroam but that sounds like extra work with few benefits and I've never seen it from either the implementation side or the user side even though I've worked on or observed numerous Eduroam installs.

I checked install advice for my language (it might differ in other languages) and there's no sign that Eduroam thinks client certificates would be a good idea. Server certs are necessary to make this system work, and there's plenty of guidance on how to best obtain and renew these certificates e.g. does the Web PKI make sense for Eduroam or should you just busk it? But nothing about client certificates that I could see.

I can't comment on Eduroam as I have no experience working in the Edu space, but in general, EAP-TLS is considered to be the gold standard for WiFi/LAN authentication, as alternatives like EAP-TTLS and PEAP-MSCHAPv2 are all flawed in one way or another and rely on username/password auth, which is a weaker form of authentication than relying on asymmetric cryptography (mTLS). Passwords can be shared and phished, if you're not properly enforcing server cert validation, you will be susceptible to evil twin attacks, etc.

Of course, implementing EAP-TLS usually requires a robust way for distributing client certificates to the clients. If all your devices are managed, this is often done using the SCEP protocol. The CA can be either AD CS, your NAC solution, or a cloud PKI solution like SecureW2.

Yeah, I don't think EAP-TLS with client certs would work out well for Eduroam applications. You have a very large number of end users, they're only barely under your authority (students, not staff) and they have a wide variety of devices, also not under your control.

But even in Enterprise corporate settings I did not ever see this though I'm sure some people do it. It sounds like potentially a good idea, of course it can have excellent security properties, however one of the major downside IMHO is that people wind up with the weakest link being a poorly secured SCEP endpoint. Bad guys could never hope to break the encryption needed to forge credentials, but they could trivially tail-gate a call center worker and get real credentials which work fine, so, who cares.

Maybe that's actually enough. Threat models where adversaries are willing to physically travel to your location (or activate a local asset) might be out of your league anyway. But it feels to me as if that's the wrong way to look at it.