Why does an unreachable 802.1X authentication server lock every device out of an unstaffed site, and who benefits if you configure it not to?
answer
- the decision point is somewhere else
- silence is not an accept
- unauthorized until told otherwise
- who benefits when it opens
basics
~20 sA switch opens a port only when the authentication server returns an accept. Silence is not an accept, so an unreachable server denies everyone. Admitting on silence instead gives a port to anyone who can cause silence.
solid answer
~50 sIn 802.1X the switch is only the authenticator: it holds the port unauthorized, passes EAPOL frames to a RADIUS server across the network, and opens the port when — and only when — that server returns an accept. The decision point is somewhere else, so if the WAN circuit to it drops, an unstaffed site has no way to authorise anything, and the laptop, the patch server and the jump host you would use to fix it are all behind the same closed door. The alternative is a deliberate fail-open design, usually a critical VLAN applied when the server is declared dead. That is a defensible choice, but it is also a control an adversary can switch off: anyone who can knock the circuit over, flood the servers, or simply wait for a maintenance window gets an open port. So the posture is chosen before enforcement day, its reach is scoped, and every port that takes it is logged.
go deeper
Be ready to say that the switch holds the port closed until an authentication server says yes, and that no answer means no access. Know that the server is usually somewhere else on the network.
Explain the three roles, what passes on an unauthorized port before a decision, and why a reject and a timeout are different events for the switch even though the device is denied either way.
Show that you have thought about the fix path: the servers, the jump host and the patch source sit behind the same control, and the fallback you configure is a control an adversary can trigger by making the servers unreachable.
Own the framing that a failure posture is an accepted risk, not a technical default — someone must fund the consequence of a dark site or accept the consequence of an open port, and that choice belongs on a change record before enforcement.
## The three roles, and where the decision actually lives 802.1X has three parties. The **supplicant** is the device asking to get on. The **authenticator** is the switch port (or wireless controller) in front of it. The **authentication server** — almost always reached over RADIUS — is the thing that decides. Before a decision arrives, the port is in an unauthorized state: it forwards EAPOL frames used by the authentication exchange itself and drops ordinary traffic. Nothing about that port is open by default. The consequence people miss is architectural, not protocol-level: **the decision point is not in the site.** For a national estate of small unstaffed sites — substations, depots, single-till stores — the RADIUS servers usually live in two central data centres, and the access decision therefore crosses a WAN circuit. When that circuit fails, the site has not lost a security service. It has lost the ability to put anything on the network at all. ## Silence is not a reject, and both deny Operationally these are two very different events with the same outcome for the device: | What happens | What the switch sees | What it can do | |---|---|---| | Server answers with a reject | A decision | Leave the port unauthorized, or apply an auth-fail VLAN if one is configured | | Server never answers | An absence | Wait out its retransmit and timeout settings, then mark the server dead and apply whatever fallback you configured — or nothing | A reject is debuggable: something evaluated your device and said no, and there is a record of it on the server. Silence gives you nothing to read, and the site stays dark for the length of the timers before any fallback engages. Both look identical from the desk of the person at the site, which is why the first question on the bridge is always *did the server answer?* Note that this is not only about certificate-based logons. MAC authentication bypass — the fallback for printers, cameras and door controllers that cannot speak 802.1X — is still a RADIUS request. If the server is unreachable, the bypass is unreachable too. Estates that assume 'the unmanaged devices will be fine' discover otherwise. ## Devices already on stay on, which hides the size of the problem A port that authenticated yesterday normally keeps its authorized session. It is torn down by a re-authentication timer expiring, by the link dropping, or by the device rebooting. So a server outage does not usually black out a site instantly — it bleeds. Everything works until the morning power cycle, the cleaner unplugs a switch, or a re-auth interval lands, and then that device never comes back. This is why an outage at 02:00 can look survivable and be catastrophic at 07:00. ## The two postures and their prices **Fail closed** — no decision, no access. The price is a site with no network and no engineer within a couple of hundred kilometres, for as long as the outage lasts. Nobody can remote in to fix it, because remoting in requires the network. **Fail open** — the port is admitted to a critical VLAN when the server is declared unreachable. The price is that the strongest admission control you own now has an off switch, and the switch is *reachability*. An adversary who has physical access to a wall port at an unstaffed site does not need to defeat 802.1X; they need the servers to be unreachable for a few minutes, and there are many ways to arrange that — cut fibre, saturate the circuit, or wait for the change window you published. Fail open is not wrong, but it must be treated as a deliberately accepted risk with a bounded blast radius: a VLAN that reaches remediation and nothing else, an alarm on every port that lands in it, and a list you audit afterwards. ## What a good answer sounds like Say plainly that the port defaults to denied because authorisation requires an affirmative decision; that an unreachable server therefore denies the same devices you need to fix it; that the fallback is a design decision made in advance rather than a property of the protocol; and that whoever wants the fallback to trigger can usually arrange it. The interviewer is checking that you do not think 802.1X quietly lets people on when it breaks, and that you know the cost of the alternative.
- Do devices that already authenticated drop the moment the server becomes unreachable?Usually not. An authorized session survives until a re-authentication timer expires, the link drops, or the device reboots. So the outage bleeds rather than blacks out, and the real damage often lands at the next power cycle or shift change. When you size the impact, count the devices that will re-authenticate during the outage window, not the ones running now.
- Does MAC authentication bypass keep unmanaged devices online when RADIUS is unreachable?No. Bypass still asks the same server — it just sends the MAC address as the identity instead of running an EAP exchange. If the server cannot be reached, printers, cameras and controllers are denied exactly like laptops. Teams that assume the bypass is a local decision are surprised on the first outage.
- If the site is dark, how do you even reach the switch to change anything?Only through a path that does not depend on the control: a console server, a cellular out-of-band link, or somebody physically present. That path must be built before enforcement day, because the management network, the jump host and the patch server usually sit behind the same authenticated ports you just closed.
saying these in an interview costs you the question
- Claims 802.1X ports fail open by default
- Treats no answer and a reject as the same event
- Assumes authenticated devices drop instantly when the server dies
- Says fail-open is safe because the window is short
- Thinks MAC authentication bypass works without the server