EU Cyber Resilience Act — Guide for Cloud & Backend Engineer

The CRA applies to products with digital elements — defined in Article 3 as hardware or software products that connect to a network, directly or indirectly. The backend services that a connected product relies on are within the scope of the manufacturer's obligations, even if those services run on third-party cloud infrastructure.

Key scoping questions for Cloud Engineers:

• Is the backend integral to the product's intended function? If yes, the backend must meet Annex I requirements as part of the product system
• Is the product a Software-as-a-Service? Pure SaaS may fall outside CRA scope, but embedded clients, firmware agents, or SDKs shipped as part of the SaaS are in scope
• Who is the manufacturer? Article 13 places obligations on the legal entity placing the product on the market — if your organisation both builds and operates the backend, it bears the full manufacturer obligation

Cloud Engineers should work with the compliance team to establish a clear scope boundary document identifying which backend components are within the CRA technical file.

Annex I Part I of the CRA requires products to protect the confidentiality and integrity of data in transit (§3), to minimise the attack surface (§2), and to authenticate users and devices appropriately (§6). For Cloud Engineers, these requirements translate directly into API design and authentication architecture.

Mandatory controls under a CRA-aligned API security standard:

• Mutual TLS (mTLS) or equivalent for device-to-backend communication on Class I and Class II products — shared API keys do not meet the authentication standard for regulated products
• Token expiry and rotation: access tokens must have short lifetimes; refresh token rotation must be enforced server-side
• Input validation at the API boundary: all inputs validated against a strict schema; reject-by-default approach to unexpected fields
• Rate limiting and abuse protection: denial-of-service resilience is an explicit Annex I requirement (§8)
• Audit logging: all authenticated API calls logged with timestamp, identity, and action — logs retained for the duration required by the technical file retention policy (Article 23: 10 years)

Annex I Part I §10 requires manufacturers to ensure the security of the software supply chain, including verifying the integrity of components obtained from third parties. For Cloud Engineers, this translates into pipeline and dependency management controls.

CI/CD pipeline integrity controls:

• Sign all build artefacts with a hardware-backed key; verify signatures before deployment to staging and production environments
• Pin dependency versions in lockfiles (package-lock.json, poetry.lock, go.sum) and enforce lockfile integrity checks in CI
• Scan all dependencies for known CVEs on every build using a vulnerability scanner integrated into the pipeline — fail builds with Critical or High severity findings that lack an accepted risk rationale
• Separate build, test, signing, and deployment stages with distinct IAM identities and minimal cross-stage permissions

Dependency governance:

• Maintain a dependency inventory updated on every build — this is the basis for the SBOM
• Review new direct dependencies for maintenance status, licence compatibility, and security posture before adoption
• Automate dependency update PRs with security patch prioritisation so that Annex I §12 (timely security update delivery) can be met

Article 13(6) requires manufacturers to identify and document components of products with digital elements. For backend services integral to a regulated product, this means producing a Software Bill of Materials (SBOM) in a machine-readable format.

SBOM requirements for backend services:

• Generate SBOMs in CycloneDX 1.5+ or SPDX 2.3+ format on every production build — embed generation in the CI/CD pipeline so the SBOM is always current
• Include all direct and transitive dependencies with name, version, package URL (PURL), and licence identifier
• Include container base images and OS packages if the backend is containerised — layer-aware SBOM tools produce this automatically
• Store versioned SBOMs alongside build artefacts in a content-addressed store; link each SBOM version to the corresponding deployment in the change management system
• Share SBOMs with the security team so that new CVE disclosures can be triaged against the current dependency graph without manual inventory checks

The SBOM for backend services should be referenced in the technical file alongside the SBOM for on-device firmware or software.

Practical first steps for Cloud Engineers building CRA compliance into backend services:

• Confirm scope: work with the compliance team to establish whether your backend services are integral to a regulated product and must be included in the technical file
• Audit authentication mechanisms: replace any shared API keys or static credentials with mTLS or short-lived tokens; document the decision in an ADR
• Add SBOM generation to CI/CD: integrate CycloneDX or SPDX SBOM generation into every build pipeline that produces a production artefact
• Enable dependency scanning: configure the CI pipeline to fail on unmitigated Critical and High CVEs in direct and transitive dependencies
• Review logging coverage: ensure all product-facing API calls are logged with sufficient detail to support an Article 14 incident report within 72 hours of a breach
• Run the CVD Portal CRA Readiness Score against your backend architecture to identify gaps against Annex I controls
• Connect with the PSIRT: ensure backend monitoring alerts are routed to the PSIRT triage queue so that server-side indicators of compromise trigger the Article 14 early-warning process