Article 5 is the pivotal compliance provision of the CRA: it requires manufacturers to ensure their products with digital elements satisfy the essential requirements set out in Annex I. Annex I is divided into two parts — Part I covers the security properties products must have at the point of design and manufacture, and Part II covers the vulnerability handling processes manufacturers must maintain after placing products on the market. Compliance with Article 5 is the condition for bearing the CE marking and accessing the EU single market.
The Two-Part Structure of Essential Requirements
Article 5 requires manufacturers to ensure their products comply with the essential cybersecurity requirements in Annex I. Those requirements are organised into two distinct parts, each addressing a different phase of the product lifecycle.
Annex I Part I deals with security properties that must be built into the product before it is placed on the market. These include requirements around no known exploitable vulnerabilities, secure default configurations, minimal attack surface, protection of data at rest and in transit, confidentiality, integrity, availability, access control, and the ability to update securely.
Annex I Part II deals with vulnerability handling processes that manufacturers must maintain throughout the product's supported lifetime. These include the obligation to identify and document vulnerabilities, establish a CVD policy, provide security updates, publish security advisories, and report severe vulnerabilities to ENISA through national CSIRTs.
Meeting both sets of requirements is necessary for CRA compliance — a product with excellent security properties but no vulnerability management process is not compliant.
Security by Design: Annex I Part I Requirements
The Annex I Part I requirements represent a codification of secure development best practices into legally binding obligations. Key requirements include:
No known exploitable vulnerabilities: Products must be placed on the market without known exploitable vulnerabilities in their components. This has significant implications for supply chain management — manufacturers must assess the security of third-party components, including open-source libraries, before integration.
Secure default configuration: Products must be delivered with secure default settings. Insecure defaults (such as blank administrator passwords or open network ports) that users must manually harden are not acceptable.
Minimal attack surface: Products must minimise their attack surface, exposing only the network interfaces and services genuinely necessary for operation.
Data protection: Products must protect data at rest and in transit using appropriate cryptographic mechanisms. Sensitive authentication credentials must not be transmitted in cleartext.
Software integrity: Products must be able to verify the integrity of updates and software components to prevent tampering.
Vulnerability Handling: Annex I Part II Requirements
Annex I Part II translates the post-market vulnerability management obligations into specific technical and procedural requirements. These are the operational backbone of ongoing CRA compliance and include:
Vulnerability identification: Manufacturers must identify and document vulnerabilities and components in their products, including by maintaining a Software Bill of Materials (SBOM).
Security updates: Manufacturers must address vulnerabilities through security updates provided free of charge to users, disseminated without undue delay and, where technically feasible, automatically.
CVD policy: Manufacturers must establish and maintain a coordinated vulnerability disclosure policy (see Article 13 for full requirements).
Security advisories: When a vulnerability is addressed or a workaround is available, manufacturers must publish a security advisory in a standard format. CSAF 2.0 is the recommended format.
Support period disclosure: Manufacturers must state the expected support period for their products, during which they commit to providing security updates.
Handling Third-Party Components and Dependencies
One of the most operationally challenging aspects of Article 5 compliance is the requirement that products be placed on the market without known exploitable vulnerabilities — including in third-party components and open-source dependencies. This creates a supply chain security obligation that extends beyond a manufacturer's own code.
Manufacturers must perform Software Composition Analysis (SCA) of their products to identify all components and their known vulnerabilities. Integrating a library with an unpatched critical vulnerability at the time of product release is likely to constitute an Annex I violation. Manufacturers should establish processes for:
- Inventorying all third-party components and their versions
- Monitoring CVE databases for new vulnerabilities in those components
- Updating or patching components prior to product release
- Maintaining an SBOM that can be provided to customers and regulators on request
The SBOM requirement in Annex I Part II also means that manufacturers must be able to produce an accurate component inventory on an ongoing basis, not just at product launch.
Proportionality and Risk-Based Application
Article 5 applies the essential requirements in a risk-proportionate manner. The CRA does not require perfection — it requires that manufacturers take appropriate measures commensurate with the risks associated with their specific product. A consumer smart plug and an industrial control system network gateway face different threat profiles and require different levels of security control.
Manufacturers must conduct a cybersecurity risk assessment for each product (documented in the technical file under Annex VII) and use this assessment to justify the security measures implemented. The risk assessment should consider the product's intended use, the likely user population, the sensitivity of data processed, and the potential impact of a security breach.
Harmonised standards published under Article 7 provide detailed, product-category-specific guidance on how to meet the essential requirements proportionately. Following an applicable harmonised standard creates a presumption of conformity with the corresponding essential requirements.
CVD Portal helps you comply with Article 5 automatically.
Public submission portal, 48-hour acknowledgment tracking, Article 14 deadline alerts, and CSAF advisory generation. Free forever.
Start your free portalFrequently asked
Does Article 5 require security testing of every product before market release?+
Article 5 does not mandate a specific testing methodology, but manufacturers must be able to demonstrate that essential requirements are met. In practice, security testing — including penetration testing, code review, and vulnerability scanning — is necessary to generate the evidence required for the technical file. Harmonised standards will specify appropriate testing approaches for different product categories.
What is an SBOM and is it legally required under the CRA?+
A Software Bill of Materials (SBOM) is a machine-readable inventory of all software components in a product, including open-source dependencies and their versions. Annex I Part II requires manufacturers to identify and document components in their products in a format that enables vulnerability monitoring. An SBOM is the standard implementation of this requirement and should be considered mandatory in practice.
How long must security updates be provided under Article 5?+
Manufacturers must provide security updates for at least five years from the date of placing the product on the market, or for the entire expected operational lifetime of the product if that lifetime is shorter than five years. The support period must be communicated to users clearly before purchase. Ceasing security updates before the stated support period ends is a violation.
Can I rely entirely on a third-party security component to meet Annex I Part I requirements?+
No. Article 5 places responsibility on the manufacturer of the final product for meeting all essential requirements. Using a certified third-party security component (such as a hardware security module) helps satisfy specific requirements, but the manufacturer must demonstrate that the overall product meets all applicable Annex I requirements. Responsibility cannot be fully delegated to a component supplier.
What constitutes a 'known exploitable vulnerability' under Annex I Part I?+
A vulnerability is generally considered 'known' if it appears in public vulnerability databases such as the NVD (National Vulnerability Database), CVE list, or ENISA's European Vulnerability Database. 'Exploitable' means there is a practical attack path that an adversary could use. Manufacturers should monitor these databases throughout the development cycle and before finalising a product release.
Related CRA Articles
Need a CVD policy that satisfies Article 5?
Download a free CRA-compliant template and deploy it in minutes.