The design phase is where CRA legal outcomes become architecture decisions. Teams should connect intended purpose, reasonably foreseeable use, operational environment and assets to be protected with security requirements, trust boundaries, interfaces, privileges, components and verification plans.
Article 13 Brings Cybersecurity Into Product Design
Article 13 requires manufacturers to ensure that products with digital elements are designed, developed and produced in accordance with the applicable essential cybersecurity requirements. It also requires the cybersecurity risk assessment to influence planning, design, development, production, delivery and maintenance. The design phase is therefore not merely preparation for later compliance testing. It is one of the stages in which the manufacturer is expected to translate identified cybersecurity risks into product decisions that can reduce the likelihood and impact of security problems.
- Bring the cybersecurity risk assessment into design review.
- Identify applicable Annex I outcomes.
- Translate legal outcomes into product architecture decisions.
- Define verification while the design is being created.
Start With Intended Purpose and Reasonably Foreseeable Use
Article 13 requires the cybersecurity risk assessment to analyse risks based on the intended purpose and reasonably foreseeable use of the product, as well as its conditions of use. Design teams therefore need a realistic description of how the product will be deployed, who will administer it, which other systems it will communicate with and what security assumptions are reasonable. Designing only for an ideal installation can leave the product exposed when foreseeable deployment patterns are different.
- Define intended purpose.
- Identify reasonably foreseeable use.
- Identify expected deployment environments.
- Identify administrative and user roles.
- Record important security assumptions.
Identify the Operational Environment and Assets to Be Protected
The CRA risk assessment expressly refers to conditions of use such as the operational environment and the assets to be protected. These factors should influence design. Assets can include credentials, configuration, personal or business data, cryptographic material, control functions, update mechanisms and availability of essential product functions. The operational environment can influence exposure to networks, physical access, administrator trust and dependencies on external services. A useful design record states which assets matter and which assumptions the architecture makes about its environment.
- Identify sensitive data and credentials.
- Identify security-critical functions.
- Identify availability requirements.
- Identify environmental trust assumptions.
- Identify external services and dependencies.
Map Annex I Outcomes Into the Architecture
Annex I Part I describes cybersecurity outcomes rather than one mandatory product architecture. Design teams therefore need to decide how the product will provide the applicable outcomes. Authentication can depend on product identity and user roles. Confidentiality can involve encryption and access controls. Integrity can involve signed updates, protected configuration or authenticated communications. Availability can require resilience or recovery mechanisms. Attack-surface limitation can affect exposed interfaces and enabled services. The cybersecurity risk assessment provides the context for deciding which controls are appropriate.
- Map each applicable Annex I outcome.
- Identify the architectural control that implements it.
- Identify the component responsible for that control.
- Identify assumptions and dependencies.
- Define how implementation will later be verified.
Design Trust Boundaries Deliberately
Trust boundaries identify where data, commands or identities move between components or actors with different levels of trust. Examples can include a device and cloud service, an unprivileged process and privileged service, a user interface and administrative interface, or an application and third-party component. These boundaries are useful design review points because they frequently require authentication, authorisation, input validation, confidentiality or integrity controls. Leaving trust boundaries implicit makes it harder to determine which component is responsible for enforcing security.
- Identify components operating at different trust levels.
- Identify data and command flows across boundaries.
- Define authentication and authorisation expectations.
- Define validation and protection requirements.
- Assign enforcement responsibility.
Limit Attack Surfaces During Architecture Design
Annex I Part I includes the requirement, where applicable, for products to be designed, developed and produced to limit attack surfaces, including external interfaces. This makes attack-surface reduction a direct design concern. Teams should question whether each exposed protocol, API, listening service, remote-management function, debug interface or privileged operation is genuinely necessary. Removing unnecessary exposure during architecture is usually more reliable than attempting to compensate later with filters or operational instructions.
- Inventory external interfaces.
- Review listening network services.
- Review remote-management functions.
- Review privileged operations.
- Remove unnecessary exposure where possible.
Third-Party Components Are Also a Design Decision
Article 13 requires due diligence when integrating third-party components so that they do not compromise product cybersecurity. Component selection is therefore not only a procurement or later vulnerability-management activity. Design teams should consider what privilege a component receives, which interfaces it exposes, how it will be updated, whether it is maintainable and what happens if support ends. Architectural isolation can sometimes reduce the consequences of a component vulnerability even when the vulnerability cannot be prevented completely.
- Evaluate component security implications.
- Limit unnecessary component privilege.
- Plan component update mechanisms.
- Consider maintenance and support expectations.
- Use isolation where it reduces risk.
Design Security Failure Behaviour
Products can fail securely or fail into a more dangerous state. Design review should consider what happens when authentication services fail, connectivity is lost, certificates expire, updates are interrupted, configuration becomes corrupt or dependent services are unavailable. The correct behaviour depends on the product and potential consequences. The design decision should nevertheless be explicit so that implementation and testing teams know which security properties need to survive abnormal conditions.
- Identify important failure scenarios.
- Define safe fallback behaviour.
- Protect essential security properties during failure.
- Avoid accidental privilege escalation during recovery.
- Include failure behaviour in verification plans.
Define Security Verification Before Implementation Ends
A security requirement is stronger when the design team already knows how it will be verified. Authentication requirements can have access-control tests. Update-integrity requirements can have signature and tampering tests. Attack-surface requirements can have interface inventories and network checks. Threat mitigations can have targeted security tests. Planning this evidence during design helps reveal requirements that are too vague to test and reduces the risk of reaching release without a defensible way to demonstrate that the architecture works as intended.
- Attach verification criteria to security requirements.
- Identify automated and manual tests.
- Identify evidence expected from architecture review.
- Plan targeted tests for important threat mitigations.
- Keep verification traceable to product versions.
Maintain Design Evidence for the Technical Documentation
Design evidence can include architecture diagrams, interface inventories, trust-boundary records, security requirements, threat models, design-review findings, component decisions and verification plans. Annex VII technical documentation requires information needed to assess conformity with the applicable essential cybersecurity requirements. Product teams should therefore preserve enough design reasoning to show how identified cybersecurity risks influenced the product instead of attempting to reconstruct those decisions after development is complete.
- Architecture and data-flow diagrams.
- Security requirement mapping.
- Trust-boundary documentation.
- Threat-model records.
- Design-review decisions.
- Verification plans.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.