CRA Considerations for Product APIs

An API Is Not Automatically Inside or Outside the CRA

The word API describes an interface rather than a complete legal category. CRA scope depends on the software behind that interface, who is responsible for it and what product function depends on it. A manufacturer-developed product API can be part of remote data processing, while an unrelated external API or an internal administrative API can require a different analysis. Product teams should therefore avoid maintaining a single rule that all APIs are product components or that APIs are merely infrastructure.

• Identify the software behind the API.
• Identify who controls its development.
• Identify which product function uses it.
• Apply Article 3(2).

Recital 11 Expressly Identifies Manufacturer-Developed APIs

Recital 11 provides one of the clearest CRA backend examples. A mobile application may require access to an API or database supplied by a service developed by the manufacturer. The recital states that such a service falls within the Regulation as a remote data processing solution. This means manufacturers should not limit CRA product documentation to code running on the user's device when core product functionality is delivered through their backend API.

• Manufacturer APIs can qualify as RDPS.
• Remote databases can qualify as RDPS.
• Mobile applications can depend on in-scope backend services.
• Document the complete product architecture.

The API Must Support a Product Function

Article 3(2) still requires functional dependency. If removal of the API prevents the product from performing one of its functions, this supports RDPS classification where manufacturer responsibility is also present. Examples can include authentication, remote commands, synchronisation, product configuration, account management or other capabilities. An API used only for unrelated corporate analytics can produce a different result.

Authentication APIs Can Be Within the Product Boundary

The Commission guidance states that identity and access management can be a product function supported by remote processing. It also explains that an authentication portal issuing credentials or tokens required for a product to operate can qualify as RDPS where the other Article 3(2) conditions are met. Authentication APIs should therefore be assessed as functional product dependencies rather than automatically treated as generic enterprise identity infrastructure.

• Map authentication to product operation.
• Identify token and credential dependencies.
• Identify manufacturer responsibility.
• Separate product authentication from unrelated workforce identity systems.

Not Every Backend Behind the API Is RDPS

The Commission guidance narrows the product boundary in an important way. RDPS that form part of the product should be limited to the software modules responsible for product functionality and the interfaces those modules use with external services. Further backend systems that perform subsequent processing and with which the product does not directly interact are not themselves considered RDPS. This prevents one product-facing API from automatically pulling an entire enterprise backend estate into product scope.

• Identify the product-facing software module.
• Identify interfaces used by that module.
• Separate deeper subsequent-processing systems.
• Do not extend the CRA product boundary indefinitely.

Deeper Backend Systems Can Still Create Cybersecurity Risk

A deeper backend system can sit outside the RDPS boundary while still affecting product security. Commission guidance says such systems remain external dependencies that should be considered in the cybersecurity risk assessment where relevant. Product-level mitigations can include input validation, strong authentication, integrity checks, isolation, defensive API design and restrictions on data flows between product-facing services and deeper systems.

• Out of RDPS does not mean irrelevant.
• Assess external dependency risk.
• Protect product-facing interfaces.
• Use isolation and validation where appropriate.

Third-Party APIs Need the Manufacturer-Responsibility Test

Where a product calls an API supplied and developed independently by another provider, the manufacturer-responsibility limb of Article 3(2) may not be satisfied for that service. The manufacturer should still examine whether the third-party service is integrated into the product in a security-relevant way. The Commission's third-party SaaS treatment supports a component-like risk and due-diligence approach for external remote services that do not qualify as RDPS.

• Identify who developed the external API.
• Identify who controls changes.
• Assess product security consequences.
• Perform appropriate provider due diligence.

API Gateways Need Layered Analysis

An API gateway can sit between the product and multiple backend services. The gateway software can itself be under the manufacturer's responsibility while some downstream services are third-party or independent internal systems. The scope record should therefore analyse the gateway, product-facing API implementation and downstream dependencies separately. Treating the whole architecture as one backend can obscure which elements are RDPS and which are external dependencies.

• Identify gateway ownership.
• Identify product-facing application logic.
• Identify downstream services.
• Record scope per software layer.

Telemetry APIs Need a Function Test

The Commission guidance distinguishes remote processing used purely for statistical telemetry or future product development where its absence does not prevent a product function. Such processing is not RDPS merely because product data is sent remotely. Telemetry APIs that directly power user-visible monitoring, alerts or another product capability can require a different conclusion. Manufacturers should therefore document what the telemetry service actually does.

• Pure statistical telemetry can be outside RDPS.
• User-facing monitoring can be different.
• Test product functionality without the API.
• Document telemetry purpose.

API Security Controls Belong in the Product Risk Assessment

Where an API is part of the product's RDPS, API security forms part of the cybersecurity risk assessment and Annex I compliance work for the product as a whole. Risks can include broken authentication, excessive authorisation, insecure data flows, injection, replay, insufficient integrity checking, abuse of exposed operations and dependency on external services. Controls should be selected according to the identified product risks rather than merely according to generic API checklists.

• Assess authentication risk.
• Assess authorisation boundaries.
• Protect confidentiality and integrity.
• Validate inputs and responses.
• Limit exposed functionality.
• Monitor security-relevant API changes.

API Version Changes Can Affect CRA Evidence

Backend APIs evolve independently from installed software in many products. A material API change can alter authentication, authorisation, data structures, remote functions or third-party dependencies without changing the local application binary. Manufacturers should therefore maintain versioned architecture and risk evidence for product-facing APIs and reassess whether changes affect the product's cybersecurity risk assessment or conformity evidence.

• Track API versions.
• Track security-relevant behaviour changes.
• Track new external dependencies.
• Update architecture evidence.
• Review the cybersecurity risk assessment.

Document the API Boundary in Technical Documentation

Commission guidance recommends that manufacturers describe RDPS and important third-party remote dependencies in technical documentation. For APIs, the record should identify the product-facing interface, responsible software module, dependent product functions, authentication model, remote database or processing relationships, relevant third-party services and deeper systems treated as external dependencies. This makes the conformity boundary reproducible instead of relying on an undocumented architecture diagram.

• Identify product-facing endpoints or interface groups.
• Identify responsible software modules.
• Map product functions.
• Document authentication relationships.
• Identify external services.
• Separate deeper backend dependencies.

Use an API Scope and Risk Register

For significant APIs, maintain a register showing the API purpose, product functions supported, software owner, development responsibility, authentication method, upstream and downstream dependencies, behaviour if unavailable, RDPS conclusion, cybersecurity risks and technical-documentation reference. This combines legal scope analysis with the engineering facts needed to keep the product boundary current as APIs evolve.

• Record API purpose.
• Record product dependency.
• Record manufacturer responsibility.
• Record external dependencies.
• Record the RDPS conclusion.
• Record risk controls.
• Review after significant API changes.