CRA Compliance for Consumer IoT: EN 303 645 Alignment and Smart Home Security Guide

Consumer IoT products (smart speakers, connected cameras, wearables, smart home devices) face the broadest CRA obligations. Most fall into the Default category, allowing self-assessment, but must still meet all essential requirements. ETSI EN 303 645 provides a strong baseline for compliance.

This guide covers CRA compliance for consumer IoT manufacturers.

Which Consumer IoT Products Are Covered?

CRA Scope for Consumer IoT

The CRA applies to all "products with digital elements" placed on the EU market. For consumer IoT, this includes:

Clearly in scope:

• Smart speakers and voice assistants
• Smart home hubs and controllers
• Connected cameras (security, baby monitors, doorbells)
• Smart lighting systems
• Connected thermostats and HVAC controls
• Smart locks and access systems
• Wearable devices (smartwatches, fitness trackers)
• Connected toys and games
• Smart appliances (fridges, washing machines)
• E-readers and tablets
• Connected health/wellness devices (non-medical)

Partial scope (may have additional regulations):

• Smart TVs (also covered by RED)
• Connected medical devices (also MDR; see our MDR guide)
• Connected vehicles (Machinery Regulation, type approval)

CRA Classification for Consumer IoT

Most consumer IoT falls into Default or Important Class I:

CONSUMER IoT CRA CLASSIFICATION

DEFAULT CATEGORY (Self-assessment):
- Smart speakers
- Connected cameras (home use)
- Smart lighting
- Connected thermostats
- Wearables
- Smart appliances
- Connected toys
- General smart home devices

IMPORTANT CLASS I (Self-assessment with harmonized standards OR third-party):
- Smart home hubs managing other devices
- Home automation gateways
- Consumer VPN solutions
- Parental control software
- Password managers

IMPORTANT CLASS II (Third-party required):
- Consumer firewalls
- Consumer IDS/IPS devices
- (Rare for pure consumer products)

EN 303 645 and CRA Alignment

What Is EN 303 645?

ETSI EN 303 645 "Cyber Security for Consumer Internet of Things: Baseline Requirements" is the leading standard for consumer IoT security. Published in 2020, it's widely adopted and expected to become a CRA harmonized standard.

EN 303 645 Structure:

• 13 provision categories
• 66 mandatory provisions (for baseline compliance)
• Additional recommendations
• Companion test specification (TS 103 701)

EN 303 645 ↔ CRA Mapping

EN 303 645 as Compliance Foundation

Expected status: EN 303 645 is likely to be listed as a CRA harmonized standard, providing "presumption of conformity" for technical requirements.

What EN 303 645 provides:

• Comprehensive security baseline
• Testable provisions (TS 103 701)
• Industry recognition
• Existing certification programs

What CRA adds beyond EN 303 645:

• SBOM requirements
• ENISA vulnerability reporting (24h/72h)
• CE marking procedures
• Formal Declaration of Conformity
• Technical file documentation
• Market surveillance coordination

EN 303 645 → CRA COMPLIANCE APPROACH

IF you have EN 303 645 compliance:
→ Strong technical baseline achieved
→ Use assessment evidence for CRA technical file
→ Add SBOM generation
→ Implement ENISA reporting
→ Prepare CE marking documentation

IF starting fresh:
→ Use EN 303 645 as your technical target
→ Plan for CRA additions from the start
→ Consider EN 303 645 certification

Core Requirements Deep Dive

No Default Passwords (Critical)

EN 303 645 Provision 5.1-1: "Where passwords are used and in any state other than the 'factory default' state, all consumer IoT device passwords shall be unique per device or defined by the user."

CRA Alignment: This is "secure by default" in action.

Implementation:

PASSWORD APPROACHES FOR CONSUMER IoT

OPTION 1: Unique factory password
- Generate unique password per device
- Print on device/packaging
- Store in secure element if available

OPTION 2: User-defined at setup
- Force password creation during setup
- Enforce password complexity
- No "skip" option

OPTION 3: Passwordless authentication
- Bluetooth/WiFi pairing codes
- App-based authentication
- Biometric where appropriate

AVOID:
✗ Universal default passwords ("admin/admin")
✗ Predictable passwords (serial number)
✗ Optional password setting
✗ Easy-to-guess patterns

Vulnerability Disclosure

EN 303 645 Provision 5.2-1: "The manufacturer shall provide a public point of contact as part of a vulnerability disclosure policy..."

