Estonia · Cyber Resilience Act

CRA in Estonia: product scope, reporting and SBOM evidence

The Cyber Resilience Act (CRA) applies directly across the EU, including Estonia. This guide covers product scope, manufacturer duties, the 2026–2027 deadlines, incident reporting, support periods and the evidence a market-surveillance authority may request.

By , Tehisabiline OÜ · Last materially updated

CRA in Estonia: short answer

The Cyber Resilience Act (Regulation (EU) 2024/2847) is an EU regulation, so it applies directly in Estonia without a separate national transposition. It covers products with digital elements that are made available on the EU market in the course of a commercial activity.

Reporting obligations apply from 11 September 2026. The main product obligations, including technical documentation, vulnerability handling and conformity assessment, apply from 11 December 2027. A product can be hardware, software or a separately marketed component.

The CRA is not a one-off certificate. Manufacturers need a risk assessment, secure development and default configuration, a vulnerability process, an SBOM, a support period, technical documentation and a declaration of conformity.

Does the CRA apply to your product?

Three questions decide most cases:

  1. Is it a product with digital elements? Hardware, software or a component whose intended or reasonably foreseeable use includes a direct or indirect logical or physical connection to a device or network.
  2. Is it made available on the EU market? This includes selling, licensing, free distribution as part of a commercial model and remote data processing that is necessary for a product function.
  3. Is it a commercial activity? A price is not required. Monetisation through support, services or data can be enough. Open-source software developed outside a commercial activity is generally outside scope, but commercial integration can change that.

Examples include routers, cameras, smart devices, operating systems, applications, firmware, industrial controllers and separately sold software components. A medical device, motor vehicle or another product covered by a more specific EU rule may sit outside the CRA where that rule provides the same or a higher level of protection.

Short CRA scope check

Answer four questions. The check runs only in your browser; nothing is uploaded.

1. Is the product made available commercially on the EU market?
2. Does it have digital elements and a direct or indirect connection to a device or network?

For example software, a smart device, router, camera or a separately sold component that communicates over a network.

3. Is the product covered by a different EU sector rule that fully addresses the same risks?
4. Are you the manufacturer placing it on the market under your own name or brand?

Default, important and critical products

CRA product categories and assessment
CategoryExamplesConformity route
DefaultMost products with digital elements not listed as important or critical.Internal control and self-assessment, with technical documentation.
Important — class IIdentity management, browsers, password managers, network interfaces, certain operating systems.Self-assessment may be possible where harmonised standards, common specifications or a certification scheme are applied; otherwise a notified body may be needed.
Important — class IIHypervisors, firewalls, intrusion detection systems, certain industrial and security products.Generally third-party assessment.
CriticalSecurity chips, certain hardware security modules and other listed critical products.Third-party assessment and, where required, a European cybersecurity certificate.

The lists are in CRA Annexes III and IV and are refined by implementing acts. Check the current legal text before deciding the route; do not infer the category from the product name alone.

Manufacturer duties

  • Risk assessment: intended use, environment, threats, impact and chosen measures.
  • Secure by design and by default: minimal attack surface, secure configuration, least privilege and protection of confidentiality, integrity and availability.
  • Vulnerability handling: a contact point, intake, triage, remediation, security updates and coordinated disclosure.
  • SBOM: components and versions, suppliers, dependencies and a process for matching them to vulnerabilities.
  • Support period: at least five years unless the expected product lifetime is shorter; state it clearly before purchase.
  • Technical documentation and conformity: risk analysis, architecture, test evidence, EU declaration of conformity and CE marking where required.
  • User information: secure installation, configuration, updates and the end of support.

Importers and distributors have their own checks. A component supplier does not lose responsibility when its component is integrated into another product.

CRA incident and vulnerability reporting

CRA reporting timeline
WhenReportWhat to include
Within 24 hoursEarly warningThe vulnerability or incident, affected products, member states where available, and initial risk.
Within 72 hoursNotificationInitial assessment, affected versions, exploitation status and measures taken.
14 days after a corrective measureFinal report for an exploited vulnerabilityRoot cause, remediation, affected users and lessons learned.
1 month after the 72-hour notificationFinal report for a severe incidentIncident impact, response, recovery and preventive measures.

Manufacturers report actively exploited vulnerabilities and severe incidents through the EU single reporting platform. Keep the evidence: timeline, affected versions, exploitation indicators, customer communication and the update that fixed the issue.

SBOM and the evidence pack

An SBOM is not a PDF attachment produced once. It is a maintained inventory that lets you answer: which component and version is in which product, which supplier owns it, and which vulnerability affects it.

  • Inventory: direct and transitive components, versions and suppliers.
  • Vulnerability matching: CVE/advisory feed, triage owner and remediation SLA.
  • Release linkage: SBOM version tied to a product release and build.
  • Update process: how a component change updates the SBOM and triggers testing.
  • Customer evidence: a machine-readable extract where appropriate, plus a clear support and disclosure contact.

Our English SBOM guide and the Estonian CSV template show a practical structure. A penetration test can test a product; it does not replace the SBOM or the vulnerability process.

30-day CRA readiness plan

  1. Days 1–3: classify the product, commercial model and EU market status.
  2. Days 4–7: list components and owners; open the SBOM and vulnerability register.
  3. Days 8–14: test secure defaults, update path, access control and logging.
  4. Days 15–21: document risk analysis, support period and user information.
  5. Days 22–30: run a reporting tabletop, fix the evidence gaps and assign owners.

Request a scoping call or compare the CRA with NIS2 in Estonia.

Frequently asked questions

When does the CRA apply?

Reporting obligations apply from 11 September 2026. The main product obligations, including conformity assessment and CE marking, apply from 11 December 2027.

Does the CRA apply to software?

Yes. It applies to hardware and software products with digital elements, including separately marketed components and remote data processing necessary for a product function.

Is an SBOM mandatory?

Manufacturers must identify and document components and vulnerabilities. An SBOM is the practical way to do this and is expected in technical documentation, even though the CRA does not prescribe one file format.

How long is the support period?

At least five years, unless the product's expected lifetime is shorter. The support period must be clear to users before purchase.

What are the CRA reporting deadlines?

An early warning within 24 hours and a notification within 72 hours. The final report is due 14 days after a corrective measure, or one month after the 72-hour notification for a severe incident.

Does a penetration test prove CRA compliance?

No. A test can provide technical evidence, but it does not replace risk assessment, technical documentation, an SBOM, vulnerability handling or conformity assessment.

Sources

Need CRA evidence for a product or customer?

Describe the product, market and current documentation. We will tell you what we can test and what we cannot.

Request a scoping call