EU Cyber Resilience Act — Guide for Security Architect

Annex I Part I of the CRA establishes the essential cybersecurity requirements that every product with digital elements must satisfy before it can bear the CE mark. Security Architects are the primary owners of these requirements within engineering organisations.

Key Annex I obligations with architectural implications include:

• No known exploitable vulnerabilities at time of market placement (Annex I §1) — requires a documented secure-SDLC with gated release criteria
• Minimal attack surface (Annex I §2) — drives decisions on exposed interfaces, protocols enabled by default, and privilege boundaries
• Confidentiality and integrity of data in transit and at rest (Annex I §3) — mandates cryptographic architecture decisions with documented algorithm selection rationale
• Least-privilege design (Annex I §4) — requires formal privilege decomposition documented in architecture artefacts
• Resilience against denial of service (Annex I §8) — necessitates rate-limiting, resource isolation, and graceful degradation patterns

Each architectural decision that addresses an Annex I requirement should be captured as a dated Architecture Decision Record (ADR) and cross-referenced in the technical file.

Article 13(1) of the CRA requires manufacturers to design, develop, and produce products in accordance with essential cybersecurity requirements, explicitly naming secure-by-design and secure-by-default as mandatory principles. This is not aspirational language — it is a conformity condition.

Secure-by-design architectural controls include:

• Defence-in-depth layering so that compromise of one component does not yield complete system access
• Cryptographic agility — designing systems to swap algorithms without architectural rework as standards evolve
• Memory-safe language selection or memory-safe subsystem boundaries when working with legacy languages
• Formal trust boundaries documented in data-flow diagrams and included in the technical file

Secure-by-default controls include:

• All interfaces disabled at factory reset except those strictly necessary for initial onboarding
• Strong, device-unique credentials with no shared default passwords (Annex I §6)
• Automatic update acceptance enabled by default with a documented opt-out mechanism
• Telemetry limited to what is necessary for security monitoring unless the user explicitly expands scope

The CRA does not prescribe a specific threat modelling methodology, but the requirement for manufacturers to assess cybersecurity risk (Article 13(2)) and maintain a technical file (Article 23, Annex V) means that threat modelling outputs must be formal, versioned, and retained for the product's support period.

A CRA-aligned threat modelling programme should:

• Use a structured methodology such as STRIDE, PASTA, or LINDDUN applied consistently across all product lines
• Produce data-flow diagrams (DFDs) at system, component, and interface level — these are expected artefacts in the technical file
• Document threats, their likelihood and impact, and the architectural controls chosen to mitigate each — mapping mitigations back to Annex I requirements
• Be repeated at every major architectural change and at least annually during the product's active support period
• Include supply chain components: third-party SDKs, open-source libraries, and hardware subsystems must appear in the threat model

Threat model reports should be signed off by the Security Architect and stored in the version control system alongside the codebase, ensuring traceability.

The CRA's technical file (Annex V) requires manufacturers to hold documentary evidence that products satisfy Annex I requirements. Architecture artefacts are a primary source of this evidence and must be structured to withstand scrutiny from a notified body or national market surveillance authority.

Conformity evidence that Security Architects own or contribute to:

• Architecture Decision Records (ADRs): dated records of significant security design decisions with rationale, alternatives considered, and the Annex I requirement addressed
• Data-flow diagrams and trust boundary maps: showing all entry points, data stores, and inter-component communication channels
• Threat model reports: per-release versions with a documented residual risk acceptance sign-off
• Cryptographic specification documents: specifying algorithms, key lengths, key management processes, and rotation schedules
• Interface specifications: enumerating all exposed network interfaces, protocols, and authentication mechanisms

Architects should establish a security architecture review gate in the product release process, producing a signed architecture review record that is added to the technical file before each market placement.

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

• Map your product portfolio against CRA scope — identify which products are Class I or Class II under Annex III and therefore require third-party conformity assessment
• Audit existing architecture documentation against Annex I Part I requirements — identify gaps where controls exist in implementation but are not documented
• Establish an ADR process with a standard template that includes CRA Annex I cross-references as a mandatory field
• Schedule initial threat modelling sessions for all in-scope products and block time for annual refreshes in the security calendar
• Define the secure-by-default baseline for each product class — document which interfaces are on/off at factory reset and why
• Run your architecture through the CVD Portal CRA Readiness Score to identify high-risk gaps before the notified body engagement
• Engage the PSIRT Lead to ensure your architecture supports rapid patch delivery within the timelines implied by Article 14 notification obligations