← Industry Guides
Public SectorCRA Guide

EU Cyber Resilience Act Guide for Smart City Infrastructure Vendors

Standard Default (most smart city devices); Important Class I if integrated with city operational systems

Smart city infrastructure vendors supplying connected streetlighting, environmental sensors, waste management systems, urban mobility platforms, and city management software to EU municipalities must comply with the CRA. The public sector deployment context means that smart city products are subject to both CRA obligations and the procurement requirements of NIS2-regulated public authorities. CRA compliance is rapidly becoming a prerequisite for EU municipal and national government smart city contracts, and vendors must demonstrate conformity credibly before the September 2026 deadline.

Article 13Article 14Annex IArticle 10Article 11Article 3
Deadline: September 2026Classification: Standard Default (most smart city devices); Important Class I if integrated with city operational systems

CRA Scope and Classification for Smart City Products

Smart city products placed on the EU market — including networked streetlight controllers, LoRaWAN environmental sensor networks, connected waste bin monitoring systems, urban noise monitoring platforms, city operations centre dashboards, smart irrigation systems for public parks, and public Wi-Fi management platforms — are products with digital elements under Article 3(1). Most standalone smart city sensors and devices will qualify as Default-category products subject to standard CRA security requirements. However, platforms integrated with city operational infrastructure — traffic management, emergency services coordination, or critical utility monitoring — may qualify as Important Products Class I or Class II. Vendors supplying smart city platforms that aggregate data from multiple subsystems into a central operational platform should assess classification carefully, as the aggregated platform may carry higher risk than any individual component.

CRA reference:Article 3(1), Article 7

Technical Security for Large-Scale Urban IoT Deployments

Smart city IoT deployments present distinct security challenges: devices are deployed in public spaces in large numbers, are physically accessible to the public, use low-power wide-area networks with constrained cryptographic capabilities, and must be managed remotely across city-scale infrastructure. Annex I obligations for smart city vendors include: implementing device authentication for all communications in the IoT network, using lightweight cryptographic protocols appropriate for constrained devices (e.g. DTLS for UDP-based protocols); eliminating default credentials on all devices and management gateways; designing remote firmware update mechanisms capable of updating thousands of field devices without requiring physical access; implementing anomaly detection to identify compromised devices within the city network; and documenting the security architecture of the complete system including field devices, gateways, communication networks, and cloud or on-premises management platforms. The SBOM must cover firmware for field devices, gateway software, and the city management platform.

CRA reference:Annex I Parts I and II

CVD Policy Under Article 13 for Public Sector Vendors

Article 13 requires a published CVD policy. For smart city vendors, the CVD programme is particularly visible because municipal technology is subject to public scrutiny and freedom of information obligations in many EU member states. The CVD policy should: establish a dedicated security reporting channel responsive to both security researchers and municipality IT teams; define clear response timelines; specify how security advisories are communicated to multiple municipal customers simultaneously; and address the public sector change management processes that govern when and how security patches can be applied to city infrastructure. Because smart city data — including environmental sensor data, population movement data, and public space usage information — may include personal data subject to GDPR, the CVD policy should address the privacy implications of potential data breaches alongside cybersecurity incident handling.

CRA reference:Article 13(6), Article 13(7)

Article 14 Incident Reporting in Public Sector Context

Article 14 notification obligations require CSIRT notification within 24 hours of confirmed active exploitation. For smart city vendors, exploitation of city infrastructure — manipulation of streetlighting, disruption of waste management monitoring, compromise of city operations data — is primarily a service disruption and reputational concern rather than an immediate public safety issue, though exploitation of integrated emergency services or traffic management components carries public safety implications. Vendors must maintain monitoring telemetry that provides visibility into exploitation attempts across city deployments, and must have pre-established notification procedures for municipal customers who, as public authorities, may have their own incident notification obligations under national cybersecurity regulations. Public sector customers will expect rapid, transparent vendor communication during any incident.

CRA reference:Article 14(1), Article 14(2)

CRA Compliance as a Municipal Procurement Requirement

EU public procurement rules (Directive 2014/24/EU) permit contracting authorities to specify technical requirements including cybersecurity standards in procurement specifications. EU member state governments and municipalities are increasingly incorporating CRA compliance requirements into smart city procurement specifications, citing NIS2 supply chain security obligations and EU cybersecurity strategy commitments. CRA CE marking will function as a minimum baseline technical requirement in many public sector smart city tenders by 2026. Vendors should document CRA compliance readiness proactively and prepare a procurement-ready compliance summary — including CE marking status, technical file summary, CVD policy URL, and security support policy — that can be attached to tender responses. Early CRA compliance provides a competitive advantage in the procurement process.

CRA reference:Article 24, Article 28, Annex VIII

CVD Portal handles your CRA Article 13 obligations automatically.

Public CVD submission portal, 48-hour acknowledgment tracking, Article 14 deadline alerts, and CSAF advisory generation. Free forever for Smart City Infrastructure Vendors.

Start your free portal

Frequently asked

Our smart city platform uses LoRaWAN. LoRaWAN has specific security limitations — how do we address these under Annex I?+

LoRaWAN v1.1 provides application-layer and network-layer encryption and device authentication using AES-128, which satisfies Annex I requirements for proportionate security on constrained IoT devices. If your deployments use older LoRaWAN v1.0, you should document the security limitations, provide upgrade paths to v1.1, and specify compensating controls (e.g. application-layer encryption of sensor payloads). The technical file should document the complete cryptographic architecture including key provisioning — how device AppKeys and NwkKeys are generated, stored, and distributed — as this is a common vulnerability point in LoRaWAN deployments. Key provisioning security must meet Annex I requirements regardless of the network protocol used.

A municipality procures our smart city platform under a 10-year concession contract. How do security update obligations work over such a long contract period?+

The CRA requires security updates for the expected product lifetime. For a smart city platform under a 10-year concession, the expected lifetime is clearly at least 10 years, and your support obligations under CRA extend accordingly. This should be explicitly addressed in the concession contract: the contract should define the vendor's security update obligations, the municipality's obligations to apply updates within defined timelines, the process for handling security patches that require service downtime, and arrangements for addressing vulnerabilities in end-of-life components where upstream support has ceased. Vendors should cost long-term security update obligations into their contract pricing — the days of selling city infrastructure and walking away from security support are over under the CRA.

Our smart city sensors collect environmental data only — no personal data. Does GDPR interact with our CRA obligations?+

Environmental sensors collecting purely environmental data (temperature, air quality, noise levels) with no personal data processing may have limited GDPR interaction. However, smart city sensors that capture vehicle number plates, track mobile device identifiers (e.g. Wi-Fi probe request monitoring), or enable inference of individual presence or movement patterns do process personal data and are subject to GDPR in addition to the CRA. Even for non-personal-data sensors, the CRA obligations — Annex I security requirements, CVD policy, incident notification — apply in full. If you expand sensor functionality in future firmware updates to include personal data collection, GDPR scope analysis must be repeated at that point.

Need a CVD policy template for Smart City Infrastructure Vendors?

Download a free CRA-compliant vulnerability disclosure policy and deploy it in minutes.

Browse templates →