Documenting Cloud Dependencies in CRA Technical Files

Article 31 Requires Technical Documentation Before Market Placement

Article 31 requires manufacturers to draw up technical documentation containing relevant information showing how the product and the manufacturer's processes comply with the essential cybersecurity requirements. The documentation must exist before the product is placed on the market. A cloud-connected manufacturer should therefore define its product and remote-processing boundary before conformity assessment rather than leaving cloud architecture undocumented until an authority asks for it.

• Prepare technical documentation before market placement.
• Document the complete relevant product architecture.
• Include qualifying remote processing.
• Connect architecture to Annex I compliance.

Technical Documentation Must Be Updated Where Appropriate

Article 31(2) requires technical documentation to be continuously updated where appropriate, at least during the support period. This is especially important for cloud-connected products because APIs, infrastructure, providers, software versions and authentication systems can change more frequently than the local hardware or application. The technical file should therefore be a maintained compliance record rather than a frozen launch document.

• Review documentation after material cloud changes.
• Update relevant architecture evidence.
• Update software-version information.
• Keep the technical file current during the support period.

Annex VII Requires a General Product Description and Relevant Software Versions

Annex VII requires a general description of the product, including its intended purpose and versions of software affecting compliance with essential cybersecurity requirements. For cloud-connected products, remote application versions, API generations or other remote software versions can be relevant where changes alter cybersecurity compliance. Manufacturers should avoid documenting only the local firmware version when remote software forms part of the product.

• Document intended purpose.
• Identify security-relevant software versions.
• Include relevant remote software.
• Connect versions to conformity evidence.

The System Architecture Should Show Remote Processing Relationships

Annex VII requires necessary information on design and development, including where applicable a description of the system architecture explaining how software components build on or feed into one another and integrate into overall processing. A cloud-connected architecture should therefore show the relationship between local software, mobile applications, APIs, databases, remote processing modules and important external services.

• Show local and remote software relationships.
• Show important interfaces.
• Show data and command paths.
• Show how remote modules integrate into overall processing.

Distinguish RDPS From Third-Party Remote Services

The technical file should distinguish manufacturer-controlled remote data processing from independently supplied cloud services. This distinction helps demonstrate why one service forms part of the product while another remains an external dependency. The Commission's implementation guidance specifically supports identifying RDPS and reliance on relevant third-party remote solutions instead of treating the entire cloud environment as one undifferentiated product component.

Document the Cybersecurity Risk Assessment for the Cloud Architecture

Annex VII requires the cybersecurity risk assessment against which the product is designed, developed, produced, delivered and maintained, including how Annex I Part I applies. The assessment should therefore cover relevant risks arising from remote processing, cloud interfaces, external providers, authentication dependencies, backend availability and other cloud relationships affecting product security.

• Document RDPS risks.
• Document important external dependency risks.
• Connect risks to Annex I requirements.
• Record product-level mitigations.

Architecture Documentation and the SBOM Serve Different Purposes

Annex VII includes the software bill of materials within vulnerability-handling documentation, but an SBOM does not replace architecture documentation. The SBOM identifies relevant software components and dependencies. Architecture evidence explains how those components and services interact and which product functions they support. A cloud provider service may need architectural documentation even where it is not represented as a software component in the manufacturer's SBOM.

• Use the SBOM for software component visibility.
• Use architecture documentation for system relationships.
• Do not force every cloud service into the SBOM.
• Document external services separately where appropriate.

Document Vulnerability-Handling Processes for Remote Software

Annex VII requires necessary information and specifications concerning vulnerability-handling processes. For cloud products, that evidence should show how vulnerabilities in remote application software, APIs and other qualifying product layers are identified, reported, assessed, remediated and tested. It should also explain how relevant provider security information feeds into product vulnerability management.

• Document vulnerability intake.
• Document backend remediation.
• Document provider advisory handling.
• Document security testing.

Describe the Technical Solutions Used for Secure Update Distribution

Annex VII expressly requires a description of the technical solutions chosen for secure distribution of updates. Where remote software is updated centrally, this can include build systems, artefact controls, deployment pipelines, signing or verification mechanisms, release permissions and production deployment controls. The description should reflect the real security-update path rather than only user-installed firmware or application updates.

• Describe local update mechanisms.
• Describe remote deployment mechanisms.
• Describe security controls around release systems.
• Connect update mechanisms to vulnerability remediation.

Document Production and Monitoring Processes Relevant to Cloud Software

Annex VII also requires necessary information and specifications concerning production and monitoring processes and validation of those processes. For remotely deployed software, production can include build, deployment and cloud configuration processes. Monitoring evidence can include mechanisms used to detect security-relevant failures, unauthorised activity or deployment problems where these are part of the manufacturer's product-security process.

• Document cloud deployment processes.
• Document validation of release processes.
• Document relevant monitoring.
• Identify security ownership.

Include Test Reports Supporting Cloud Security Claims

Annex VII requires reports of tests used to verify product conformity and vulnerability-handling processes. Where remote processing is part of the product, the testing evidence should include appropriate product-facing cloud functions and interfaces. This can include API security, authentication, update delivery, resilience or other risk-driven tests relevant to Annex I compliance.

• Retain relevant API test evidence.
• Retain authentication test evidence.
• Retain update-process evidence.
• Retain vulnerability-handling test evidence.

Provider Evidence Should Be Preserved as Supporting Evidence

Provider certifications, audit reports, service descriptions and contractual security information can support the manufacturer's cloud-risk analysis. Those materials should be treated as supporting evidence rather than a substitute for the manufacturer's technical documentation. The technical file still needs to explain how the provider service is used and how its risks are managed in the product.

• Retain relevant provider assurance.
• Record assurance scope.
• Connect provider evidence to product risk.
• Keep manufacturer conclusions explicit.

Cloud Changes Should Trigger Documentation Review

Because Article 31 requires technical documentation to remain updated where appropriate, manufacturers should establish change triggers. A new cloud provider, authentication system, major API version, remote dependency or backend architecture can justify technical-file review. Not every operational deployment requires rewriting the conformity file, but security-relevant architectural changes should not remain undocumented.

• Review provider changes.
• Review material API changes.
• Review authentication changes.
• Review RDPS boundary changes.
• Update technical documentation where appropriate.

Maintain a Cloud Technical Documentation Matrix

Create a matrix covering each important remote service. Record whether it is RDPS or an external dependency, the product function supported, responsible party, software version where relevant, key interfaces, principal cybersecurity risks, relevant controls, update mechanism, provider evidence, testing evidence and the technical-documentation sections where the service is described. This makes cloud evidence auditable without overstating the legal status of every dependency.

• Identify each important remote service.
• Record RDPS status.
• Record product function.
• Record risk and controls.
• Record update method.
• Record supporting evidence.
• Review after material changes.