CRA Essential Requirements 2026: The Annex I Security Checklist Every EU Product Must Pass

Post #8 in the sota.io EU Cyber Resilience Act Series

The Cyber Resilience Act (CRA) enters application in September 2026. For every software company selling into the EU, Annex I is the document that determines whether your product ships or gets blocked at the border. It contains 13 essential security requirements that are not optional, not best-practice suggestions — they are legal mandates backed by fines of up to €15 million or 2.5% of global annual turnover.

This guide breaks down every Annex I requirement, explains what implementation looks like in practice, and explains why your PaaS provider's jurisdiction matters when demonstrating compliance.

What Is a "Product with Digital Elements"?

Before diving into Annex I, you need to know whether the CRA applies to you at all. Article 3 defines a "product with digital elements" as any software or hardware product that:

• Connects directly or indirectly to a network (including the internet, local networks, or Bluetooth)
• Is placed on the EU market (sold to EU customers, even if your company is outside the EU)
• Is not excluded by sector-specific legislation covering the same security requirements (medical devices, aviation, automotive under UNECE WP.29)

This captures an enormous range of products: web applications, mobile apps, IoT devices, desktop software, APIs, and cloud services. If you have EU customers and your product touches a network, Annex I applies to you.

Key exclusion: Open-source software developed entirely outside of commercial activity is exempt. However, if you offer a commercially-supported open-source product (paid support, managed hosting, enterprise licenses), you are likely not exempt.

Annex I Part I: Security Requirements During Design

Part I of Annex I specifies requirements that must be built into the product itself — not bolted on afterward.

Requirement 1: No Default Insecure Configurations

Products must be designed with security as the default state. This means:

• No universal default passwords — devices and software cannot ship with shared credentials like admin/admin or root/password
• Minimal default services — only the services required for core functionality should be enabled by default
• Opt-in for risky features — telemetry, remote access, and debug modes must be disabled by default

Practical implication: Every configuration flag in your product that disables a security control must be documented as a deviation from the secure default, and you must be able to show why this is justified in your conformity documentation.

Requirement 2: No Known Exploitable Vulnerabilities

Products may only be placed on the market when there are no known exploitable vulnerabilities in the components you use. This is not a one-time check — it extends to the entire support lifecycle.

This requirement alone justifies an automated Software Composition Analysis (SCA) pipeline. You need continuous visibility into:

• All third-party dependencies and their vulnerability status
• The SBOM (Software Bill of Materials) for your product — addressed in our CRA SBOM Requirements post
• Which vulnerabilities are actually exploitable in your deployment context (VEX documents)

The CLOUD Act problem: If your CI/CD pipeline runs on a US-hosted platform (GitHub Actions, CircleCI, Jenkins on AWS), US law enforcement can obtain your vulnerability scan logs and dependency manifests during an active incident response — precisely when you are trying to assess whether a zero-day affects your product. EU-native CI/CD eliminates this confidentiality risk.

Requirement 3: Protect Confidentiality of Stored, Transmitted, and Processed Data

Products must implement appropriate technical measures to protect data:

• Encryption at rest for sensitive data stored by the product
• Encryption in transit for all network communications (minimum TLS 1.2, prefer TLS 1.3)
• Protection against unauthorized processing — access controls, authentication, authorization

This requirement directly intersects with GDPR Article 32 ("security of processing"). Products that handle personal data must satisfy both CRA Annex I and GDPR simultaneously.

Requirement 4: Protect Integrity of Stored, Transmitted, and Processed Data

Beyond confidentiality, products must ensure data integrity:

• Detection of unauthorized modification
• Signed software updates (code signing for binaries, signature verification before applying patches)
• Tamper-evident audit logs
• Protection against data corruption

Implementation note: This means your software update pipeline must implement cryptographic verification end-to-end. A product that downloads updates over HTTPS but without signature verification fails this requirement.

Requirement 5: Minimal Attack Surface

Products must minimize their attack surface by:

• Exposing only necessary interfaces and ports
• Disabling unused protocols and services
• Applying principle of least privilege to internal components
• Removing unnecessary functionality before distribution

This is the CRA codification of the security engineering principle of "defense in depth." In practical terms: your product should not bundle debug endpoints, management APIs, or admin interfaces that are only needed during development.

