Updating Remote Processing Components

Remote Product Software Is Part of the Update Lifecycle

Where manufacturer-controlled remote software qualifies as remote data processing, it forms part of the product with digital elements. Vulnerability management therefore cannot stop at firmware, desktop binaries or mobile applications. APIs, databases, remote processing modules and other qualifying backend software should be included in the manufacturer's product update and remediation lifecycle.

• Include RDPS in vulnerability monitoring.
• Include remote software in remediation planning.
• Include backend changes in product-security records.
• Maintain product-level ownership for remote fixes.

Annex I Requires Vulnerabilities to Be Addressable Through Security Updates

Annex I Part I requires products, where applicable based on the cybersecurity risk assessment, to ensure that vulnerabilities can be addressed through security updates. The requirement is architecture neutral. For a cloud-connected product, a security update can involve local software, remote software or both depending on where the vulnerability exists.

• Identify which product layer contains the vulnerability.
• Provide an effective remediation path.
• Do not assume every update must be installed locally.
• Keep remote software within the security-update process.

Backend Remediation Can Be a Server-Side Security Update

A manufacturer can fix a remote processing vulnerability by deploying corrected backend code without requiring user action. Other fixes can involve a secure configuration change, credential rotation, replacement of a vulnerable dependency or isolation of an affected remote function. The important CRA question is whether the vulnerability has been effectively addressed in relation to the risk, not whether the remediation arrived as a downloadable patch.

• Backend code deployment can remediate vulnerabilities.
• Configuration changes can be security fixes.
• Dependency replacement can be remediation.
• Document what changed and why.

Remediation Must Be Timely in Relation to Risk

Annex I Part II requires vulnerabilities to be addressed and remediated without delay in relation to the risks posed to the product. This is a risk-based requirement rather than one universal deadline for every vulnerability. A remotely exploitable backend weakness affecting authentication or remote commands can justify a different remediation priority from a low-impact issue in an isolated service.

• Assess product impact.
• Assess exploitability.
• Prioritise according to risk.
• Record remediation decisions.

Security Updates Should Be Separated From Functionality Updates Where Technically Feasible

Annex I Part II provides that, where technically feasible, new security updates should be provided separately from functionality updates. Continuous cloud deployment can combine many code changes, but manufacturers should still maintain the ability to identify security-relevant changes and distinguish vulnerability remediation from ordinary feature development in their release and compliance evidence.

• Identify security-relevant changes.
• Avoid hiding critical fixes inside undocumented feature releases.
• Maintain release traceability.
• Separate security and functionality changes where technically feasible.

Automatic Update Rules Should Be Applied According to the Architecture

Annex I Part I includes automatic security-update requirements where applicable, including installation within an appropriate timeframe, default enablement, user notification and an opt-out mechanism. These provisions are primarily framed around updates delivered to products used by customers. Manufacturer-controlled remote software can already be updated centrally without requiring a user installation decision. The manufacturer should therefore apply the CRA requirements according to the actual update architecture rather than inventing a user opt-out for backend deployments where that concept does not fit.

Secure Distribution Still Matters for Remote Deployments

Annex I Part II requires mechanisms for secure distribution of updates. For remotely deployed product software, the relevant distribution chain can include source repositories, build pipelines, artefact registries, deployment systems, signing mechanisms, infrastructure credentials and production release permissions. Compromise of that chain can turn an intended security update into a supply-chain attack.

• Protect build and deployment pipelines.
• Protect update artefacts.
• Restrict production release permissions.
• Protect deployment credentials.
• Validate deployed software.

Security Fixes Should Be Tested Before and After Deployment

Annex I Part II requires effective and regular security tests and reviews. A backend vulnerability fix should therefore be validated before deployment and monitored afterwards where appropriate. Testing should confirm that the vulnerability is remediated without introducing new access-control, integrity, availability or compatibility problems.

• Reproduce the vulnerability where appropriate.
• Verify the fix.
• Perform regression testing.
• Monitor post-deployment behaviour.

Remote Software Remains Within the Support-Period Obligation

Article 13 requires effective vulnerability handling throughout the product support period. A manufacturer cannot maintain the physical device while abandoning a manufacturer-controlled backend that the product still requires for a function. Support planning should therefore account for the expected lifetime and maintenance of qualifying remote processing as well as local software.

• Include backend maintenance in support planning.
• Plan dependency upgrades.
• Plan cloud platform migrations.
• Maintain vulnerability response capability.

Issued Security Updates Have a Long Availability Requirement

Article 13(9) requires each security update made available to users during the support period to remain available for at least 10 years after it is issued or for the remainder of the support period, whichever is longer. The rule is most directly relevant where an update is something users need continued access to. Server-side remediation should still be documented so the manufacturer can demonstrate what security changes were implemented and when.

• Track security-update release dates.
• Preserve user-accessible updates where the rule applies.
• Preserve remediation evidence for server-side fixes.
• Connect update records to supported product versions.

Backend Changes Can Require Cybersecurity Risk Reassessment

Article 13 requires relevant cybersecurity aspects to be documented and the cybersecurity risk assessment updated where applicable. A backend migration, major API redesign, new authentication provider or significant dependency change can alter the attack surface even where the local product remains unchanged. Cloud change management should therefore include a CRA security review trigger.

• Review major backend changes.
• Review authentication changes.
• Review significant dependency changes.
• Update risk evidence where applicable.

Maintain Procedures for Continued Product Conformity

Article 13 requires manufacturers to maintain procedures ensuring that products in a series remain in conformity and to take account of changes in development and production processes or product design and characteristics. For cloud-connected products, continuous backend development is part of that operational reality. Manufacturers should prevent cloud release velocity from bypassing conformity controls.

• Connect cloud release processes to compliance controls.
• Review security-relevant product changes.
• Maintain version and deployment evidence.
• Preserve continued conformity.

Maintain a Remote Processing Update Record

For security-relevant remote changes, maintain a record identifying the affected service, product function, vulnerability or security reason, old and new software version or configuration, security testing, deployment date, rollback approach, risk-assessment impact and technical-documentation impact. This gives remote software the same compliance traceability expected from other product layers.

• Identify affected remote software.
• Record security reason.
• Record deployment evidence.
• Record testing.
• Record risk impact.
• Update technical documentation where needed.