YMMV. It depends on the application and the implementation.
Modern Apple and Microsoft dot1x supplicants do pin on first use, but the only consequence of that is if someone spoofs a cert, the user gets a popup, and how they react to that depends on their training.
Android dot1x supplicants won't, and won't even allow you to pin a particular CA to limit exposure when using a public CA, nor even check the DN, so you are vulnerable to any old stolen key/certificate pair signed by a CA in the base OS trusted list.
If you set it up by hand, wpa-supplicant for Linux has the ability to pin either a particular cert or a CA/DN. Various GUI config tools may or may not support setting these options.
For IPSEC VPN, Windows supplicants cannot pin a CA/DN unless you use EAP-PEAP-MSCHAPv2 either for L2TP/IKEv1 or as the auth protocol in IKEv2, and it must be pinned manually or through a setup/install script. If you use EAP-MSCHAPv2/IKEv2 there is a check that DNS matches the DN, but that's not much extra security if your OS store includes a compromised CA, and Windows also cannot support DH groups higher than modp2048 in a RAS dialer, only in the decidedly user-unfriendly firewall policy feature set. Some 3rd-party VPN clients improve things slightly but often still play it loose with the store/validation. If installed through a mobileconfig, OSX and IOS do support locking things down, I think... that's next on my list of things to kick the tires on. Strongswan on linux pretty much kicks ass, once you've patched it up past the oopsie they had with the EAP state machine, but again, not an end-user-friendly animal so you are at the mercy of GUI tools to not be setting things up wrong.
The whole crypto landscape is a bit of a mess on the client side... the above doesn't really scratch the surface.