What do you do when a city’s walk signal stops obeying the rules of the road — not because of a traffic jam, but because someone logged in with a password the manufacturer never bothered to change? That was the unsettling choice facing Palo Alto last year when several municipal crosswalk signals were manipulated after the devices were left on their factory default credentials.
The incident was not a Hollywood-style cyberattack; it was, by experts’ measure, a basic operational failure: devices shipped and deployed with default or embedded passwords that were never changed. Those credentials — identical across many units — turn a single mistake into a multiply exploitable weak point. Security analysts warn that when product credentials are uniform and unrotated, a single compromise can give attackers administrative control over entire fleets of devices, from wireless access points to city infrastructure controllers .
Background: in recent years, municipalities have accelerated deployment of connected devices for traffic management, parking, public Wi‑Fi and other civic services. These “Internet of Things” devices promised efficiency and real‑time control, but many arrive with convenience features that cut corners on security. Default passwords are a common shortcut during development and testing; if they remain in production firmware, the result is systemic risk rather than an isolated vulnerability .
In Palo Alto’s case, city managers discovered that a third party had altered the behavior of crosswalk signals. The cause was not an unknown zero‑day or a nation‑state exploit but the persistence of built‑in credentials — a problem that allowed relatively low‑effort tampering with public‑safety equipment. The practical harms include confusing pedestrians, undermining trust in infrastructure, and creating potential safety hazards while opening pathways to broader network access if the device sits on a municipal network segment.
Why this matters: hard‑coded or default credentials are cheap for attackers and costly for defenders. They require almost no specialized skill to exploit, can be scaled across many devices, and often leave little logging or trace because device management functions are not monitored the way enterprise servers are. The result is a vulnerability that is trivial to weaponize and hard to eradicate without systematic inventory and remediation .
Perspectives vary:
- Technologists point to predictable engineering failures: lack of automated secret scanning in build pipelines, inadequate threat modeling, and insufficient QA that would have removed test credentials before shipping .
- Policy makers see a regulatory gap. Some argue for baseline security requirements for connected devices — unique per‑device credentials, mandatory update mechanisms, and vendor disclosure rules — to prevent manufacturers from shipping products with such fundamental flaws .
- City officials and users face practical constraints: budgets, legacy equipment that cannot be patched, and operational burdens of discovering and replacing vulnerable devices across utility poles and intersections.
- Potential adversaries — from pranksters to organized criminal groups — view default passwords as low‑hanging fruit that can be exploited for disruption, extortion, or to establish footholds for more damaging intrusions.
There are immediate, actionable steps cities and organizations can take: conduct a comprehensive inventory of all connected devices; prioritize those exposed to public networks for credential replacement and firmware updates; segment management interfaces behind VLANs and VPNs; enable logging and continuous monitoring of administrative access; and replace unsupported hardware that cannot be secured. Longer term, industry practices need to change: bake security into the product lifecycle, add independent audits and bug bounty programs, and require automated checks that detect embedded credentials before firmware ships .
Manufacturers, too, carry responsibility. The recurring discovery of hard‑coded credentials, even in widely used product lines, suggests that convenience during development remains a stronger impulse than secure defaults. Vendors must adopt secure‑by‑default settings, require unique factory credentials or forced setup, and provide timely, verifiable update channels so operators can patch broadly and rapidly.
The Palo Alto case should serve as a practical lesson: the risk is not merely theoretical. When control of a crosswalk signal can be taken with a factory password, the stakes include not only privacy and data but public safety. The cost of prevention — disciplined engineering, effective procurement requirements and routine operational hygiene — is small compared with the reputational and safety costs of compromise.
As communities lean further into connected infrastructure, one question remains: will policymakers and manufacturers treat default credentials as an acceptable risk, or will this and other incidents finally force durable standards that make such lapses rare and unacceptable? The answer will determine whether our streets remain governed by traffic law — or by whatever password happens to be printed on a device sticker.
Original reporting and context: https://www.schneier.com/blog/archives/2026/01/palo-alto-crosswalk-signals-had-default-passwords.html
