EU Cyber Resilience Act — Guide for Software Architect

Software Architects make decisions at the beginning of a product's life that determine its CRA compliance posture for the entire support period — which may extend a decade or more. Annex I Part I establishes essential requirements that software design must satisfy structurally, not just through post-hoc controls.

High-impact architectural decisions with Annex I implications:

• Language and memory safety (Annex I §1): memory-unsafe languages (C, C++) require additional architectural controls — memory-safe subsystem boundaries, use of bounds-checking libraries, or migration to memory-safe equivalents — to satisfy the exploitable vulnerability prohibition
• Privilege architecture (Annex I §4): the software must implement least-privilege principles; architectural decisions about process isolation, capability-based security, and inter-process communication boundaries must be documented
• Cryptographic agility (Annex I §3): hardcoding specific cipher suites creates future compliance risk as algorithms are deprecated; the architecture must support algorithm rotation without full stack changes
• Logging and auditability (Article 14 support): the architecture must support the rapid incident analysis required by Article 14's 72-hour notification timeline — this means structured, queryable logs from the first release

Each of these decisions should be captured in a dated Architecture Decision Record (ADR) cross-referencing the relevant Annex I provision.

Annex I §10 requires manufacturers to address the security of the software supply chain, including the integrity and security of third-party and open-source components. For Software Architects, this means establishing a dependency governance process that operates before components are adopted, not only after vulnerabilities are discovered.

Dependency selection criteria for CRA-regulated products:

• Maintenance status: prefer dependencies with active maintainers, recent release history, and a public security advisory channel — abandoned or unmaintained libraries create unresolvable Annex I §1 risk
• Vulnerability history: review the CVE history of candidate dependencies before adoption; a pattern of critical vulnerabilities signals structural security debt
• Licence compatibility: CRA does not mandate specific OSS licences, but copyleft licences may affect the ability to distribute security patches promptly
• SBOM availability: prefer upstream components that themselves publish SBOMs — this simplifies transitive dependency tracking
• Minimal transitive footprint: prefer dependencies with few transitive dependencies; each transitive dependency is an additional attack surface and SBOM entry

Document the dependency selection criteria as an architecture standard and include a record of the evaluation for significant new dependencies in the technical file.

Annex I §12 requires products with digital elements to support secure, authenticated software updates throughout their support period. This is an architectural requirement — systems that were not designed for updatability cannot be made updatable after the fact without significant rework.

Update architecture requirements under Annex I §12:

• Authenticated update channel: the update delivery mechanism must cryptographically verify the authenticity of update packages before installation — unsigned updates must be rejected
• Integrity verification: each update package must be verified against a cryptographic signature from a key held in a hardware-backed store, not a software keystore
• Rollback protection: the architecture must prevent downgrade attacks by tracking installed versions in tamper-resistant storage and rejecting packages with lower version numbers than the current installation
• Staged rollout capability: the update architecture should support canary deployments and staged rollouts to limit the blast radius of a defective update
• Offline update path: for products deployed in air-gapped or intermittently connected environments, design an authenticated offline update mechanism (e.g., signed update packages deliverable via USB or SD card)

The update architecture must be documented in the technical file, including the key management scheme and the rollback protection mechanism.

Annex I §3 requires products to protect the confidentiality and integrity of stored and transmitted data. For Software Architects, this translates into data classification, encryption standards, and key management architecture decisions that must be made explicitly rather than left to individual developers.

CRA-aligned data handling architecture includes:

• Data classification: define data categories (e.g., device credentials, user PII, telemetry) and specify the encryption and access control requirements for each class — document this as a data classification policy in the technical file
• Encryption at rest: sensitive data stored on-device must be encrypted using current NIST-recommended algorithms (AES-256-GCM or equivalent); document algorithm selection with rationale
• Encryption in transit: all network communication must use TLS 1.2 minimum, TLS 1.3 preferred; enforce certificate pinning for product-to-backend communication on high-risk products
• Key management architecture: specify where keys are generated, stored, rotated, and destroyed — keys used for product security functions must be stored in hardware-backed keystores, not application memory
• Data minimisation: only data necessary for the product's intended function should be collected and retained — excess data collection expands the confidentiality risk addressed by Annex I §3

Practical first steps for Software Architects building CRA compliance into their architecture programme:

• Audit the current architecture against Annex I Part I requirements — identify where controls are implemented but undocumented, and where structural gaps exist that require design changes
• Establish an ADR process with CRA Annex I cross-referencing as a mandatory field for all security-relevant architecture decisions
• Define the dependency governance policy: document the evaluation criteria for new dependencies and create a review record template for significant adoptions
• Review the update delivery architecture: confirm that update packages are signed, integrity-verified, and rollback-protected — if not, plan the remediation before CRA application date
• Define data classification and encryption standards: ensure encryption algorithm choices are documented with rationale and that key management is specified at the architecture level
• Generate an initial software SBOM: run SBOM tooling across the codebase to establish the baseline dependency inventory — identify any unmaintained or unpatched components
• Run the CVD Portal CRA Readiness Score to benchmark the architecture against Annex I and identify the highest-risk gaps to address first