A city warehouse adds rugged scanners that only support an older TLS stack. How should that client constraint affect WLAN security requirements?
Select an answer to reveal the explanation.
Short Explanation
Old scanners that speak weak TLS are like trucks that only fit certain bridges—you note the limit, pick EAP/ciphers they can handle without going back to WEP, and plan the upgrade on-ramp.
Full Explanation
When a city warehouse adds rugged scanners that only support an older TLS stack, that client constraint must be written into WLAN security requirements as a limit on allowed EAP methods and cipher suites, followed by compensating controls or a funded upgrade path. Client crypto capability is a required input when defining authentication and encryption policy; pretending every device can run modern EAP-TLS with current cipher suites produces brittle cutovers. Ignoring clients and standardizing solely on marketing SSID names leaves the technical policy unmoored from negotiation reality. Mandating WEP because legacy scanners "prefer" it reintroduces obsolete cryptography that modern municipal policy should reject. Disabling all encryption so scanners can always connect maximizes association success while abandoning confidentiality for warehouse operations data. A disciplined approach documents the gap, may place scanners on a tightly segmented SSID with monitoring, and schedules replacement rather than silently weakening the citywide baseline. Exam caveat: temporary exceptions for legacy clients should be time-bounded, owned, and compensated—not permanent silent weakenings of enterprise policy. Operational check: lab-test scanner EAP and cipher negotiation against the proposed staff profile, document failures, implement a dedicated legacy SSID with stricter segmentation if required, assign an owner and sunset date, and track firmware or hardware refresh until the exception can be removed.