Secure by design means security influences what the product is and how it is built, rather than being added mainly through hardening and patches after implementation. For CRA readiness, the cybersecurity risk assessment should influence architecture and product decisions early enough that risks can be reduced structurally.
Secure by Design Is an Implementation Principle
The phrase secure by design is widely used in current CRA implementation guidance, including ENISA's Secure by Design and Default Playbook. The operative Regulation itself does not create a separately labelled Annex I requirement called secure by design. Instead, Article 13 requires manufacturers to design, develop and produce products in accordance with Annex I and to use the cybersecurity risk assessment throughout planning, design, development, production, delivery and maintenance. Secure by design is therefore a useful way to describe how those legal obligations should influence engineering before release.
- Treat secure by design as an engineering principle grounded in CRA obligations.
- Do not present it as a separately numbered Annex I requirement.
- Use Article 13 and Annex I as the legal basis.
- Use current ENISA guidance for practical implementation.
Security Starts With Product Requirements
Security architecture is constrained by product requirements. If authentication, secure updating, separation of privileges, logging or confidentiality are considered only after major product decisions have been fixed, teams can be forced into expensive or fragile retrofits. Secure by design brings cybersecurity requirements into the same process as functional, performance and safety requirements. The cybersecurity risk assessment identifies the risks that need treatment, while the requirements record defines the product behaviour expected to control those risks.
- Identify security-relevant product behaviour.
- Translate risk findings into engineering requirements.
- Assign requirement ownership.
- Define how each requirement will be verified.
Architecture Can Remove Risks Before Code Exists
Some of the strongest security decisions are architectural. A product may reduce risk by separating privilege domains, narrowing trust boundaries, removing unnecessary network exposure, limiting administrative interfaces, isolating sensitive components or avoiding collection of unnecessary data. These choices can eliminate attack paths rather than merely attempting to detect exploitation later. Secure-by-design review should therefore happen while architecture can still be changed without destabilising the product.
- Identify trust boundaries.
- Review privilege boundaries.
- Review external and internal interfaces.
- Minimise unnecessary attack surface.
- Reduce unnecessary sensitive-data processing.
Threat Modelling Connects Risks to Architecture
The CRA does not mandate one named threat-modelling framework, but threat modelling is a practical way to connect the Article 13 cybersecurity risk assessment to engineering. Teams can identify assets, entry points, trust boundaries, attacker capabilities, misuse scenarios and potential security consequences, then evaluate whether the architecture provides adequate controls. The method can be lightweight or detailed depending on the product and risks. What matters for CRA readiness is that important cybersecurity risks are understood early enough to influence design.
- Identify assets and security objectives.
- Identify trust boundaries and entry points.
- Identify credible attack scenarios.
- Map controls to relevant threats.
- Record unresolved design risks.
Secure by Design Reduces Dependence on User Hardening
A product whose architecture creates unnecessary exposure cannot be made genuinely secure merely by adding a long hardening guide. Secure by design aims to remove or constrain risky behaviour at the product level. Secure by default then complements that design by ensuring the product's starting configuration does not unnecessarily weaken those protections. The principles are related but distinct: secure by design influences the architecture and functionality, while secure by default focuses on the initial configuration and behaviour users receive.
- Remove unnecessary risky functionality where possible.
- Design safe privilege boundaries.
- Limit exposed interfaces.
- Use secure defaults to preserve the intended security architecture.
- Do not transfer avoidable product-security work to users.
Security Testing Does Not Replace Secure Design
Security testing is essential for verifying implementation, but testing occurs after at least some design decisions already exist. A penetration test can reveal an exposed administrative function, but removing that function late may be much more difficult than deciding during architecture that it should never be remotely exposed. Secure by design therefore treats testing as evidence that design and implementation controls work, not as the primary mechanism for discovering what the security architecture should have been.
- Use testing to verify security assumptions.
- Do not rely on penetration testing as the first architecture review.
- Resolve structural risks during design where possible.
- Feed test findings back into future design decisions.
Product Changes Should Trigger Security Reassessment
Secure design is not a one-time launch activity. New interfaces, cloud integrations, authentication methods, dependencies, remote-management features or deployment models can change trust boundaries and attack paths. Article 13's lifecycle approach means manufacturers should consider whether significant product changes alter the cybersecurity risk assessment or the controls derived from it. Design review should therefore be triggered by security-relevant changes rather than occurring only for the original product architecture.
- Identify security-relevant change triggers.
- Review changed trust boundaries.
- Review new privileges and interfaces.
- Update risk and threat analysis where necessary.
- Update verification plans and evidence.
Secure-by-Design Evidence Should Be Traceable
Useful evidence can include cybersecurity risk assessments, security requirements, architecture diagrams, trust-boundary documentation, threat models, design-review decisions and records showing how important risks were treated. Evidence should explain why the implemented architecture is appropriate for the product rather than merely showing that a meeting took place. Connecting each major security decision to a risk, requirement and verification activity makes the development process much easier to demonstrate later during conformity preparation.
- Cybersecurity risk assessment.
- Security requirements.
- Architecture security decisions.
- Threat-model records.
- Design-review findings.
- Verification traceability.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.