The EU Cyber Resilience Act: What Annex I Asks of AppSec

The EU Cyber Resilience Act is now partly in force for software companies. Since 11 September 2026, manufacturers of products with digital elements sold in the EU must report actively exploited vulnerabilities and severe incidents on a fixed clock. From 11 December 2027, the full set of essential requirements in Annex I applies.

For most security teams the Cyber Resilience Act lands on AppSec's desk, because a large share of Annex I is application security written as law: no known exploitable vulnerabilities, secure defaults, an SBOM, vulnerability handling, security updates. This post explains what the regulation asks of software teams, what Annex I says in practical terms, and what evidence an AppSec program can produce today.

This is a practitioner's summary, not legal advice. Read the regulation text on EUR-Lex and involve counsel before you decide a product's classification or conformity route.

What the Cyber Resilience Act is

The Cyber Resilience Act (CRA) is Regulation (EU) 2024/2847. It sets cybersecurity requirements for products with digital elements placed on the EU market, and it puts the obligations on the manufacturer: whoever makes the product, or has it made, and markets it under their name.

The regulation entered into force on 10 December 2024 and applies in stages:

• 11 June 2026. Rules on notifying conformity assessment bodies.
• 11 September 2026. Article 14 reporting obligations.
• 11 December 2027. Everything else, including the Annex I essential requirements.

Is your software in scope?

A "product with digital elements" is broad. For a software company it usually means anything a customer installs or runs:

• Desktop and mobile applications.
• SDKs and libraries distributed commercially.
• Agents and daemons installed on customer infrastructure.
• Browser extensions.
• Firmware and embedded software.

Software delivered only as a service over the internet is generally outside the CRA, which leaves most pure SaaS to other rules such as NIS2. The line is not always clean: remote data processing that an in-scope product depends on to work can fall inside it. Products already covered by sector rules, such as medical devices and vehicles, are handled by those rules instead.

The CRA also classifies products. Most are in the default category and can use self-assessment. Products listed as important (Class I or Class II) or critical face stricter conformity assessment routes. The classification changes how you prove conformity. It does not change the Annex I requirements.

Article 14: reporting is already live

Article 14 is the part most teams need to act on now. When a manufacturer becomes aware of an actively exploited vulnerability in its product, it must notify the CSIRT designated as coordinator and ENISA through the single reporting platform, on a fixed timeline:

• An early warning within 24 hours.
• A vulnerability notification within 72 hours.
• A final report no later than 14 days after a corrective or mitigating measure is available.

Severe incidents that affect the security of the product follow the same 24-hour and 72-hour steps, with a final report within one month.

The practical consequence for AppSec: you need to know, per product, which components it ships and whether any of them has a known exploited vulnerability. Without that inventory, a 24-hour clock is not achievable.

Annex I in plain terms

Annex I has two parts. Part I covers properties of the product. Part II covers how the manufacturer handles vulnerabilities.

Part I: product properties

The product must be designed, developed and produced to ensure a level of cybersecurity appropriate to the risks. Based on the manufacturer's risk assessment, and where applicable, it must:

• Ship without known exploitable vulnerabilities.
• Ship with a secure-by-default configuration, with a way to reset it.
• Allow vulnerabilities to be fixed through security updates, automatic by default where that makes sense, with an opt-out.
• Protect against unauthorized access through authentication and access control.
• Protect the confidentiality of stored, transmitted and processed data, for example with encryption.
• Protect data and code integrity against unauthorized changes.
• Process only the data it needs.
• Protect the availability of essential functions, including against denial of service.
• Minimize its own negative effect on other devices and networks.
• Limit attack surfaces, including external interfaces.
• Reduce the impact of an incident through exploitation mitigation.
• Record and monitor security-relevant activity.
• Let users securely remove their data and settings.

Part II: vulnerability handling

For as long as the product is supported, the manufacturer must:

• Identify and document the product's components and vulnerabilities, including an SBOM in a common machine-readable format that covers at least the top-level dependencies.
• Address and remediate vulnerabilities without delay, including through security updates.
• Test and review the product's security regularly.
• Publish information about fixed vulnerabilities once an update is available.
• Have and enforce a coordinated vulnerability disclosure policy.
• Make it possible to report vulnerabilities, with a contact address.
• Distribute updates securely.
• Deliver security updates without delay, with advisory messages to users.

