CRA Compliance Checklist: CCTV & Video Surveillance
Annex III Class I for professional CCTV and IP cameras — Default for basic consumer cameras; Class II if deployed in critical infrastructure monitoring roles
CCTV and video surveillance systems — including IP cameras, network video recorders (NVRs), video management software (VMS), and integrated surveillance platforms — are products with digital elements with a significant history of security vulnerabilities. IP cameras have repeatedly been mass-compromised to form botnets (Mirai and successors). Professional surveillance systems used in critical infrastructure are Annex III Class I or II. Consumer cameras are Default. All must meet CRA security requirements.
1. Scope & Classification
Confirm all IP cameras, NVRs, DVRs, and VMS software are products with digital elements in CRA scope
All IP cameras with network connectivity and updateable firmware are in scope. NVRs, DVRs, and video management software are also in scope. Even basic analog-over-coax systems with IP management modules are in scope.
Assess Class I for professional CCTV systems — particularly those monitoring public spaces, critical infrastructure, or high-security environments
Professional surveillance systems for retail, commercial buildings, transport hubs, and government facilities are important products. Class I is likely for most professional deployments.
Assess Class II for surveillance systems forming part of critical infrastructure monitoring — power stations, border control, national security monitoring
Surveillance systems integrated into critical infrastructure security monitoring may be Class II given the impact of their compromise on national security or public safety.
Compile SBOM for IP camera firmware, NVR OS, VMS, and video analytics components — camera firmware historically contains many vulnerable open-source components
IP camera firmware typically includes embedded Linux, RTSP server, web interface, and video codec libraries. SBOM generation is critical given the historically poor security record of camera firmware.
2. Product Security (Annex I Part I)
Eliminate all default credentials — require unique per-device credentials or forced setup. This is the primary cause of Mirai-style mass compromise
Default credentials on IP cameras have enabled the largest IoT botnets in history. CRA explicitly prohibits insecure defaults. Each camera must have unique credentials or require user-set credentials before network activation.
Disable all unnecessary services — Telnet, UPnP, ONVIF discovery broadcasting, and debugging interfaces must be off by default
IP cameras notoriously expose unnecessary services. Conduct a comprehensive service audit. Disable everything not required for the documented product function. ONVIF discovery should be opt-in.
Implement encrypted video streams using TLS/SRTP for all remote video access — prevent eavesdropping on surveillance footage
Unencrypted RTSP streams are accessible to any network observer. All remote video access must use encrypted protocols. This is both a CRA requirement and a GDPR necessity for public area surveillance.
Implement signed firmware updates with version verification — prevent downgrade attacks to known-vulnerable firmware
Signed updates and downgrade protection prevent attackers from forcing cameras to run vulnerable old firmware. Implement both update signing and anti-rollback protection.
For cameras with AI analytics (face recognition, object detection), implement data minimisation and access controls on analytics data
AI surveillance analytics generate highly sensitive data. Implement strict access controls, data minimisation, retention limits, and encryption. Face recognition data is biometric special category data under GDPR.
3. CVD Policy & Vulnerability Handling
Publish a CVD policy and security.txt — IP camera manufacturers receive significant security researcher attention
IP cameras are among the most actively researched IoT devices. A CVD policy with a responsive security team is essential for managing the volume of reports.
Establish automated firmware CVE scanning for all camera product lines and a structured patch release process
Camera firmware contains many open-source components. Implement automated SBOM-based CVE scanning (Grype, Trivy) and a regular patch release cadence.
Define security support lifecycle — minimum 5 years for consumer cameras, 7 years for professional, from last unit production
Professional surveillance cameras are installed for 7–10 years. Publish per-model security support end dates and proactively notify customers 12 months before end of support.
4. Article 14 Incident Reporting
Monitor for active exploitation of camera vulnerabilities — including recruitment into botnets and live video stream exposure
Mass compromise of IP cameras into botnets and unauthorised access to live video feeds are active, ongoing threats. Subscribe to threat intelligence and monitor for your platform-specific campaigns.
Coordinate Article 14 and GDPR breach notifications for incidents exposing surveillance footage — video of individuals is personal data
Unauthorised access to surveillance footage depicting identifiable individuals triggers GDPR Article 33 breach notification obligations alongside CRA Article 14.
5. CE Marking & Technical Documentation
Prepare technical file with camera firmware security architecture, service audit documentation, SBOM, and update mechanism evidence
Given the history of IP camera security failures, market surveillance authorities may scrutinise camera technical files particularly carefully. Invest in thorough, evidenced documentation.
Issue EU Declaration of Conformity referencing the CRA and affix CE marking before EU market placement
DoC must reference the CRA. Wi-Fi or cellular cameras must also reference the Radio Equipment Directive.
Track your CCTV & Video Surveillance compliance progress in CVD Portal.
Public CVD submission portal, Article 14 deadline alerts, SBOM tracking, and CSAF advisory generation. Free forever for manufacturers.
Start your free portalFrequently asked
We manufacture IP cameras that OEM customers rebrand and sell — who holds CRA obligations?+
If a customer rebrands your camera and places it on the market under their name, they become the 'manufacturer' for CRA purposes and assume full CRA obligations. However, your underlying firmware and hardware must be CRA-compliant for them to meet their obligations. Provide your OEM customers with CRA technical documentation, SBOM data, and vulnerability notification processes. Clearly define responsibilities in your OEM agreements.
Our cameras support ONVIF — does ONVIF compliance help with CRA?+
ONVIF compliance demonstrates interoperability, not security. ONVIF Profile S/T/G includes RTSP and WS-Security, but ONVIF itself does not mandate strong security configurations. Your camera must implement secure ONVIF with encrypted streams and authenticated access. ONVIF compliance is not evidence of CRA compliance. Disable ONVIF discovery broadcasting by default to reduce exposure.
Our cameras use facial recognition — do we need a GDPR DPIA and how does it interact with CRA?+
Yes. Processing biometric data for facial recognition is high-risk processing under GDPR requiring a Data Protection Impact Assessment (DPIA). Facial recognition data is special category under GDPR Article 9. The CRA independently requires privacy protection in Annex I Part I(4). Run the DPIA alongside your CRA compliance work. The EU AI Act also applies to real-time remote biometric identification in public spaces — this is generally prohibited with narrow exceptions.
Need a CVD policy for CCTV & Video Surveillance?
Download a free CRA-compliant disclosure policy template and deploy it in minutes.