Smart streetlight sensors are being added across downtown. Which IoT architecture implication should security emphasize?
Select an answer to reveal the explanation.
Short Explanation
Streetlight brains are not laptops—you often cannot patch them like PCs, and someone can walk up to them. Expect limited updates, nasty defaults, and physical exposure. Do not park them next to finance for 'simpler routing.'
Full Explanation
Smart streetlight and similar IoT deployments commonly suffer limited patchability, long lifetimes, weak or default credentials, and expanded physical attack surface because devices sit outdoors where they can be observed, tampered with, or cloned. Security architecture must therefore emphasize compensating controls: network segmentation away from enterprise and finance networks, unique credentials and certificate-based device identity where supported, encrypted management channels, inventory and monitoring of gateways, and physical tamper considerations. Security+ IoT themes center on these constrained-device realities rather than treating sensors like monthly-patched desktops.
Assuming IoT devices are always easy to patch monthly like standard desktops ignores vendor update gaps and field logistics. Accepting default credentials because lights "only" control lighting underestimates pivot potential—compromised IoT often becomes a foothold into gateways and broader city networks. Placing IoT sensors on the same flat network as finance servers for simpler routing maximizes blast radius from a physically exposed, weakly patched class of devices.
Exam caveat: IoT answers usually stress limited updates, defaults, and physical exposure plus compensating segmentation—not "put them with servers for simplicity." Operationally, isolate lighting controllers on dedicated networks or VRFs, change defaults before deployment, disable unused services, monitor gateway anomalous traffic, and maintain an asset inventory that includes firmware versions even when patch cadence is slow.