What happens if Passbeam is down?

Two things protect you here, and the first is that there is no single Passbeam to be down. Authentication is served by two independent endpoints on two separate hosts, at two different providers, in two different locations — radsec-1 and radsec-2. Both are live, both answer on both transports, and neither depends on the other to keep working.

You get both. The site's Connect tab hands you a primary and a secondary, in the order your equipment wants them, and your access points or switches fail over between them on their own — that behaviour is built into 802.1X and has been for decades. If one endpoint goes away, your devices carry on joining through the other, and nobody at the client's site notices.

The second protection is that a device already on the network stays on it. The certificate check happens when a device joins, not continuously, so even in the worst case the people already working carry on working. What would pause is new joins and re-joins — which is why the redundancy is on the authentication path first, rather than anywhere else.

Beyond that, the equipment itself has the final say, and this is worth setting up deliberately rather than discovering. A switch or an access point can be told what to do when it can reach no RADIUS server at all — hold existing sessions open, drop new devices onto a guest VLAN, or use a critical-authentication VLAN. Which of those a site wants is a decision only somebody who knows that network can make, so we tell you it exists at the point you turn a transport on rather than choosing for you.

And we watch it rather than waiting to be told. Both endpoints are probed every five minutes with a real TLS handshake over the same public path a customer's equipment uses, and we are emailed the moment one stops answering — including when the failure is our own mail, which is the case most monitoring quietly misses.