An IoT badge reader used at county building doors has a published CVE in its Wi-Fi module. How should WLAN vulnerability scope treat that finding?
Select an answer to reveal the explanation.
Short Explanation
WLAN risk is not 'APs only.' That door badge reader's Wi-Fi chip can be a soft underbelly on the same air the county trusts—clients and specialty gear stay in the CVE hunt.
Full Explanation
An IoT badge reader at county building doors with a published CVE in its Wi-Fi module must be included when assessing WLAN-related vulnerability exposure. Wireless clients and specialty devices extend the attack surface of the WLAN security domain; a compromised Wi-Fi module on a door reader can threaten both wireless credentials and physical access pathways. Excluding it because only access-point CVEs matter artificially narrows scope and misses client-side risk. Marking it resolved automatically because badge readers supposedly never authenticate to enterprise SSIDs is an unverified assumption—many readers do join facility SSIDs. Converting the finding into a cable-plant work order and ignoring the wireless CVE fails to address the reported wireless flaw. Civic physical-security devices on Wi-Fi deserve explicit tracking in the WLAN vulnerability program alongside APs and controllers. Exam caveat: WLAN vulnerability scope includes infrastructure and wireless clients that participate in or extend the wireless environment. Operational check: add badge readers and similar IoT Wi-Fi clients to the vulnerability asset inventory, map the CVE to installed module firmware, apply vendor fixes or network compensating controls (segmentation, monitoring), and verify door systems remain on the intended facility SSID only.