A city library has specialty tablets that cannot store client certificates but can send a username and password inside a TLS tunnel to RADIUS. Which EAP method fits that constraint?
Select an answer to reveal the explanation.
Short Explanation
No room for a client cert on the tablet? EAP-TTLS still builds a TLS tunnel to the server, then slips the username/password inside. You’re not stuck demanding EAP-TLS certs—or falling back to open or WEP.
Full Explanation
Specialty library tablets that cannot store client certificates but can send a username and password inside a TLS tunnel to RADIUS fit EAP-TTLS, which establishes server-side TLS and then tunnels inner credentials without requiring client certificates. Mandating EAP-TLS only would block devices that lack a certificate store. Open System authentication with no EAP and no encryption abandons confidentiality and enterprise identity. Static WEP with rotating shared keys reintroduces deprecated crypto. Exam caveat: TTLS versus TLS versus PEAP is about credential form factor—no client cert capability with tunneled passwords commonly maps to TTLS (or PEAP); mutual certs map to TLS. Operational check: configure EAP-TTLS against library RADIUS, test a tablet login with username/password, verify the outer TLS server identity is validated, and ensure tablets still cannot reach staff VLANs beyond policy. Document why TTLS was chosen over TLS for this civic device class so future refreshes revisit certificate capability. In municipal WLAN operations, record the rationale in the change ticket so future on-call staff know which control was chosen and which failure modes the rejected options would create for city services. Re-validate after the next maintenance window that the same control still holds under the infrastructure versions and client fleets used by the civic environment.