CRA Enhancement: CRA requires not just disclosure acceptance but active reporting to ENISA.

Implementation:

CONSUMER IoT VULNERABILITY HANDLING

PUBLIC CONTACT:
- security@company.com
- Security.txt file at /.well-known/security.txt
- Dedicated security page on website

DISCLOSURE POLICY:
- Accept reports from security researchers
- Acknowledge within 5 business days
- Provide status updates
- Coordinate disclosure timing
- Credit researchers (if desired)

ENISA REPORTING (CRA-specific):
- Report actively exploited vulnerabilities within 24 hours
- Report severe vulnerabilities within 72 hours
- Use ENISA Single Reporting Platform

Software Updates

EN 303 645 Provisions 5.3: Software updates capability is mandatory.

Key Requirements:

SOFTWARE UPDATE REQUIREMENTS

UPDATE MECHANISM (5.3.3):
[ ] Secure delivery (signed updates)
[ ] Integrity verification
[ ] Rollback protection
[ ] User notification

UPDATE SUPPORT (5.3.1):
[ ] Defined support period
[ ] Published end-of-support date
[ ] At least product's expected lifetime
[ ] CRA: Minimum 5 years

AUTOMATIC UPDATES (5.3.6):
[ ] Configurable auto-update
[ ] User consent mechanism
[ ] Minimal disruption
[ ] Update status visibility

Secure Communication

EN 303 645 Provision 5.4: Encrypt sensitive data in transit.

Implementation:

COMMUNICATION SECURITY

TRANSPORT ENCRYPTION:
- TLS 1.2+ for all cloud communications
- Strong cipher suites
- Certificate validation
- No fallback to unencrypted

LOCAL COMMUNICATION:
- Encrypt local network traffic where feasible
- Secure pairing mechanisms
- Protected setup/configuration flows

AVOID:
✗ Plain HTTP for any sensitive data
✗ Self-signed certificates without pinning
✗ Weak cipher negotiation
✗ Hardcoded credentials in communications

SBOM for Consumer IoT

Embedded Device Challenges

Consumer IoT devices often run on constrained hardware:

Typical Components:

• Real-time OS or embedded Linux
• Network stacks (lwIP, etc.)
• Protocol libraries (MQTT, CoAP)
• Crypto libraries
• Third-party SDKs (cloud connectivity)
• Application code

SBOM Strategy:

CONSUMER IoT SBOM APPROACH

MINIMUM DEPTH:
1. Operating system/RTOS
2. Major framework/SDK
3. Network/protocol libraries
4. Crypto libraries
5. Cloud connectivity SDK
6. Key third-party components

FORMAT:
- CycloneDX or SPDX
- Include version information
- Include PURL where available
- Document proprietary components

PRACTICAL TIPS:
- Extract from build system
- Automate SBOM generation in CI/CD
- Update SBOM with each firmware release
- Consider tooling (Syft, Trivy, etc.)

Supply Chain Considerations

Consumer IoT often uses common silicon vendors and SDKs:

SUPPLY CHAIN SBOM MANAGEMENT

SILICON VENDOR SDK:
- Request SBOM from vendor (Espressif, Nordic, etc.)
- Many now provide component lists
- Include in your aggregated SBOM

CLOUD PLATFORM SDK:
- AWS IoT, Azure IoT, Google Cloud IoT SDKs
- Well-documented components
- Usually have dependency manifests

THIRD-PARTY MODULES:
- WiFi/Bluetooth modules may have firmware
- Request component information
- Document what you know

DOCUMENT LIMITATIONS:
- Note any components without SBOM visibility
- Explain supply chain constraints
- Update as information becomes available

5-Year Support: The Big Challenge

Industry Context

Many consumer IoT products have historically had short support windows:

• Budget devices: 1-2 years (or no updates)
• Mid-range: 2-3 years
• Premium: 3-5 years

CRA Requirement: Minimum 5 years of security updates from each unit's placement on market.

Planning for 5-Year Support

5-YEAR SUPPORT STRATEGY

COST PLANNING:
- Security monitoring (ongoing)
- Vulnerability response capability
- Update development and testing
- Update delivery infrastructure
- Customer support resources

TECHNICAL PLANNING:
- Stable update mechanism
- OTA infrastructure
- Rollback capability
- Testing across device lifetime

COMMERCIAL PLANNING:
- Product pricing (include support costs)
- Support period communication
- End-of-support process
- Customer migration path

