CRA Security Responsibilities for IoT Cloud Platforms

An IoT Platform Can Be Part of the Product With Digital Elements

Where an IoT device relies on manufacturer-controlled remote software to perform one of its functions, that software can qualify as remote data processing under Article 3(2). This means the product-security boundary can extend beyond the physical device and firmware into the cloud application layer. Manufacturers should document the complete system rather than treat cloud functionality as a separate operational concern.

• Identify cloud-dependent device functions.
• Identify manufacturer-controlled remote software.
• Apply Article 3(2).
• Document the device and cloud architecture together.

Remote Device Management Is a Strong RDPS Indicator

Recital 12 uses manufacturer-provided remote control of a smart-home device as a clear remote data processing example. IoT platforms commonly provide commands, configuration, status retrieval and device management through remote services. Where those functions depend on manufacturer-developed cloud software, the platform can form part of the CRA product.

• Remote commands can be product functions.
• Remote configuration can be product functionality.
• Remote status can be product functionality.
• Manufacturer responsibility still needs to be confirmed.

Device Identity Should Be Treated as a Security Boundary

Connected products need reliable ways to distinguish authorised devices from unauthorised systems attempting to use cloud services. Annex I requires appropriate controls against unauthorised access, including authentication and identity or access management mechanisms where applicable. IoT architectures should therefore address device identity, credential provisioning, rotation, revocation and protection against credential reuse or unauthorised enrolment according to the identified risks.

• Authenticate devices where appropriate.
• Protect device credentials.
• Support credential revocation.
• Prevent unauthorised device enrolment.
• Separate device and user privileges where needed.

User Authentication and Device Authentication Are Different Controls

An IoT platform can authenticate both people and devices. A user's right to control a thermostat or camera is different from the device's right to connect to the manufacturer's cloud service. Product security design should distinguish these identities and authorisation paths. Combining them carelessly can create privilege escalation or account-takeover paths that affect physical devices.

• Separate user identity from device identity.
• Define authorisation relationships.
• Protect ownership transfer processes.
• Review privileged administrative access.

Protect the Integrity of Remote Commands

Annex I requires protection of commands and configuration against unauthorised manipulation or modification. This is especially important in IoT platforms where remote commands can unlock doors, change alarms, alter environmental controls or modify safety-relevant settings. Manufacturers should ensure commands are authenticated, authorised, integrity protected and constrained to legitimate product actions.

• Authenticate remote command sources.
• Authorise each operation.
• Protect command integrity.
• Reject replay or tampering where relevant.
• Log security-sensitive actions where appropriate.

Cloud Availability Can Affect Essential Product Functions

Annex I includes availability protection for essential and basic functions, including after incidents. Where an IoT product depends on cloud services for important functions, denial of service, provider outages or backend failures can create product-level cybersecurity consequences. Manufacturers should determine which functions need local fallback, resilience, recovery or graceful degradation.

IoT Cloud Platforms Should Minimise External Attack Surfaces

IoT products often expose APIs, messaging brokers, onboarding services, update endpoints and management interfaces to the internet. Annex I requires attack-surface limitation, including external interfaces. Manufacturers should remove unnecessary services, restrict management interfaces, use appropriate authentication and avoid exposing product operations more broadly than required.

• Minimise public endpoints.
• Restrict management interfaces.
• Remove unused services.
• Limit cloud permissions.
• Review internet-exposed product interfaces.

Third-Party Infrastructure Remains an External Dependency

The Commission's smart thermostat example shows that manufacturer-controlled IoT software can qualify as RDPS while underlying third-party IaaS remains a separate external service. The manufacturer still needs to understand provider risks and available controls. Provider responsibility does not replace the manufacturer's obligation to ensure that the complete product satisfies applicable CRA requirements.

• Separate application and infrastructure layers.
• Assess provider security.
• Use available cloud security controls.
• Maintain product-level mitigations.

Remote Updates Need Secure Cloud Delivery

Annex I Part II requires vulnerabilities to be addressed through security updates and includes secure distribution expectations. IoT cloud platforms frequently coordinate firmware or software update delivery. Manufacturers should protect update metadata, authenticity, integrity and distribution processes so that cloud compromise cannot be used to deliver malicious updates to connected devices.

• Authenticate update artefacts.
• Protect update integrity.
• Protect update metadata.
• Restrict update publishing privileges.
• Monitor update infrastructure.

Cloud Telemetry Does Not Automatically Become RDPS

IoT devices often transmit operational or statistical telemetry. Remote processing used only for statistics or future product development does not necessarily satisfy the Article 3(2) function test if the product performs all of its functions without that processing. Telemetry that directly powers monitoring, alerts, automation or another product capability can require a different conclusion.

• Identify telemetry purpose.
• Test whether product functionality depends on it.
• Separate statistical processing from product services.
• Document the conclusion.

IoT Platform Changes Need CRA Change Control

Cloud platforms evolve continuously. Changes to device enrolment, authentication, remote commands, data flows, update services or providers can change cybersecurity risk without any physical product redesign. Manufacturers should therefore connect cloud-platform change management to their CRA risk assessment and technical documentation processes.

• Review authentication changes.
• Review new APIs.
• Review provider changes.
• Review remote command changes.
• Update risk evidence where necessary.

Maintain an IoT Cloud Security Responsibility Matrix

A responsibility matrix should identify device firmware, mobile applications, product-facing APIs, message brokers, authentication services, update infrastructure, databases, manufacturer-controlled cloud modules and third-party provider layers. For each element, identify the responsible party, RDPS status, product functions supported and principal security controls. This keeps CRA responsibility clear across a complex connected-product architecture.

• Map device and cloud components.
• Identify responsible entities.
• Record RDPS status.
• Map security controls.
• Identify external dependencies.
• Review after platform changes.