CRA Annex I explained — the 21 essential cybersecurity requirements

The Cyber Resilience Act (Regulation (EU) 2024/2847) introduces — for the first time in EU law — mandatory cybersecurity requirements for every product with digital elements sold in the European Union. The core of the obligation lives in Annex I, which lists 21 essential requirements: 13 design properties the product must have (Part I) and 8 vulnerability-handling processes the manufacturer must operate (Part II).

This article translates each of those 21 requirements into engineer-speak, explains the most common compliance failure mode for each, maps them to existing harmonised standards (notably EN 18031 and EN 303 645), and explains how conformity is demonstrated when CE-marking a product.

What CRA Annex I is and who it applies to

CRA Annex I is the operative core of the regulation. Article 6 of the CRA states that "products with digital elements shall be made available on the market only where they meet the essential cybersecurity requirements set out in Part I of Annex I, on condition that they are properly installed, maintained, used for their intended purpose or under conditions which can reasonably be foreseen". Article 13 imposes the parallel obligation to operate the processes in Part II throughout the support period.

A product with digital elements is defined in Article 3(1) as any software or hardware product and its remote data processing solutions. The scope is intentionally broad:

• Connected consumer electronics — smart speakers, wearables, smart home hubs, connected toys
• Industrial IoT and operational technology — sensors, controllers, gateways
• Network equipment — routers, switches, firewalls, access points
• Operating systems, hypervisors, and embedded firmware
• Microcontrollers and microprocessors with software stacks
• Pure software products — applications, libraries, SDKs (where placed on the market commercially)

The notable exclusions: medical devices regulated under MDR/IVDR, motor vehicles under the Type Approval Regulation 2018/858, maritime equipment, and aviation products — these fall under sector-specific cybersecurity regimes. Open-source software developed outside a commercial activity is also excluded under Article 2(5), with conditions.

Timeline and enforcement dates

Existing products on the market before 11 December 2027 are subject to the Article 13 vulnerability-handling obligations during their support period but do not need to retrospectively conform to Annex I Part I — that applies to products placed on the market after the cut-off.

How conformity with Annex I is demonstrated

The CRA uses the EU's New Legislative Framework (NLF) conformity-assessment modules. For an ordinary product with digital elements (not listed in Annex III or Annex IV), the manufacturer:

1. Performs a cybersecurity risk assessment against intended use and foreseeable misuse (Article 13).
2. Applies an applicable harmonised standard — when published in the Official Journal, this gives a presumption of conformity with the relevant Annex I requirements.
3. Issues a Declaration of Conformity (see DoC 101) citing the CRA and the harmonised standards applied.
4. Affixes the CE mark.
5. Maintains the Technical File and SBOM for ten years.

The principal harmonised standard under development is EN 18031 with three sub-parts:

• EN 18031-1 — security requirements for products with digital elements (mirrors Annex I Part I)
• EN 18031-2 — vulnerability handling requirements (mirrors Annex I Part II)
• EN 18031-3 — security requirements for the vulnerability disclosure process

Until EN 18031 is cited in the Official Journal, manufacturers either anticipate the standard, fall back to EN 303 645 (consumer IoT baseline, already in force) plus documented justification, or engage a Notified Body for Module B/C/D assessment.

For important products listed in Annex III (identity management, password managers, network management, firewalls, etc.), Class I requires either a harmonised standard or Notified Body Module B/C/H assessment. Class II always requires Notified Body involvement. For critical products in Annex IV (hardware security modules, smart meter gateways), the European Cybersecurity Certification Scheme applies.

Part I — the 13 design requirements explained

These are the properties the product itself must demonstrate at the moment it is placed on the market.

1. Appropriate level of cybersecurity by design

"Products with digital elements shall be designed, developed, and produced in such a way that they ensure an appropriate level of cybersecurity based on the risks."