LIFECYCLE STAGES:
Year 1-2: Active development, frequent updates
Year 3-4: Maintenance mode, security-only updates
Year 5:   End-of-support preparation
Year 5+:  Support ends, customer notification

End-of-Support Communication

END-OF-SUPPORT REQUIREMENTS

AT PURCHASE:
- Clear support period indication
- Expected end-of-support date
- What "support" includes

APPROACHING END:
- Advance notification (6-12 months)
- Explanation of implications
- Upgrade/replacement options

AT END-OF-SUPPORT:
- Final notification
- Security recommendations
- Safe disposal guidance

POST-SUPPORT:
- Device may still function
- No security updates
- Customer assumes risk

Consumer Documentation Requirements

Language Requirements

Consumer products sold in EU member states require local language documentation:

CONSUMER IoT DOCUMENTATION LANGUAGES

REQUIRED PER MARKET:
- Safety information: Must be in local language
- Setup instructions: Should be in local language
- User manual: Should be in local language

PRACTICAL APPROACH:
- English as base
- Localize for major markets (DE, FR, ES, IT, PL, NL)
- Consider digital documentation (app, QR code)
- Printed quick-start in multiple languages

What to Document

CONSUMER IoT USER DOCUMENTATION

SECURITY INFORMATION:
[ ] Initial setup security (password, pairing)
[ ] Update settings and recommendations
[ ] Privacy settings
[ ] Data collection explanation
[ ] Support period and contact

SAFETY INFORMATION:
[ ] Electrical safety
[ ] Intended use
[ ] Hazard warnings
[ ] Children's safety (if relevant)

COMPLIANCE INFORMATION:
[ ] CE marking visible on product
[ ] Declaration of Conformity reference
[ ] Manufacturer contact information
[ ] Support/security contact

Conformity Assessment for Consumer IoT

Self-Assessment (Module A)

Most consumer IoT can use self-assessment:

MODULE A FOR CONSUMER IoT

WHAT YOU DO:
1. Perform internal risk assessment
2. Implement essential requirements
3. Prepare technical documentation
4. Test against requirements
5. Complete EU Declaration of Conformity
6. Apply CE marking

NO NOTIFIED BODY NEEDED:
- Default category products
- Important Class I with harmonized standards

TECHNICAL FILE CONTENTS:
- Product description
- Risk assessment
- Design documentation
- Test reports (internal or external lab)
- EN 303 645 assessment (if claimed)
- SBOM
- User documentation

Using EN 303 645 Certification

If you pursue EN 303 645 certification:

EN 303 645 CERTIFICATION → CRA

CERTIFICATION BODIES:
- CTIA (US)
- TÜV (EU)
- BSI Kitemark (UK)
- Various ETSI-aligned labs

BENEFITS:
- Third-party verification
- Marketing value ("certified secure")
- Presumption of conformity (when harmonized)
- Evidence for technical file

FOR CRA, ALSO NEED:
- SBOM (not covered by EN 303 645)
- ENISA reporting process
- Formal EU DoC
- CE marking process

Industry-Specific Guidance

Smart Speakers and Voice Assistants

SMART SPEAKER CRA COMPLIANCE

CLASSIFICATION: Default

KEY REQUIREMENTS:
- Voice data protection
- Secure cloud communication
- Mute/privacy mode (secure by default)
- Update mechanism
- Account security

PRIVACY CONSIDERATIONS:
- Minimize always-on listening
- Clear indicator when listening
- User data access and deletion
- GDPR alignment

Connected Cameras

CONNECTED CAMERA CRA COMPLIANCE

CLASSIFICATION: Default (home) or Important I (security system)

KEY REQUIREMENTS:
- Strong authentication
- Encrypted video streams
- Local storage security
- Cloud storage security
- Privacy masking features

SPECIAL CONSIDERATIONS:
- Video data is highly sensitive
- Physical access protection
- Guest/family access management
- Recording notification requirements

Smart Home Hubs

SMART HOME HUB CRA COMPLIANCE

CLASSIFICATION: Important Class I

KEY REQUIREMENTS:
- Protocol security (Zigbee, Z-Wave, Thread, Matter)
- Secure device onboarding
- Access control for connected devices
- Local vs. cloud processing
- Update mechanism for hub and protocols

SPECIAL CONSIDERATIONS:
- Hub is attack surface for all connected devices
- Matter/Thread security alignment
- Backup/recovery capability