Requirement 6: Limit Impact of Security Incidents

Products must be designed to limit the blast radius of a successful attack:

• Compartmentalization — components should run with only the permissions they need
• Isolation — compromise of one component should not automatically compromise others
• Resource limitation — DoS resistance through rate limiting and circuit breakers

For cloud-native products, this maps directly to microservices isolation, Kubernetes RBAC, and network policies that prevent lateral movement.

Requirement 7: Availability of Security Updates

Products must provide mechanisms to receive and apply security updates:

• A defined update channel that reaches end users
• Documentation of the expected update lifecycle
• For IoT products: a way to update firmware that cannot be permanently disabled by the user

This requirement has teeth: if you abandon a product without security updates during the support period you declared, you are in violation of CRA. The support period must be at least 5 years from the date the product is placed on the market (or the expected product lifetime, whichever is shorter).

Requirement 8: Monitoring and Logging

Products must collect and retain sufficient security events:

• Authentication successes and failures
• Privilege escalation events
• Configuration changes
• Network connection attempts to/from unexpected endpoints

Critically, logs must be user-accessible — end users must be able to export and analyze security events from your product, not just your SRE team.

The CLOUD Act audit risk: If your product's logging infrastructure runs on AWS CloudWatch, Azure Monitor, or Google Cloud Logging, EU supervisory authorities asking for incident data could trigger a parallel US law enforcement inquiry. EU-native logging (Loki, OpenSearch on EU infrastructure) keeps your security telemetry under a single jurisdiction.

Requirement 9: Secure Authentication and Access Control

Products must implement strong authentication:

• Protection against unauthorized access (multi-factor authentication where appropriate)
• Secure credential storage (hashed passwords using modern KDFs like Argon2, bcrypt)
• Session management that limits the window of credential theft
• Protection against brute-force attacks

For B2B products handling sensitive data, MFA is effectively mandatory under this requirement.

Requirement 10: No Known Vulnerabilities in Dependencies

This requirement goes beyond Requirement 2 by specifically addressing the supply chain:

• Third-party libraries must be evaluated before integration
• The provenance of dependencies must be verifiable (checksums, signatures)
• Transitive dependencies (dependencies of dependencies) must be included in your vulnerability management

This is why an SBOM is not optional under the CRA — it is the technical artifact that demonstrates compliance with Requirements 2 and 10 simultaneously.

Requirement 11: Data Minimization

Products must only collect and process data that is strictly necessary for their function:

• Telemetry must be limited to what is required for the declared purpose
• Personal data collected for security purposes must not be used for other purposes
• Users must be informed of what data is collected

This aligns with GDPR Article 5(1)(c) data minimization principle. Under the CRA, it is now also a security requirement — unnecessary data collection is treated as a security risk, not just a privacy concern.

Requirement 12: Confidentiality and Integrity of Configuration

The product's security configuration must itself be protected:

• Configuration files must not be readable by unauthorized users
• Changes to security settings must be logged and attributable
• Security-critical configuration must be protected from tampering

Why this matters for PaaS customers: If you run your product on a US-headquartered cloud provider, configuration data including encryption keys, access credentials, and network policies are potentially subject to CLOUD Act disclosure requests. EU-native PaaS (like sota.io) ensures configuration data stays under EU jurisdiction.

Requirement 13: Security Controls Apply to Connected Components

If your product connects to external systems (APIs, databases, third-party services), you are responsible for ensuring those connections do not undermine your product's security posture:

• Third-party API integrations must use secure protocols and authentication
• External dependencies must be documented and assessed
• Data shared with third parties must be subject to appropriate contractual security requirements

This requirement makes your vendor selection a compliance decision. Using a US-headquartered analytics provider, error tracking service, or payment processor becomes part of your CRA conformity documentation.

Annex I Part II: Vulnerability Handling Requirements

Part II focuses on what happens after your product ships. These overlap with Articles 7, 10, 11, and 14 of the main CRA text (covered in detail in our previous posts in this series):

1. Identify and document vulnerabilities in the product and its components
2. Address vulnerabilities without delay — patch, workaround, or withdraw from market
3. Apply security patches promptly after vulnerabilities are confirmed
4. Disclose vulnerability information to users through a documented coordinated disclosure process
5. Report actively exploited vulnerabilities to ENISA within 24 hours of becoming aware
6. Maintain an SBOM for the lifecycle of the product
7. Provide security updates for the declared support period

