Secure by design is one of the core principles of the Cyber Resilience Act. It forms the foundation of how manufacturers must design, develop and maintain products with digital elements that are placed on the EU market.
It is also the backbone of Annex I of the CRA, which defines the essential cybersecurity requirements that every covered product must meet.
This article explains what secure by design means in practice under the CRA, how Annex I shapes this obligation, and how the official FAQ clarifies several important nuances that are easy to miss.
Disclaimer: This content is provided for informational purposes only. The official text remains the authoritative reference.
What Secure by Design Means Under the CRA
Secure by design means that cybersecurity is built into a product from the very beginning, not added after development is finished.
Under the Cyber Resilience Act, this is not optional.
It is a legal requirement that influences architecture decisions, development practices, documentation, conformity assessment and CE marking.
A secure by design product is one that
- identifies cybersecurity risks early
- embeds appropriate security controls into its architecture
- limits attack opportunities by design
- anticipates foreseeable misuse
- considers the entire expected lifetime of the product
In short, secure by design means the product starts secure rather than being made secure later.
How the CRA Defines Secure by Design: Annex I Requirements
Annex I of the Cyber Resilience Act provides the legal substance behind secure by design. It lists the essential cybersecurity requirements that products with digital elements must meet before they can be placed on the EU market and throughout their support period.
These requirements are risk based and technology neutral. The CRA does not mandate specific tools or technologies. Instead, the manufacturer must demonstrate through a cybersecurity risk assessment how the product design satisfies the applicable Annex I requirements.
Below is a structured overview of Annex I requirements that directly relate to secure by design, enriched with the clarifications provided in the official CRA FAQ.
Essential Cybersecurity Requirements Related to Secure by Design
Before a product with digital elements is placed on the EU market, it must satisfy the following security properties.
Security aligned with a cybersecurity risk assessment
Manufacturers must perform a cybersecurity risk assessment for each product.
The FAQ clarifies that this assessment is the central reference point for secure by design. It determines
- which Annex I requirements apply
- how they are implemented
- how residual risks are justified
Secure by design under the CRA is demonstrated by showing that the product’s design decisions are proportionate to the identified risks.
No known exploitable vulnerabilities at release
A product may not be placed on the market if it contains known exploitable vulnerabilities at the time of release.
The FAQ adds two critical nuances here.
First, the CRA does not require products to be free from all vulnerabilities. The obligation is limited to vulnerabilities that are known and exploitable, assessed case by case.
Second, exploitable does not mean theoretical. It depends on real world conditions, including how the product is used, deployed and accessed. A vulnerability that requires unrealistic physical access or highly specific conditions may not be considered exploitable in practice.
This requirement links to sources such as the Open Intelligence database, but the final judgement always sits with the manufacturer’s risk assessment rather than a single dataset.
ScanDog smart prioritisation immediately surfaces actively exploited vulnerabilities and also makes clear the distinction of whether it can be exploited in your specific implementation.
Secure by default configuration
Products must be delivered with secure default settings.
This includes
- no insecure default credentials
- minimal exposed services
- security relevant options enabled without user intervention
- the ability for the user to return the product to a secure default state
The FAQ adds useful examples. A cryptographic library should have deprecated algorithms disabled by default. A hardware or software component should ship with unnecessary network interfaces disabled unless explicitly required.
For components intended for integration, secure by default applies to the component itself, while the system integrator remains responsible for the final configuration.
Minimisation of attack surface
Products must reduce their attack surface by design.
This includes
- removing unnecessary components
- limiting exposed interfaces
- avoiding unused features
- applying measures that make exploitation harder
The CRA expects manufacturers to justify why each exposed function or interface is necessary for the intended purpose of the product.
Protection of confidentiality
Products must protect sensitive data against unauthorised disclosure.
This includes
- encryption of sensitive data
- confidentiality during transmission and storage
- appropriate access controls
The level of protection must again be aligned with the cybersecurity risk assessment.
Protection of integrity
Products must protect against unauthorised modification.
This includes
- integrity of commands
- integrity of configuration
- integrity of stored and processed data
- early detection of tampering or corruption
Integrity protections are a core part of secure by design because they limit the impact of both accidental faults and deliberate attacks.
Protection of availability
Essential product functions must remain available and resilient.
The CRA expects products to withstand reasonable attack scenarios and to fail in a safe state when disruption occurs. Availability protections should be proportionate to the intended use and risk profile of the product.
Secure update mechanisms
Products must support security updates throughout the support period.
Annex I requires:
- mechanisms for delivering security updates
- authentication of updates
- informing users about available updates
- automatic installation of security updates enabled by default where applicable
- the ability for users to temporarily postpone updates
The FAQ clarifies that automatic updates are not universally mandatory. In professional, industrial or integrated environments where automatic updates are not appropriate, manufacturers must still inform users about vulnerabilities and make security updates available without undue delay.
Where technically feasible, security updates should be separable from functionality updates, although the FAQ recognises that this is not always possible.
Data minimisation
Products must only collect and process data that is necessary for their intended purpose.
This requirement directly supports secure by design by reducing exposure and limiting the impact of potential breaches.
Security monitoring and logging
Products must be capable of recording security relevant events.
The CRA requires
- logging of relevant internal activity
- transparency toward the user
- an option for the user to opt out
Logging supports both detection of attacks and effective vulnerability handling.
Secure deletion of data
Products must allow users to permanently and securely delete personal or sensitive data and reset the product.
This applies to both software and hardware products and supports safe decommissioning.
The Role of the Cybersecurity Risk Assessment
Secure by design under the CRA is anchored in the cybersecurity risk assessment.
This assessment must
- identify product specific risks
- determine which Annex I requirements apply
- document how design decisions address those requirements
- be kept up to date throughout the support period
The resulting documentation becomes part of the technical file used for CE marking and market surveillance.
Secure by Design Does Not End at Release
Secure by design continues after a product is placed on the market.
Annex I Part II defines vulnerability handling requirements that apply for the entire support period.
Manufacturers must
- monitor the product after release
- identify and analyse vulnerabilities
- provide timely security updates
- maintain a coordinated vulnerability disclosure process
- support users with corrective actions
In practice, secure by design evolves into secure by maintenance once customers start using the product.
Practical Examples of Secure by Design
While the CRA does not mandate specific techniques, it expects practices such as
- secure coding practices
- threat modelling during design
- dependency analysis to remove unnecessary third party components
- encryption of sensitive data
- strong input validation
- architectural isolation of critical components
- removal of debug features before release
- continuous hardening during development
These measures reduce risk long before compliance checks begin.
Why Secure by Design Matters for CRA Compliance
Secure by design is not a single checklist item.
It influences
- technical documentation
- risk assessment
- conformity assessment
- CE marking
- update policies
- vulnerability handling processes
A product that is not secure by design cannot meet the essential cybersecurity requirements of the CRA.
It also delivers long term operational benefits. Products designed securely generate fewer vulnerabilities, fewer incidents and fewer legally mandated reports once CRA reporting obligations begin in September 2026.
How ScanDog Helps Teams Achieve Secure by Design
Secure by design becomes practical when teams can
- understand their full dependency graph
- identify known exploited vulnerabilities early
- continuously assess risk
- reduce attack surface
- generate CRA ready documentation
- monitor products throughout the support period
ScanDog supports these needs by mapping software composition, identifying exploited vulnerabilities from open intelligence sources and helping teams make secure design decisions earlier in the development lifecycle.
ScanDog is an AI-powered Application Security Posture Management (ASPM) platform that helps development teams build secure software faster. With advanced vulnerability prioritization, reachability analysis, and AI-assisted remediation, ScanDog cuts through the noise of false positives to focus on what truly matters.