Wearables

WEARABLE DEVICE CRA COMPLIANCE

CLASSIFICATION: Default (fitness) or may have medical overlap

KEY REQUIREMENTS:
- Bluetooth pairing security
- Health data protection
- Phone app security
- Limited attack surface
- Battery-conscious security

SPECIAL CONSIDERATIONS:
- Size constraints affect security features
- Companion app is part of product
- Health data may have additional regulations

Connected Toys

CONNECTED TOY CRA COMPLIANCE

CLASSIFICATION: Default

KEY REQUIREMENTS:
- Child privacy protection (COPPA-like)
- Parental controls
- Safe default settings
- Simple security model
- Appropriate content filtering

SPECIAL CONSIDERATIONS:
- Children as primary users
- Voice/video features need extra care
- Physical safety + cyber safety
- Clear parental guidance

Practical Compliance Roadmap

Phase 1: Assessment (Now - Mid 2026)

CONSUMER IoT ASSESSMENT

PRODUCT INVENTORY:
[ ] List all products with digital elements
[ ] Classify per CRA categories
[ ] Identify products with short current support

GAP ANALYSIS:
[ ] Current vs. EN 303 645 provisions
[ ] SBOM capability
[ ] Update infrastructure
[ ] Support period commitment

PLANNING:
[ ] EN 303 645 compliance path
[ ] SBOM generation tooling
[ ] Support period extension costs

Phase 2: Preparation (Mid 2026 - Sept 2026)

PREPARATION PHASE

TECHNICAL:
[ ] Implement EN 303 645 provisions
[ ] Add SBOM generation to build
[ ] Establish vulnerability handling
[ ] Prepare ENISA reporting capability

DOCUMENTATION:
[ ] Technical file templates
[ ] User documentation updates
[ ] Multi-language preparation

COMMERCIAL:
[ ] Support period definitions
[ ] Pricing review
[ ] Customer communication plan

Phase 3: Compliance (Sept 2026 - Dec 2027)

COMPLIANCE PHASE

SEPTEMBER 2026:
[ ] Vulnerability reporting operational
[ ] ENISA SRP registration

THROUGH 2027:
[ ] Complete conformity assessments
[ ] Update all product lines
[ ] Finalize documentation
[ ] EN 303 645 certification (optional)

DECEMBER 2027:
[ ] All products CRA compliant
[ ] CE marking applied
[ ] Customer communication complete

Checklist for Consumer IoT

CONSUMER IoT CRA CHECKLIST

PRODUCT SECURITY:
[ ] No default passwords (unique or user-set)
[ ] Encrypted communications (TLS 1.2+)
[ ] Secure update mechanism
[ ] Minimal attack surface
[ ] Secure by default settings

EN 303 645 ALIGNMENT:
[ ] Reviewed all 66 provisions
[ ] Implemented mandatory provisions
[ ] Documented compliance evidence
[ ] Considered certification

SBOM:
[ ] SBOM generation in build process
[ ] All major components identified
[ ] Supply chain components included
[ ] Regular SBOM updates

VULNERABILITY HANDLING:
[ ] Public security contact
[ ] Vulnerability disclosure policy
[ ] ENISA reporting capability
[ ] Patch development process

DOCUMENTATION:
[ ] Technical file prepared
[ ] User documentation updated
[ ] Multi-language support
[ ] Support period stated

SUPPORT PERIOD:
[ ] 5-year minimum commitment
[ ] Update infrastructure planned
[ ] End-of-support process defined
[ ] Cost model sustainable

How CRA Evidence Helps

CRA Evidence supports consumer IoT manufacturers:

• EN 303 645 mapping: Track compliance against standard provisions
• SBOM management: Generate and manage SBOMs for embedded devices
• Multi-product support: Manage product families efficiently
• Vulnerability tracking: Consumer-friendly vulnerability management
• Documentation: Technical file generation and management

Start your CRA compliance at app.craevidence.com.

Related Articles

• CRA Product Classification: Default vs Important vs Critical -- Understand how your IoT product is classified under the CRA.
• SBOM for CRA Compliance: Complete Guide to Software Bill of Materials -- Learn how to create and manage SBOMs for embedded IoT devices.
• CRA and Smart Cameras: Connected Camera Security and Compliance -- Deep dive into CRA requirements for connected cameras and video devices.

This article is for informational purposes only and does not constitute legal advice. For specific compliance guidance, consult with qualified legal counsel.