EU Cyber Resilience Act conformity assessment — what to do before 2027

The EU Cyber Resilience Act will be the single most consequential cybersecurity regulation for product manufacturers in the European market. The first obligations apply from 2026 (vulnerability and incident reporting), and full applicability — including conformity assessment for CE marking — kicks in in 2027.

If your company makes a product with digital elements that you place on the EU market, the CRA applies. The thresholds are not based on company size; they are based on product class. This article walks through what your conformity-assessment plan should look like, and the work you should be doing now rather than in late 2026.

Scope: who is in?

A "product with digital elements" is, in CRA language, any software or hardware product that processes data and has a logical or physical connection. That includes:

• Connected consumer products (cameras, smart-home devices, wearables).
• Industrial automation components and PLCs.
• Software products sold or licensed in the EU, including SaaS in some readings (the borderline cases are still being clarified by the European Commission guidance).
• Operating systems, browsers, security products, identity products.
• Specifically out: SaaS that does not qualify as a "product" under the regulation, free open-source software developed outside commercial activity, and a few sector-specific products covered by other regulations (medical devices under MDR, motor vehicles).

Annex I — the cybersecurity essential requirements

Annex I is short and harsh. The product must:

1. Be designed, developed and produced to ensure an appropriate level of cybersecurity.
2. Have no known exploitable vulnerabilities at the time of placing on the market.
3. Have a default secure configuration.
4. Support security updates throughout the support period (which CRA requires you to declare).
5. Protect confidentiality of stored, transmitted and processed data, with cryptography by default where appropriate.
6. Protect integrity of stored, transmitted and processed data.
7. Process only data adequate, relevant and limited to what is necessary.
8. Protect availability of essential functions.
9. Minimise the impact of incidents.
10. Provide security-relevant information through appropriate mechanisms (logs, telemetry).
11. Allow vulnerabilities to be addressed through security updates, including automatic security updates by default for consumer products.

The "no known exploitable vulnerabilities at time of placing on the market" requirement is the single biggest behavioural change for product teams used to shipping with a known-bug list.

Annex II — vulnerability handling

Annex II is the vulnerability handling process you must operate over the lifetime of the product:

• Identify and document the components of the product, including by producing a software bill of materials (SBOM) in a commonly used format.
• Address and remediate vulnerabilities without delay, including by providing security updates.
• Apply effective and regular tests of the security of the product.
• Coordinate disclosure of vulnerabilities, including with the European Union Agency for Cybersecurity (ENISA).
• Make available a contact for vulnerability reporting.
• Provide for mechanisms to securely distribute updates.
• Provide for prompt public disclosure of remedied vulnerabilities, including the description, the impact, and the corrective measures.

Article 14 — incident and exploited-vulnerability reporting

CRA introduces two distinct reporting obligations:

1. An "actively exploited vulnerability" must be reported to ENISA within 24 hours of awareness, with a follow-up within 14 days. The "actively exploited" threshold is in-the-wild exploitation, not theoretical exploitability.
2. A "severe incident having an impact on the security of the product" must be reported to ENISA within 24 hours, with follow-ups within 72 hours and 1 month.

Conformity assessment routes

The route depends on the product class. Most products will use Module A — internal production control plus self-declaration. Important products (Class I and Class II) require either Module B+C, Module D, or Module H, depending on the class. Critical products require notified-body involvement.

For most software products, the practical conformity-assessment package looks like:

• Cybersecurity risk assessment of the product, documented.
• Evidence of secure-development practices (we recommend mapping to ISO/IEC 27034 and IEC 62443-4-1).
• Penetration test report against Annex I requirements, ideally re-tested before each release.
• SBOM in a commonly used format (CycloneDX or SPDX).
• Vulnerability handling policy and process evidence.
• A declared support period and a published security-update policy.
• EU declaration of conformity — the legal output of the assessment.

What to do in 2026

1. Build the SBOM pipeline today. CycloneDX or SPDX, generated in CI, attached to releases. This is the longest lead-time work and the easiest to underestimate.
2. Stand up a coordinated vulnerability disclosure process with a clear contact (security.txt, see RFC 9116).
3. Run a CRA Annex I gap analysis against your most strategic product. The findings drive the 2026 product backlog.
4. Decide the support period. Two years is the de facto floor; many regulators will probe for five.
5. Document the secure-development life cycle. The auditor reads what you have written, not what you describe verbally.

Where Sandline fits

We run pre-market product security assessments against Annex I, stand up the coordinated vulnerability disclosure process, generate the SBOM and run the gap analysis. The conformity-assessment statement is yours to make; we produce the technical evidence underneath.