The product's cybersecurity properties must be the output of a documented risk assessment proportional to intended use and foreseeable misuse. A connected industrial valve carries different risk than a connected toothbrush — both must be "appropriate" to their context, and both must show how that conclusion was reached. The risk assessment lives in the Technical File and is updated whenever the product or its threat model materially changes.

Common failure: shipping a connected device without any documented risk assessment, then improvising one when an auditor asks.

2. No known exploitable vulnerabilities at the moment of placing on the market

"Products with digital elements shall be made available on the market without any known exploitable vulnerabilities."

The SBOM (see Part II requirement 1) must be checked against the NVD, ENISA, and vendor advisory feeds immediately before release. Any component with a public CVE rated High or Critical and with a known exploit path must be patched, replaced, or formally mitigated before the CE mark is affixed.

Common failure: using a library version frozen six months earlier in the BSP without rechecking CVE status at release.

3. Secure-by-default configuration

"On the basis of a risk assessment […] delivered with a secure-by-default configuration, including the possibility to reset the product to its original state."

Out of the box: authentication required, no hard-coded credentials, encryption on by default, all non-essential services disabled, every port closed unless explicitly needed for first-use. The factory-reset path must restore the product to this state — not to an insecure shipping configuration.

Common failure: ship with telnet on port 23 enabled for "factory testing" and password "admin/admin".

4. Vulnerabilities addressed through security updates

"Ensure that vulnerabilities can be addressed through security updates, including, where applicable, through automatic security updates that are installed within an appropriate timeframe enabled as a default setting."

Default behaviour is automatic update install. Opt-out is permitted only with clear notification of the security consequences. Updates must be cryptographically signed, integrity-checked on download, and rollback-protected. Update mechanism failure modes (server unreachable, signature invalid) must not silently disable the update path.

Common failure: updates require user-initiated download from a web portal, with no automatic check or notification.

5. Protect against unauthorised access by appropriate control mechanisms

"Ensure protection from unauthorised access by appropriate control mechanisms, including but not limited to authentication, identity or access management systems, and report on possible unauthorised access."

Multi-factor authentication where the threat model warrants it; principle of least privilege for every account and API; brute-force protection with rate limiting and lockout; account creation must avoid default-credential anti-patterns. Failed authentication attempts must be logged (see requirement 13).

6. Protect confidentiality of stored, transmitted, and processed data

"Protect the confidentiality of stored, transmitted or otherwise processed data, personal or other, such as by encrypting relevant data at rest or in transit by state of the art mechanisms […]"

Encryption in transit: TLS 1.2+ minimum, TLS 1.3 preferred, modern ciphers only (no RC4, no DES, no MD5-based MACs). Encryption at rest: on user data, credentials, and any key material with appropriate scope. Key management documented in the Technical File.

7. Protect integrity of data, commands, programs, and configuration

"Protect the integrity of stored, transmitted or otherwise processed data, personal or other, commands, programs and configuration against any manipulation or modification not authorised by the user."

Cryptographic integrity checks on firmware (signed boot), on configuration files, on stored data the user relies on. The product must detect tampering and refuse to operate with a compromised image.

8. Process only data adequate, relevant, and limited to what is necessary

"Process only data, personal or other, that are adequate, relevant and limited to what is necessary in relation to the intended purpose of the product."

Annex I aligns with GDPR Article 5(1)(c) data minimisation. No telemetry beyond what the manufacturer has declared to the user and the regulator. Optional analytics: opt-in.

9. Protect availability of essential and basic functions

"Protect the availability of essential and basic functions, also after an incident, including through resilience and mitigation measures against denial-of-service attacks."

