A physician's tablet, previously able to authenticate seamlessly to the clinical Wi-Fi network using certificate-based authentication, suddenly begins failing every connection attempt with an authentication error after IT rotates the network's authentication certificates. What is the most likely explanation, at a conceptual level?

Certificate-based authentication (as used in EAP-TLS style exchanges) depends on the client having a trusted certificate, or a trusted issuing authority, installed ahead of time so it can validate whatever certificate the authentication server presents during the handshake. When IT rotates the certificates used by the authentication infrastructure, any client device that hasn't also been updated with the new trusted certificate or root chain will reject the server's new certificate as untrusted and fail the authentication exchange immediately, even though nothing about the client's own credentials or the wireless configuration has changed. This is distinct from a DHCP lease issue, since a rejected authentication never gets far enough to request an IP address at all, and different from an AP losing its uplink, which would cause a broader outage affecting every client on that AP rather than a certificate-specific failure tied precisely to the moment of rotation. A changed RADIUS shared secret between the switch and RADIUS server is a related but different failure mode — that affects the switch-to-RADIUS trust relationship, not the client-to-server certificate trust, and would typically produce a different class of error visible on the switch or RADIUS logs rather than a client-reported authentication rejection. The operational check is to review the client's authentication logs for a certificate-trust or validation error specifically, and confirm whether the new root or intermediate certificate has been pushed to affected devices, commonly through a mobile device management profile.