← CRA Compliance Checklists
Safety & SecurityDeadline: September 2026

CRA Compliance Checklist: Smart Cameras & Video Surveillance

Default Class for consumer cameras — review Annex III for security/CCTV infrastructure use

Smart cameras and IP video surveillance systems are frequently compromised via default credentials and unpatched firmware — they were among the first device classes targeted by Mirai and similar botnets. The CRA's prohibition on default passwords and requirement for secure update mechanisms directly target these failure modes. Manufacturers must also consider GDPR obligations around video data and the NIS2 implications for critical infrastructure deployments.

19
checklist items
17
high priority
September 2026
deadline
Safety & Security
sector
CRA Classification:Default Class for consumer cameras — review Annex III for security/CCTV infrastructure use

1. Scope & Classification

Confirm all IP cameras, NVRs, and video management software are in scope as products with digital elements

highArticle 3(1)

Any camera with network connectivity (Ethernet, Wi-Fi, LTE) is in scope. Analogue cameras without network interfaces are not.

Review Annex III classification for cameras marketed for critical infrastructure or government security use

highAnnex III

Consumer-grade IP cameras are Default class. Cameras integrated into critical infrastructure security systems may face stricter classification.

Compile SBOM for all camera firmware — including embedded OS, video codec libraries, and ONVIF implementation

highArticle 10(6)

Camera firmware typically includes complex video processing stacks with many open-source dependencies. Each must be tracked for CVEs.

2. Default Credentials & Authentication

Eliminate all default, hardcoded, or shared credentials — require unique credentials or forced setup on first access

highAnnex I, Part I(2)

Default credentials are the primary attack vector for IP cameras. Mirai and variants specifically exploit default camera credentials. This is explicitly prohibited by the CRA.

Require password change on first login — refuse access until a strong password is set

highAnnex I, Part I(2)

Cameras must not allow access with factory credentials beyond initial setup. Force password creation before full functionality is enabled.

Implement account lockout after repeated failed authentication attempts

highAnnex I, Part I(3)

Rate-limit and lock authentication endpoints to prevent credential brute-force attacks.

Support certificate-based authentication for API and ONVIF integration

mediumAnnex I, Part I(3)

Enterprise and integration use cases require certificate-based authentication. Support both password and certificate auth.

3. Video Data Security

Encrypt all video streams in transit using TLS 1.2+ or DTLS for SRTP

highAnnex I, Part I(4)

Unencrypted video streams allow eavesdropping. RTSP over TLS (RTSPS) or WebRTC with SRTP/DTLS is required.

Encrypt video stored on-device (SD card) and in cloud storage

highAnnex I, Part I(4)

Video recordings may contain sensitive personal data. Storage encryption prevents data exposure if physical access is obtained.

Disable remote access and cloud services by default — require explicit user opt-in

highAnnex I, Part I(5)

Remote access features significantly increase attack surface. They should be opt-in, not enabled by default.

4. Firmware Security

Implement cryptographically signed firmware updates — reject unsigned or tampered updates

highAnnex I, Part I(9)

Camera firmware updates must be signed. The device must verify the signature before applying any update to prevent malicious firmware injection.

Enable automatic security update notifications or opt-in automatic updates

highAnnex I, Part I(9)

Camera owners rarely manually update firmware. Implement update notification and ideally automatic security patch delivery.

Implement secure boot to verify firmware integrity at startup

mediumAnnex I, Part I(9)

Secure boot prevents running modified firmware even if an attacker has physical access to the device.

Disable unused services and ports (Telnet, UPnP, unnecessary HTTP APIs) by default

highAnnex I, Part I(5)

Camera attack surface must be minimal by default. Disable all services that are not required for core function.

5. CVD & Vulnerability Management

Publish a CVD policy and security.txt — camera firmware is heavily researched by the security community

highArticle 13(1)

IP cameras are among the most targeted consumer devices. A clear CVD policy is essential for receiving and responding to vulnerability reports.

Establish monitored vulnerability intake with 48h acknowledgment SLA

highArticle 13(3)

Camera vulnerabilities are frequently weaponised quickly. A fast intake and acknowledgment process is critical.

Define firmware support lifecycle — minimum 5 years from product launch

highAnnex I, Part II(5)

Cameras are often deployed for many years. Support periods must reflect realistic deployment lifetimes. Publish end-of-life dates.

6. Article 14 Incident Reporting

Monitor threat intelligence for active exploitation of your camera models

highArticle 14(1)

Camera CVEs are actively exploited by botnet operators. Subscribe to ICS-CERT, CISA KEV, and vendor-specific threat feeds.

Document Article 14 notification process for camera vulnerability exploitation events

highArticle 14(2)

Camera botnet recruitment is a common Article 14-triggering event. Pre-prepare your escalation and ENISA notification process.

Track your Smart Cameras & 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 portal

Frequently asked

Do smart doorbells and baby monitors fall under the same requirements as professional CCTV?+

Yes. Smart doorbells, baby monitors, and indoor IP cameras are all products with digital elements subject to the CRA. The same Annex I requirements apply regardless of whether the camera is marketed as consumer or professional. The conformity assessment route differs — consumer cameras can self-assess, while cameras for critical infrastructure may require third-party assessment.

We use ONVIF for camera interoperability — does CRA compliance affect ONVIF implementation?+

ONVIF Profile S, T, and G implementations often involve unauthenticated or weakly authenticated interfaces. CRA Annex I requires that management interfaces use authenticated, encrypted communication. You must ensure your ONVIF implementation supports and enforces authentication, and disable ONVIF access without credentials.

Our cameras use UPnP for automatic router port forwarding — can we keep this?+

UPnP-based automatic port forwarding creates significant security risks by exposing cameras to the internet without explicit user action. CRA Annex I Part I(5) requires minimising the attack surface. UPnP auto-port-forward should be disabled by default or removed entirely, with manual port forwarding or VPN as the recommended access method.

Need a CVD policy for Smart Cameras & Video Surveillance?

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

Browse templates →