Essential functions (the product's primary purpose) must survive denial-of-service attempts and component failures with graceful degradation. A connected thermostat must continue to regulate temperature when the network is unreachable.

10. Minimise impact on other devices and networks

"Minimise the negative impact by the products themselves or connected devices on the availability of services provided by other devices or networks."

No amplification, no bandwidth flooding, no broadcast storms. Polite back-off when the network is congested. Particularly relevant for products that act as gateways or that bridge multiple networks.

11. Limit attack surfaces, including external interfaces

"Be designed, developed and produced to limit attack surfaces, including external interfaces."

Every unused port closed. Debug interfaces (JTAG, serial console, SWD) disabled or password-protected on production builds. Web interfaces stripped of test pages and example endpoints. API surface minimised to what the documented use cases require.

Common failure: leaving JTAG enabled on production silicon "for field debug" without any access control.

12. Reduce impact of an incident using exploitation mitigation

"Be designed, developed and produced to reduce the impact of an incident using appropriate exploitation mitigation mechanisms and techniques."

ASLR, stack canaries, W^X (write-XOR-execute) memory protection, sandboxing of untrusted parsers, secure-boot chain, isolation of sensitive operations in a TEE or HSM where the threat model warrants. The standard of practice from desktop and mobile carries to embedded.

13. Provide security-related information by recording internal activity

"Provide security related information by recording and monitoring relevant internal activity, including the access to or modification of data, services or functions, with an opt-out mechanism for the user."

A local security event log — authentication attempts, configuration changes, update history, anomalous access — retained on-device with a documented format. Optional remote forwarding for centralised SIEM integration. User must be able to opt out of any remote forwarding.

Part II — the 8 vulnerability-handling requirements explained

These are processes the manufacturer must operate throughout the support period — not properties of the product at any single moment.

1. Identify and document vulnerabilities and components — the SBOM

"Identify and document vulnerabilities and components contained in the product, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the product."

A Software Bill of Materials (SBOM) in CycloneDX or SPDX format, maintained per release, made available to authorities on request. The SBOM is the input to all subsequent monitoring and patching obligations.

Common failure: SBOM generated once at the first release and never updated. CRA requires it to track each version.

2. Address and remediate vulnerabilities without undue delay

"In relation to the risks posed to the products with digital elements, address and remediate vulnerabilities without delay, including by providing security updates."

The manufacturer needs a documented vulnerability response policy: triage SLA, severity tiers, patch SLA per tier, communication plan. Industry common practice is Critical < 7 days, High < 30 days, Medium < 90 days from validated disclosure.

3. Apply effective and regular tests and reviews of the security

"Apply effective and regular tests and reviews of the security of the product."

Minimum: static analysis (SAST), dynamic analysis (DAST), dependency-scan, and unit-test coverage of security-critical paths — all in continuous integration. For higher-risk products: annual independent penetration test, threat-modelling exercise per major release.

4. Publicly share information about fixed vulnerabilities

"Once a security update has been made available, publicly disclose information about fixed vulnerabilities, including a description of the vulnerabilities, information allowing users to identify the product with digital elements affected, the impacts of the vulnerabilities, their severity and clear and accessible information helping users to remediate the vulnerabilities."

Issue a CVE entry (via CNA or MITRE root) or a vendor security advisory. Include affected versions, severity (CVSS), mitigation instructions, and update path. Publish on a stable URL discoverable from the product documentation.

5. Coordinated vulnerability disclosure policy

"Put in place and enforce a policy on coordinated vulnerability disclosure."

Publish a security.txt file at /.well-known/security.txt. Offer a contact channel (email, web form, or platform like HackerOne). Commit to acknowledgement (e.g. < 5 working days) and remediation timelines. Honour reporter confidentiality and reasonable disclosure timelines.

6. Facilitate sharing of information about potential vulnerabilities

"Take measures to facilitate the sharing of information about potential vulnerabilities in their product […]"

Cooperate with ENISA, member-state CSIRTs, and disclosed researchers. No legal threats, no DMCA-style takedowns against good-faith security research. Participate in industry sharing frameworks where relevant.

7. Securely distribute updates

"Provide for mechanisms to securely distribute updates for products with digital elements to ensure that vulnerabilities are fixed or mitigated in a timely manner […]"

Signed update packages, integrity-checked download (HTTPS + checksum), authenticated update server, atomic install with rollback only by user consent. The update channel itself must not be a vulnerability — historically a common attack vector.

8. Updates disseminated without delay and free of charge

"Ensure that, where security patches or updates are available to address identified security issues, they are disseminated without delay and, unless otherwise agreed between a manufacturer and a business user in relation to a tailor-made product with digital elements, free of charge […]"

No payment, no subscription, no warranty exclusion attached to security patches throughout the support period. The support period itself must be declared (Article 13(8)) and is normally at least five years — shorter only with justification.

Common interpretation mistakes

From the Inovasense compliance practice and the Cenitia review pipeline, the most frequent mistakes manufacturers make when reading Annex I:

• Treating Part I as "design checklist done at start" and Part II as "we'll deal with that later". Both apply throughout the support period. A product shipped with no SBOM (Part II item 1) cannot satisfy Annex I from day one.
• Confusing "secure-by-default" (Part I item 3) with "secure as documented". Annex I requires the factory default state to be secure. A product that becomes secure only after the user reads the manual and changes 12 settings is non-compliant.
• Treating "appropriate level of cybersecurity" (Part I item 1) as a vibe. It must be the documented output of a written risk assessment. "We thought about security" without a document is not appropriate.
• Self-asserting EN 18031 conformity before OJ citation. Until EN 18031 is listed in the Official Journal, citing it on the DoC does not give presumption of conformity — it gives a marketing claim. Manufacturers should either anticipate it with that caveat documented, or use EN 303 645 as the citable baseline.
• Skipping the SBOM because the product is "pure firmware in C". The SBOM requirement applies regardless of language. A C firmware product still depends on libraries, an RTOS, a toolchain, drivers — all of which go in the SBOM.
• Confusing 24-hour ENISA notification (Article 14) with the 72-hour GDPR breach notification (Article 33). They are different obligations triggered by different events. Both can apply simultaneously when a personal-data breach is also an actively exploited CRA vulnerability.

How CRA Annex I relates to other regimes

CRA does not exist in isolation. Three other frameworks materially overlap:

• RED Delegated Act / EN 18031 — the Radio Equipment Directive's delegated cybersecurity acts (mandatory since 1 August 2025) cover similar ground for products with radio. EN 18031 is the common harmonised standard. A product compliant with RED via EN 18031 is most of the way to CRA Annex I but still needs SBOM, vulnerability disclosure policy, and the formal CRA DoC.
• NIS2 Directive ((EU) 2022/2555) — applies to operators of essential services (energy, transport, banking, etc.). CRA applies to products. A product sold to a NIS2-regulated operator must meet CRA; the operator separately has NIS2 obligations.
• IEC 62443 — international standard family for industrial automation cybersecurity. Overlaps with CRA Annex I on industrial IoT but is broader (covers asset owners and integrators too). IEC 62443-4-1 (process) and -4-2 (product) are the parts most relevant to CRA compliance.

How Cenitia maps your product against Annex I

Cenitia parses your product description, BOM, software architecture, and uploaded engineering documents to produce a per-requirement Annex I matrix: for each of the 21 items, what evidence in your Technical File satisfies it, what is missing, and what harmonised standard (EN 18031, EN 303 645) the cited claim is grounded in. The output is a draft Declaration of Conformity ready for review and signing, with every claim citing the specific Annex I item and the EUR-Lex source paragraph.

When CRA enforcement begins on 11 December 2027, the affected document is automatically reviewed against any post-publication amendments to Annex I or to the cited harmonised standards. You find out about a regulatory change before your distributor does.

For products that need Notified Body assessment under Annex III Class II, or full lifecycle compliance management including ENISA notification operations, our parent company Inovasense provides expert-led consulting.

Frequently asked questions

When does CRA Annex I become enforceable?

The Cyber Resilience Act enters full application on 11 December 2027. Mandatory reporting of actively exploited vulnerabilities and severe incidents to ENISA starts earlier — on 11 September 2026. From 11 December 2027 onwards, no product with digital elements can be CE-marked or placed on the EU market without satisfying Annex I.

What products are subject to CRA Annex I?

Every "product with digital elements" placed on the EU market — defined in Article 3 as any software or hardware product and its remote data processing solutions. This includes connected consumer products, industrial IoT, smart home devices, network equipment, operating systems, microcontrollers, and pure software products. Open-source components developed outside a commercial activity are excluded under Article 2.

How do harmonised standards relate to Annex I?

Compliance with a harmonised standard listed in the Official Journal under the CRA gives a "presumption of conformity" with the corresponding Annex I requirements. The principal harmonised standard under development for CRA is EN 18031, with sub-parts EN 18031-1 (security requirements for products with digital elements), EN 18031-2 (vulnerability handling), and EN 18031-3 (vulnerability disclosure). Until OJ publication, manufacturers either anticipate the standard, use EN 303 645 as a baseline, or take a Module B/C/D path with a Notified Body.

Do I need a Notified Body to demonstrate Annex I conformity?

Only for "important" products listed in Annex III and "critical" products in Annex IV. Important Class I and Class II products require either an applied harmonised standard (Module A self-assessment) or third-party Notified Body assessment (Modules B/C/H). Critical products always require Notified Body involvement plus EU statement of conformity from the Commission's certification scheme. The default for ordinary connected consumer products is self-assessment.

What is the role of the SBOM under CRA Annex I?

Annex I Part II item (1) requires manufacturers to identify and document vulnerabilities and components contained in the product. In practice this means a machine-readable Software Bill of Materials in either CycloneDX or SPDX format, maintained throughout the support period, and made available to authorities on request. The SBOM is the input to ongoing CVE monitoring required under item (2) of the same Part.

How does CRA Annex I compare to EN 303 645 (the consumer IoT baseline)?

EN 303 645 is a 13-control baseline standard for consumer IoT, in force since 2020. CRA Annex I subsumes most of EN 303 645 (default credentials, vulnerability disclosure, software updates, secure storage of credentials) and adds requirements that EN 303 645 only recommends — explicit SBOM, mandatory coordinated vulnerability disclosure policy, secure-by-default configuration, vulnerability remediation SLA. Most products that already comply with EN 303 645 are 60–70% of the way to CRA Annex I but need to formalise the gap.

What are the penalties for non-compliance with CRA Annex I?

Article 64 of the CRA sets administrative fine ceilings at €15 million or 2.5% of global annual turnover (whichever is higher) for non-compliance with the essential requirements in Annex I. Failure to report exploited vulnerabilities to ENISA carries up to €10 million or 2% of turnover. Other violations of the regulation are capped at €5 million or 1%. Member state market surveillance authorities can also order withdrawal, recall, and import bans.

What is the difference between Annex I and Annex II of the CRA?

Annex I lists the essential cybersecurity requirements every product must meet (the 21 items this article explains). Annex II lists the information and instructions to users that must accompany every product — manufacturer details, intended use, points of contact for vulnerability reporting, support period end-date, and instructions for secure use, decommissioning, and updates. Annex I is what the product does; Annex II is what the manufacturer tells the user.

Related from the Library

• Declaration of Conformity 101 — what it is, who needs it, how it's signed — the legal artefact your Annex I compliance ends up in

Further reading

Primary EU sources:

• Cyber Resilience Act — Regulation (EU) 2024/2847 — full text including Annex I
• Annex III — important products with digital elements
• Annex IV — critical products with digital elements
• NIS2 Directive — (EU) 2022/2555
• GDPR — Regulation (EU) 2016/679

Harmonised standards and guidance:

• CEN-CENELEC cybersecurity work programme — EN 18031 development status
• ENISA — CRA implementation guidance
• EN 303 645 — Consumer IoT baseline security
• CycloneDX — SBOM specification
• SPDX — SBOM specification
• security.txt — standardised vulnerability disclosure file
• IEC 62443 — Industrial automation and control system security

Last reviewed: 10 June 2026. Cited regulations watched continuously by Cenitia — when one amends, this article is flagged for update.