Considerations for 802.1x Port Based and Wi-Fi Certificate Authentication

Question

Lately, we have been going back and for with the thought of doing certificate authentication for Wi-Fi and Port. We have Server 2012 PKI and CA and it seems fairly straight forward to pump out a certificate to a user and have them authenticate with their
certificate to a RADIUS/NPS. However, every time I mention our thoughts with consultants or others they seem to cringe saying that they've seen this deployment cripple networks.
We have almost 50 branch retail locations (with hub-spoke topology - all have VPN tunnels to corporate and also a disaster recovery location) and their internet isn't always super stable and they absolutely need to have network access at all times because
they are running Point Of Sale. Right now, if their internet fails, they can remain functional because we have the necessary pieces at all locations to keep a Windows network going but I'm afraid that if we force 802.1x certificate authentication for the switch
ports and Wi-Fi that if their internet goes down, they won't be able to authenticate since the authentication server will be at corporate. I am curious as to how people deal with:
1. Fail over to a disaster recovery authentication server if Corporate connection goes down
and:
2. If internet fails locally and can no longer communicate with any authentication server. Is there some sort of scale-out? It seems complicated since (if I'm not mistaken) it needs access to the CRL to validate certificates and also a Network Policy Server
for the authentication and so on.
What we're really trying to accomplish is to prevent people from bringing in a laptop or device with an Ethernet port and removing an existing device and plugging into the port in its place. MAC filtering doesn't seem like a good solution on a large scale,
nor a super secure option so it seemed like 802.1x certificate seemed to be the most flexible without having to go full NAP/NAC. Anyhow, sorry for the lengthy post and I really appreciate your time in advance!

Answer 1

Re-authentication could be triggered by the NPS, the switch / AP or the client:
NPS: There is a bunch of attributes to be configured in the Network Policy that determine the time a machine can remain connected such as Idle Timeout and Session Timeout. (When WEP was still common the session timeout had been used to enforce
a change of the insecure key.) Otherwise, the machine should remain connected as far as NPS is concerned.
Switch / AP: Depends on the configuration, e.g. re-authentication has to be triggered if the link went down. If a user plugs a cable or accidentally disable WLAN on his machine when the internet link he will not be able to reconnect.
Then I have seen some options similar to the NPS options, and switches could have their own session timeouts or be configured for respecting the radius server's setting.
Client: The term "re-authentication" is also used happens if you have to / want to use both machine and user authentication: When the machine starts up, the machine account is authenticated; when the user logs on the user is authenticated;
when the user logs off the machine is authenticated again. Per GPO you configure the machines for this kind of re-authentication (the default) or use machine-only or user-only authentication instead.
It might be a challenge to manage and test these settings if you have to support many different APs / switches and different WLAN devices.
I would recommend to carefully test it with a pilot group of users.
Would you have any chance to turn off 802.1x on the switches / APs in case of a major outage? I guess not as you would be able to manage them remotely?