Security design documentation is the bridge between the CRA cybersecurity risk assessment and implementation evidence. It should explain what security outcome is required, which component or process implements it, why the selected design is appropriate, what assumptions the design depends on and how the manufacturer will verify that the control works.
Security Design Documentation Is a Practical Evidence Layer
The CRA does not prescribe a separately titled document called security design documentation. Article 31 nevertheless requires relevant details of the means used to ensure Annex I compliance, while Annex VII requires necessary design and development information. Manufacturers can therefore use security design records as a practical evidence layer connecting the Article 13 risk assessment, Annex I requirements, system architecture and technical implementation. The format can be adapted to the product as long as the resulting documentation supports traceability.
- Do not present one document template as CRA-mandated.
- Connect risk assessment to design.
- Connect Annex I requirements to controls.
- Record important technical rationale.
- Connect design controls to verification.
Start With Security Requirements
A security design should begin with explicit security requirements derived from the cybersecurity risk assessment and applicable Annex I requirements. Requirements should describe the intended security outcome rather than immediately locking the product into one technology. For example, protect administrative functions from unauthorised access is a requirement, while a particular authentication protocol is one possible implementation. Separating outcome and mechanism makes design reasoning easier to review.
- Requirement identifier.
- Risk source.
- Annex I reference.
- Required security outcome.
- Affected product component.
Connect Security Requirements to Architecture
Security requirements should identify where in the architecture they are implemented. Authentication can terminate at a management service. Cryptographic verification can occur in a bootloader or update agent. Rate limiting can operate at an API gateway. Data-deletion behaviour can span local and remote services. The design record should reference architecture components consistently so that security requirements, implementation and tests describe the same product structure.
- Use stable architecture identifiers.
- Identify implementing components.
- Identify trust boundaries.
- Identify external dependencies.
- Identify cross-component controls.
Document Authentication and Access-Control Design
Where Annex I protection from unauthorised access is applicable, document the identity, authentication and authorisation model relevant to the product. Identify user and administrator roles, privileged operations, authentication boundaries, credential handling and access decisions. The design should explain the security outcome rather than relying on a statement that access control exists. Important fallback, recovery and service-access paths should also be considered because alternate paths can bypass the main authentication flow.
- Identity model.
- Authentication mechanisms.
- Authorisation model.
- Administrative privileges.
- Credential handling.
- Recovery and service access.
Document Secure-Default Decisions
Secure-by-default design choices can include disabled unnecessary services, initial credential requirements, automatic security-update settings, minimum access permissions and safe network exposure. The design record should identify which defaults carry security significance and why they were chosen. Where a user can weaken a default, document the expected control, warning or consequence. This helps distinguish deliberate product design from accidental deployment defaults inherited from a framework or operating system.
- Default enabled services.
- Default account and credential state.
- Default permissions.
- Default update behaviour.
- Default network exposure.
- Security-relevant user overrides.
Document Confidentiality and Cryptographic Design
Where confidentiality controls are needed, document which data require protection, where they are stored or transmitted and which mechanisms provide that protection. If encryption is used, record the relevant boundaries, key-management model and important dependencies. Avoid reducing the design record to algorithm names. Security depends on key storage, identity, protocol configuration, certificate validation and error behaviour as well as the cryptographic primitive itself.
- Protected data categories.
- Protection at rest.
- Protection in transit.
- Key-management design.
- Certificate or trust management.
- Relevant cryptographic dependencies.
Document Integrity Controls
Integrity design can cover software, firmware, configuration, commands, stored data and transmitted data. Record where signatures, authenticated protocols, integrity checks, secure boot, code signing or protected configuration are used and which threat they address. Identify how verification failures are handled because a product that detects invalid software but continues to execute it has not achieved the intended integrity outcome.
- Software and firmware integrity.
- Configuration integrity.
- Command integrity.
- Data integrity.
- Verification-failure behaviour.
Document Availability and Resilience Design
Security design should identify controls used to preserve essential and basic functions against relevant cybersecurity disruption. These can include resource limits, queue management, failover, isolation, graceful degradation, retry controls and recovery mechanisms. Document the functions being protected, the failure or attack conditions considered and the intended degraded or recovery state. This gives later resilience testing a defined expected result.
- Essential functions.
- Resource controls.
- Failure isolation.
- Graceful degradation.
- Recovery design.
- External dependency behaviour.
Document Attack-Surface Decisions
Attack-surface design should explain which interfaces and services are necessary and which are removed, disabled or restricted. Record decisions involving administrative interfaces, debugging functionality, local ports, APIs, plugins and optional services. Where exposure is required, identify compensating controls such as authentication, network restriction or isolation. The architecture inventory can show what exists, while the security design record explains why the exposed surface is considered appropriate.
- Required external interfaces.
- Disabled or removed services.
- Administrative exposure.
- Debugging restrictions.
- Plugin and extension controls.
- Compensating controls.
Document Exploitation-Mitigation Design
Where relevant, document controls designed to limit consequences if prevention fails. These can include least privilege, process isolation, sandboxing, privilege separation, memory protections, service segmentation and restricted credential access. Identify which attack scenarios the controls are intended to contain. This helps distinguish attack-surface reduction from post-exploitation containment and gives penetration or adversarial testing clear boundaries to verify.
- Least privilege.
- Process isolation.
- Sandboxing.
- Service segmentation.
- Credential isolation.
- Platform exploit mitigations.
Document Logging and Monitoring Design
Security design should identify important security events, event sources, storage or forwarding paths and the mechanisms used to provide security-related information. Record how log confidentiality and integrity are protected and how relevant user controls affect logging or monitoring. Detection design should identify the security condition being detected rather than merely state that logs are collected.
- Security event sources.
- Important event fields.
- Log storage or forwarding.
- Monitoring and detection logic.
- Log protection.
- Applicable user controls.
Document Security Update Design
Update architecture deserves dedicated design evidence because it is both a security control and a privileged code-delivery path. Document how updates are identified, authenticated, verified, distributed, installed and recovered from failure. Where automatic security updates apply, record default behaviour, user controls and postponement. Identify signing-key protection and package-verification behaviour. These design records support both Part I and Part II Annex I requirements.
- Update discovery.
- Package authenticity.
- Package integrity.
- Signing-key protection.
- Installation and rollback.
- Automatic-update behaviour.
Document Data Removal and Decommissioning Design
Where applicable, record how product data, settings, credentials and security relationships are securely removed. Identify local and remote storage, cloud dependencies, reset behaviour, key destruction and ownership-transfer behaviour. Security design should make clear when a reset differs from permanent removal and how the implementation meets the intended Annex I outcome.
- Local data removal.
- Remote data removal.
- Credential cleanup.
- Key removal.
- Reset behaviour.
- Ownership transfer.
Record Important Security Assumptions
A security design often depends on assumptions about the operating system, network, administrator, hardware, cloud provider or connected environment. These assumptions should be explicit. If a control is effective only when an external identity provider enforces multi-factor authentication or when a network is segmented, record that dependency. Hidden assumptions are difficult to reassess when deployment conditions change.
- Platform assumptions.
- Network assumptions.
- Administrator assumptions.
- Physical security assumptions.
- External service assumptions.
Record Security Design Rationale
Material security decisions should include enough rationale to explain why a design was selected. The rationale can reference identified risks, relevant Annex I outcomes, product constraints, state-of-the-art techniques, compatibility or operational requirements. Not every implementation detail requires a design essay. Focus deeper documentation on decisions whose failure would materially change the product's cybersecurity posture.
- Risk addressed.
- Annex I outcome.
- Selected solution.
- Relevant alternatives.
- Security trade-off.
- Residual assumption.
Link Security Design to Verification
Every significant design control should have a verification method. Authentication design can map to access-control tests. Update verification can map to malicious-package tests. Isolation design can map to privilege and containment testing. Resilience controls can map to resource-exhaustion tests. This mapping prevents security testing from becoming a generic activity disconnected from the design decisions it is supposed to validate.
- Control identifier.
- Verification method.
- Expected result.
- Test environment.
- Evidence reference.
A Practical CRA Security Design Record
A practical security design record can identify the security requirement, source risk, Annex I reference, architecture component, selected control, technical rationale, assumptions, dependencies, implementation owner, verification method and evidence location. The CRA does not prescribe this exact template. Its purpose is to demonstrate how the Article 13 risk assessment and Annex I requirements influenced the technical design that appears in the Article 31 documentation.
- Security requirement.
- Risk reference.
- Annex I mapping.
- Architecture component.
- Selected control.
- Design rationale.
- Assumptions.
- Verification method.
- Evidence location.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.