As reported by SecurityAffairs, Slovakia's National Security Authority (NBÚ) has issued a significant cyber threat warning covering three speed camera product lines: NERO R-ONE devices sold by Cyprus-based SODASUS, Cordon-series cameras manufactured by Russia's Simicon, and Cordon-series products distributed by Croatia's NEROline. The findings go well beyond misconfiguration — they point to a fundamental breakdown in supply chain trust.

Key Takeaway: As reported by SecurityAffairs, Slovakia's National Security Authority (NBÚ) has issued a significant cyber threat warning covering three speed camera product lines: NERO R-ONE devices sold by Cyprus-based SODASUS, Cordon-series cameras manufactured by Russia's Simicon, and Cordon-series products distributed by Croatia's NEROline.

What makes this advisory notable is not any single technical flaw but the pattern: undocumented remote-access mechanisms, software versions that don't match documentation, communication interfaces configured differently than stated, and uncertainty about the actual origin of hardware and software components. These are the hallmarks of a supply chain integrity failure, not a patchable bug.

Why This Matters Beyond Slovakia

Road speed cameras are deployed by the thousands across European municipalities and increasingly worldwide. They sit on public-sector networks, process personally identifiable data (license plates, timestamps, vehicle images), and communicate with backend law enforcement and municipal systems. A compromised camera is not just a privacy issue — it is a potential pivot point into government infrastructure.

The core problem is asymmetric information: vendors know exactly what their devices do. Buyers almost never do. When a device ships with pre-configured remote access that the operator cannot inspect or disable, the operator has ceded control of a node on their network to an unknown party.
This is not unique to speed cameras. The same dynamic exists across traffic sensors, building access controllers, environmental monitors, and countless other IoT categories deployed in public infrastructure. The Slovak warning should be read as a case study in a much larger problem.

The Provenance Problem

NBÚ's concern about the "true origin" of hardware and software is particularly significant given the product lines involved. A device marketed by a Cyprus-based company or a Croatian distributor may contain components or firmware developed elsewhere — including jurisdictions with conflicting data protection regimes or strategic interests. For EU member states deploying equipment on government networks, this is not a theoretical concern. It is a national security question that procurement processes are rarely equipped to answer.

Key Risk Vectors Identified

The Provenance Problem
Undocumented remote access: Pre-configured management channels outside operator control create persistent access paths for unknown parties.
Software/firmware provenance gaps: Declared versions don't match what's running, making patch management and vulnerability assessment impossible.
Communication interface drift: Actual network behavior differs from documentation, defeating firewall rules and traffic monitoring assumptions.
Lateral movement potential: Cameras connected to municipal or police networks can serve as initial access points for broader infrastructure compromise.
Evidence integrity risk: If camera data can be manipulated or deleted, the legal validity of speeding enforcement is called into question.

Shield53 Recommendations

Organizations operating connected field devices — whether speed cameras, traffic sensors, or similar IoT infrastructure — should take the following steps:

  • Conduct an immediate asset inventory covering all connected field devices, including vendor, model, firmware version, network connections, and any remote management arrangements. If you cannot answer "who has remote access to this device?" for every asset, that is your first gap.
  • Network segmentation is non-negotiable. Field devices should sit on isolated VLANs with strict egress filtering. No IoT device should have a direct path to law enforcement databases, municipal financial systems, or general government networks. Default-deny firewall rules between IoT segments and critical systems.
  • Perform firmware verification. Extract firmware from a sample device and compare hashes against vendor-published values. Where vendors cannot or will not provide signed firmware images, treat the device as untrusted.
  • Capture and analyze device traffic. Deploy network monitoring on IoT segments for at least 30 days. Compare observed traffic flows against vendor documentation. Undocumented outbound connections to foreign IP ranges warrant immediate investigation.
  • Revise procurement requirements. Future contracts should mandate: software bill of materials (SBOM), signed firmware, documented and operator-controllable remote access, and the right to independent security testing. If a vendor refuses these terms, find another vendor.
  • Engage your national CERT or equivalent authority. If you operate devices named in the NBÚ advisory, report your deployment and request guidance. Coordinated response is more effective than isolated remediation.

The broader lesson is that IoT procurement in public infrastructure has been operating on trust for too long. Slovakia's warning is a reminder that trust is not a security control — and that the devices we deploy to enforce the rules of the road may not be following the rules themselves.