Decommissioning Cloud Services Used by CRA Products

Start by Determining What Cloud Service Is Being Retired

Before planning shutdown, identify whether the service is manufacturer-controlled remote data processing, an independently supplied third-party cloud dependency or a broader operational service unrelated to product functionality. This distinction matters because qualifying remote data processing forms part of the product with digital elements, while an external provider service can remain outside the product boundary even though its loss still affects product security or operation.

• Identify the service being retired.
• Determine whether it is RDPS.
• Identify manufacturer responsibility.
• Identify dependent product functions.
• Identify relevant external dependencies.

Retiring RDPS Can Remove a Product Function

Article 3(2) defines remote data processing partly by functional dependency: absence of the remote processing would prevent the product with digital elements from performing one of its functions. A decision to retire qualifying RDPS therefore changes the functioning of the product by definition. Manufacturers should identify the affected functions and assess the resulting cybersecurity and conformity consequences before shutdown.

• Identify functions lost after shutdown.
• Identify affected product versions.
• Assess security consequences.
• Assess conformity consequences.
• Document the decision.

Do Not Treat End of Support and Cloud Shutdown as the Same Legal Event

The CRA establishes a support period during which users can expect vulnerabilities to be handled and security updates to be provided, but it does not define the support-period end date as an automatic mandatory shutdown date for remote services. Conversely, ending a cloud service does not by itself erase support-period obligations that still apply to products already placed on the market. Manufacturers should therefore document the relationship between product support, cloud operation and the intended lifetime of the product instead of assuming the dates are legally interchangeable.

• Record the support-period end date.
• Record the planned cloud-service end date.
• Explain any difference between the dates.
• Assess remaining product-security obligations.

Support-Period Vulnerability Handling Remains Important

Article 13(8) requires manufacturers to ensure that vulnerabilities are handled effectively throughout the support period in accordance with Annex I Part II. If qualifying remote software remains operational during that period, its vulnerabilities need to remain within the manufacturer's product-security process. A manufacturer should not remove the ability to handle product vulnerabilities merely because a cloud migration or commercial service-retirement project has begun.

• Maintain vulnerability monitoring.
• Maintain remediation capability.
• Keep security contacts operational.
• Include remote software while it remains part of the supported product.

Users Must Be Told the Support-Period End Date

Article 13 requires the end date of the support period, including at least the month and year, to be clearly and understandably specified at the time of purchase in an easily accessible manner. Where technically feasible, manufacturers must also display a notification informing users when the product has reached the end of its support period. Cloud-retirement planning should therefore be consistent with support information already provided to users.

• Preserve the disclosed support end date.
• Use at least month and year.
• Keep the information easily accessible.
• Provide end-of-support notification where technically feasible.

Annex II Expressly Requires Secure Decommissioning Instructions

Annex II requires detailed instructions or an internet address referring to instructions concerning secure decommissioning of the product with digital elements, including information on how user data can be securely removed. This requirement provides a direct CRA basis for planning the end of a cloud-connected product lifecycle. Instructions should reflect the actual architecture rather than treating decommissioning as only a physical-device disposal task.

User Data Should Have a Secure Removal Path

Annex I requires products to provide users the possibility to securely and easily remove permanently all data and settings. This becomes especially important where product data exists in remote databases, account systems or cloud storage. A decommissioning plan should identify what user data remains remotely, how the user can remove it and what data must instead be retained under another applicable legal obligation.

• Identify user data stored remotely.
• Provide a secure removal path.
• Remove obsolete product settings where appropriate.
• Separate user deletion from legally required record retention.

Secure Data Transfer Can Be Part of the Exit Plan

Annex I also states that where user data can be transferred to other products or systems, that transfer should be secure. A cloud-service retirement may therefore need an export or migration mechanism where the product architecture and user expectations make transfer relevant. The CRA does not create a universal data-portability format through this provision, but security should be preserved when supported data transfer occurs.

• Identify data suitable for export.
• Protect exported data.
• Authenticate export requests.
• Protect migration channels.
• Avoid insecure emergency-export mechanisms.

Revoke Credentials and Tokens That No Longer Serve a Product Function

Cloud retirement can leave behind API keys, service credentials, refresh tokens, device credentials or administrative secrets. Retaining unnecessary credentials increases attack surface after the corresponding product service has ended. A secure decommissioning process should identify obsolete credentials and revoke or remove them in a controlled manner while preserving credentials still needed for supported products or required migration operations.

• Inventory service credentials.
• Revoke obsolete tokens.
• Remove unused secrets.
• Protect credentials needed during migration.
• Verify revoked credentials no longer work.

Retire Obsolete Product Interfaces Safely

APIs, webhook receivers, device-management endpoints and other internet-facing interfaces can remain attack surfaces if they are abandoned rather than deliberately retired. Manufacturers should identify interfaces associated with the retiring service, disable those no longer needed and verify that old endpoints do not expose data, administrative functionality or insecure fallback behaviour.

