CRA Secure Development Requirements: What Annex I Section 1 Means for Your Team

Annex I of the EU Cyber Resilience Act is where the regulation gets concrete. Section 1 lists the essential cybersecurity requirements that every product with digital elements must meet before it can carry a CE mark and be placed on the EU market. If you are an engineering lead, security architect, or product owner, this is the section you need to internalize.

This guide breaks down each requirement in Annex I Section 1 of Regulation 2024/2847, explains what it means in practice, and gives you actionable steps to implement it.

The Overarching Principle: Security by Design

The CRA does not prescribe specific technologies or frameworks. Instead, it mandates that products be designed, developed, and produced to ensure an appropriate level of cybersecurity based on the risks. This is a risk-based approach — the security measures must be proportionate to the threat landscape and the product's intended use.

This means your team needs to perform a risk assessment before writing a single line of code. Threat modeling is not optional under the CRA. Document the threats your product faces, the attack vectors, and the mitigations you have chosen. This documentation forms part of your technical documentation package.

Requirement 1: No Known Exploitable Vulnerabilities

Products must be delivered without known exploitable vulnerabilities. This does not mean zero vulnerabilities — it means you must have a process to identify vulnerabilities before release and address them. In practice, this requires:

• Maintaining a Software Bill of Materials and monitoring it against vulnerability databases
• Running static analysis (SAST) and dynamic analysis (DAST) as part of your CI/CD pipeline
• Performing dependency audits before every release
• Tracking and remediating known CVEs in your components using automated vulnerability monitoring

If a vulnerability is discovered after release, you must provide security updates — which brings us to the next requirement.

Requirement 2: Secure Default Configuration

Products must be delivered with secure default settings. Users should not need to configure security — it should work out of the box. This includes:

• No default passwords. If credentials are required, force the user to set them during first use.
• Encryption enabled by default for data in transit and at rest where applicable.
• Unnecessary ports and services disabled by default.
• Least-privilege access as the default for all user roles.
• Automatic security updates enabled by default (users may opt out, but the default must be on).

Audit your current product defaults. If any feature ships in an insecure state that relies on the user to harden it, that is a CRA compliance gap.

Requirement 3: Protection Against Unauthorized Access

Products must protect against unauthorized access through appropriate authentication and identity management mechanisms. Depending on the product, this may require:

• Strong authentication mechanisms (multi-factor authentication where appropriate)
• Session management with proper timeout and revocation
• Role-based access control (RBAC) or attribute-based access control (ABAC)
• Audit logging of authentication events and access attempts
• Protection against brute force attacks (rate limiting, account lockout)

For products classified as Important or Critical, the access control requirements are more stringent and may be scrutinized during third-party conformity assessment.

Requirement 4: Data Confidentiality and Integrity

Products must protect the confidentiality and integrity of stored, transmitted, and processed data. This overlaps significantly with GDPR requirements for personal data, but the CRA applies to all data, not just personal data. Implementation includes:

• TLS 1.2 or higher for all network communications
• Encryption at rest for sensitive data stores
• Integrity verification for firmware and software updates (code signing)
• Secure key management practices
• Protection against data exfiltration through proper egress controls

Requirement 5: Attack Surface Minimization

Products must minimize their attack surface. Every exposed interface, protocol, and service is a potential entry point. The CRA requires manufacturers to reduce unnecessary exposure:

• Remove or disable unused features, APIs, and services
• Minimize the number of open ports and network interfaces
• Apply the principle of least functionality — the product should only include what is necessary for its intended purpose
• Regularly review and prune the attack surface as the product evolves
• Document all external interfaces and their security controls

This requirement connects directly to your supply chain security practices — every third-party component you include expands your attack surface.

Requirement 6: Impact Minimization of Security Incidents

When a security incident occurs, the product must minimize its impact. This is about resilience and containment:

• Implement proper error handling that does not leak sensitive information
• Design for graceful degradation under attack
• Include monitoring and logging capabilities so incidents can be detected and investigated
• Support incident response through diagnostic interfaces and forensic data preservation
• Implement network segmentation and isolation where applicable

Requirement 7: Security Updates

Manufacturers must provide security updates throughout the product's support period. Updates must be:

• Delivered in a timely manner after vulnerability discovery
• Free of charge for security fixes
• Distributed through a secure mechanism (signed packages, authenticated channels)
• Accompanied by advisories describing the vulnerability and the fix

The support period must be documented and communicated to users. For IoT devices and connected products, this includes over-the-air (OTA) update capability.

Putting It All Together: A Practical Implementation Plan

Do not try to address all requirements simultaneously. Prioritize based on risk and deadline:

1. Start with your SBOM and vulnerability monitoring. This addresses Requirement 1 and prepares you for ENISA reporting by September 2026.
2. Audit your default configurations. Review every setting that ships with your product and document secure defaults.
3. Implement threat modeling. If your team does not already perform threat modeling, start now. It informs every other requirement.
4. Review access controls. Map your authentication and authorization mechanisms against CRA requirements.
5. Document everything. The CRA requires you to demonstrate compliance through technical documentation. If you did not document it, you cannot prove it.

For a complete timeline, see our CRA compliance checklist. To assess your current readiness, run cra-scanner against your project.

Complaro helps engineering teams track their CRA compliance across all Annex I requirements — from SBOM management to vulnerability monitoring to ENISA reporting. Get started free.