For detailed treatment of these requirements, see:

• CRA Art.10: Vulnerability Reporting 2026
• CRA Art.11: Actively Exploited Vulnerabilities — 24h ENISA Notification
• CRA Art.14: Coordinated Vulnerability Disclosure
• CRA Art.7: Vulnerability Handling Requirements

The Conformity Assessment Process

To legally place a product on the EU market after September 2026, you must complete a conformity assessment and affix the CE marking. The pathway depends on your product category:

Class I (Default — Most Software Products)

Products in the default category can complete a self-assessment:

1. Document how each Annex I requirement is met in your product
2. Prepare a technical file (architecture documentation, risk assessment, test results)
3. Draft an EU Declaration of Conformity
4. Affix CE marking
5. Register with ENISA's vulnerability database

No third-party auditor is required for Class I, but the documentation must be comprehensive enough to satisfy a market surveillance authority if they investigate.

Class II (Critical Products — Requiring Third-Party Assessment)

High-criticality products listed in Annex III (operating systems, hypervisors, industrial control system software, VPNs, firewalls, PKI systems, industrial automation software) require:

• Assessment by a notified body (third-party conformity assessment organization)
• Or conformance with a harmonized European standard (when published)

Critical Products (Class III)

The highest-criticality products (hardware security modules, smart cards, microprocessors used in security-sensitive contexts, smart meter gateways) require European Cybersecurity Certification under ENISA's certification framework.

The EU-Native Hosting Advantage for Annex I Compliance

Demonstrating Annex I compliance involves producing documentation that will be reviewed by market surveillance authorities. Several requirements create a practical advantage for EU-native infrastructure:

Logging and Audit Trails (Requirement 8)

If your logs are on US infrastructure, a data subject access request or regulatory audit can trigger parallel disclosure risk. EU-native logging means your audit trail stays in one jurisdiction.

Vulnerability Management (Requirements 2 and 10)

Vulnerability scan results, dependency manifests, and SBOM data contain security-sensitive information. On US-hosted CI/CD, this data is subject to CLOUD Act. An EU-native CI/CD pipeline (Woodpecker CI, GitLab CI on EU servers) keeps vulnerability data under EU data protection law.

Configuration Security (Requirement 12)

Secrets management on US cloud providers (AWS Secrets Manager, Azure Key Vault) means your encryption keys and access credentials are legally accessible to US law enforcement under the CLOUD Act. EU-native secrets management (HashiCorp Vault on EU servers, or EU-jurisdiction KMS) eliminates this risk.

Incident Response (Part II Requirements)

When you have 24 hours to report an actively exploited vulnerability to ENISA, the last thing you need is uncertainty about who else has access to your incident data. EU-native hosting means your forensic artifacts, incident logs, and response communications stay in the EU.

Annex I Compliance Checklist

Use this checklist to assess your current status against each requirement:

Part I — Security Requirements:

Part II — Vulnerability Handling:

Timeline: What Applies When

September 2026 is 16 months away as of publication. For most software teams, the compliance work needed to satisfy Annex I takes 6–12 months when starting from scratch — especially building the documentation infrastructure (technical file, SBOM tooling, CVD policy, ENISA reporting runbook).

What sota.io Provides

For companies running their products on sota.io (EU-native PaaS, operated entirely within EU jurisdiction):

• EU-jurisdiction infrastructure — all compute, storage, and networking within the EU, no US-parent company
• No CLOUD Act exposure — your logs, configuration, and vulnerability data cannot be compelled by US law enforcement
• GDPR-compliant data processing — consistent with Annex I data protection requirements (Requirement 3, 11)
• Audit-ready logging — structured, exportable logs for Requirement 8 documentation
• Documentation support — we can provide infrastructure attestation letters for your technical file

The September 2026 deadline is real. Annex I compliance is achievable — but only if you start the documentation and infrastructure work now.

This post is part of the sota.io CRA series. See also: CRA Art.10 Vulnerability Reporting · CRA Art.13 Security by Design · CRA Penalty Framework · CRA SBOM Requirements