• Inventory retiring endpoints.
• Disable obsolete APIs.
• Remove unnecessary webhooks.
• Verify administrative interfaces are closed.
• Test post-decommission behaviour.

Domains and Service Endpoints Need Controlled Retirement

A cloud-connected product can contain hard-coded or configured domain names, API hosts and other remote destinations. Uncontrolled expiry of those resources can create takeover or redirection risks. Where such endpoints remain referenced by deployed products, manufacturers should evaluate the security implications before releasing control of names or infrastructure associated with them. This is a practical security consideration derived from maintaining a secure product lifecycle rather than a separate CRA domain-retention rule.

• Identify referenced domains and hosts.
• Understand whether deployed products still call them.
• Prevent avoidable endpoint takeover risks.
• Document the retirement decision.

Third-Party Provider Termination Still Needs Product Impact Review

Sometimes the manufacturer is not shutting down its own remote software but is leaving an external IaaS, PaaS, SaaS or identity provider. The external service may not itself be RDPS, yet removing it can still affect product security or functionality. The manufacturer should assess migration, credential changes, data handling, new interfaces and changes in provider security controls before terminating the dependency.

• Assess provider-exit impact.
• Plan secure migration.
• Review authentication and credentials.
• Review data movement.
• Update cloud-risk evidence.

Cloud Retirement Can Require Conformity Change Review

Article 13 requires manufacturers to take account of changes in development and production processes and changes in product design or characteristics so products remain in conformity. Retiring a significant remote service can change product characteristics, interfaces and security assumptions. Manufacturers should therefore perform a conformity and cybersecurity review rather than treating decommissioning solely as an infrastructure operation.

• Review changed product characteristics.
• Review changed security assumptions.
• Review Annex I compliance.
• Update conformity evidence where appropriate.

Cloud Shutdown Is Not Automatically a Substantial Modification

The CRA defines substantial modification according to whether a post-market change affects compliance with the essential cybersecurity requirements in Annex I Part I or changes the intended purpose for which the product was assessed. A cloud-service retirement can potentially meet that test, particularly where it significantly changes the product, but not every backend shutdown automatically constitutes a substantial modification. The effect of the specific change should be assessed and documented.

• Assess the specific product change.
• Assess Annex I compliance impact.
• Assess intended-purpose impact.
• Avoid automatic classification based only on the word decommissioning.

Security Update Availability Can Outlive Active Product Operation

Article 13 requires security updates made available to users during the support period to remain available for at least 10 years after issue or for the remainder of the support period, whichever is longer. A cloud shutdown plan should therefore identify any user-accessible security updates, archives or distribution mechanisms that remain subject to that requirement. Pure server-side deployments that were never made available to users should be documented as remediation history rather than automatically treated as downloadable updates subject to the same availability mechanism.

• Identify updates made available to users.
• Preserve required update availability.
• Preserve server-side remediation history.
• Do not confuse update archives with continued cloud operation.

Technical Documentation Can Outlive the Cloud Service

Article 13 requires manufacturers to keep technical documentation and the EU declaration of conformity available to market surveillance authorities for at least 10 years after the product was placed on the market or for the support period, whichever is longer. Shutting down a cloud service therefore does not mean deleting the compliance record for the product. Architecture, risk, vulnerability and change evidence may need to remain available after operational systems have been retired.

• Preserve required technical documentation.
• Preserve conformity records.
• Preserve relevant cloud architecture evidence.
• Preserve security-change history.

Update Technical Documentation to Reflect the Retired Architecture

Article 31 requires technical documentation to remain updated where appropriate during the support period. Where decommissioning changes remote processing, security dependencies or product characteristics, the technical file should record the new architecture and the reasoning behind the transition. The historical state should remain understandable where necessary to explain versions already placed on the market.

• Document the pre-retirement architecture.
• Document the post-retirement architecture.
• Record affected product versions.
• Record risk and conformity conclusions.

Communicate Product Consequences, Not Only Infrastructure Dates

A message saying that a cloud platform will close on a particular date may not tell users what happens to the product. Manufacturers should explain which functions will stop, which functions remain, whether data should be exported or removed, whether an update is needed and what security support remains available. These communications should remain consistent with the support information and secure-decommissioning instructions required by the CRA.

• Explain affected product functions.
• Explain data actions.
• Explain required updates.
• Explain remaining security support.
• Provide clear effective dates.

Use a Controlled Cloud Decommissioning Checklist

A CRA-aware cloud decommissioning checklist should identify the retiring service, RDPS status, affected product functions, support-period status, user communications, user-data removal, data migration, credentials, endpoints, provider dependencies, vulnerability obligations, security-update retention, conformity impact and technical-documentation changes. Completing this review before shutdown reduces the risk of leaving unsupported product functions, insecure residual services or incomplete compliance records.

• Confirm product and cloud scope.
• Confirm support-period status.
• Map lost functions.
• Plan secure data handling.
• Revoke obsolete credentials.
• Retire obsolete interfaces.
• Review conformity.
• Update technical documentation.
• Preserve required records.