Article 13 adds the manufacturer's own obligations around these, including a support period that is at least five years unless the product is expected to be used for less time.

What AppSec can evidence, and what it cannot

Read Annex I with an AppSec program in mind and it splits cleanly.

Evidence your tools already produce

• No known exploitable vulnerabilities. Dependency findings matched against known-exploited catalogues, and critical static analysis findings.
• Secure by default. Secrets in code and CI, hard-coded credentials, debug settings left on.
• Access control. Endpoints reachable without authentication, and token-handling weaknesses.
• Confidentiality and integrity. Cleartext transport, disabled certificate validation, weak cryptography, injection and deserialization findings.
• Attack surface. Documentation and management endpoints exposed to the internet.
• SBOM. A generated SBOM per component that covers every direct dependency.
• Remediation without delay. Findings past their remediation deadline, and fixable high-severity dependency vulnerabilities.
• Regular testing. Proof that static analysis, dependency and secret scans actually ran recently.
• Disclosure and secure updates. A published security policy and signed releases, which OpenSSF Scorecard checks can show.

Obligations that need a person

Risk-based design, update mechanisms, data minimization, effects on other devices, data deletion and much of the update process are product decisions. No scanner can see them. They need a written statement from the people accountable for the product, with the evidence referenced, reviewed on a schedule.

Common mistakes in CRA readiness work

• Treating "no findings" as compliance. A repository that was never scanned has no findings. Coverage has to be shown before a clean result means anything.
• One assessment for the whole company. CRA obligations attach to each product. A portfolio average does not help the product manager who has to sign the declaration of conformity.
• Skipping the "where applicable" work. Part I applies where applicable, and the manufacturer's risk assessment decides that. Record each "not applicable" with its justification.
• Waiting for a harmonised standard. None is cited in the Official Journal yet. Readiness work cannot wait for one.
• Forgetting the support period. The obligations run for the whole support period, not just until launch.

How Heeler supports CRA readiness

Heeler Standards assesses products against the EU Cyber Resilience Act, Annex I, alongside OWASP ASVS and DORA, as part of Compliance and audit-readiness.

• CRA is off until an administrator puts a product in scope. A suggested-applications list finds likely installable software, such as iOS and Android projects, Electron or browser-extension code, and public repositories with published releases.
• Heeler holds all 22 Annex I requirements and answers 15 of them, fully or in part, from evidence it already collects. The other seven read Manual until someone attests to them for the product.
• Each product records its classification, whether it is on the EU market, its support period end date, its vulnerability contact, and where its user information and technical documentation live. All of it prints on the report.
• A not-applicable decision takes a written justification, as Article 13 expects.
• The Enforce CRA Annex I guardrail bundle turns the enforceable controls into PR Guardrails.
• Every CRA report states that it is readiness evidence, not a compliance determination.

The details are in the EU Cyber Resilience Act documentation. If you sell to EU financial entities, the DORA assessment and its supplier evidence pack cover the questions those customers ask.

A CRA readiness checklist for AppSec

1. List your products with digital elements, and agree the list with product and legal.
2. Build a per-product component inventory, so an Article 14 report is possible within 24 hours.
3. Generate an SBOM per product that covers every direct dependency.
4. Gate known-exploited vulnerabilities, secrets and injection findings at the pull request.
5. Set remediation deadlines and measure against them.
6. Publish a coordinated vulnerability disclosure policy and a contact address.
7. Sign your releases.
8. Write down the product decisions Annex I asks about, with evidence links and a review date.

FAQ

What is the Cyber Resilience Act?

The Cyber Resilience Act is Regulation (EU) 2024/2847, which sets cybersecurity requirements for products with digital elements placed on the EU market and puts the obligations on their manufacturers.

When does the Cyber Resilience Act apply?

Article 14 reporting obligations apply from 11 September 2026. The full set of requirements, including Annex I, applies from 11 December 2027.

Does the CRA apply to SaaS?

Software delivered only as a service over the internet is generally outside the CRA. Remote data processing that an in-scope product needs to function can be inside it, so check each case.

Does the CRA require an SBOM?

Yes. Annex I Part II requires manufacturers to identify and document components, including an SBOM in a commonly used, machine-readable format covering at least the top-level dependencies.

Get your products ready

Heeler assesses each product against CRA Annex I from the evidence your AppSec program already produces, and shows what still needs a person's statement. Get a demo.