CRA questions, glossary and resources
Start with the task you need to complete. For a borderline case, record the facts that affect the result and check them against current legislation and guidance.
Quick links
- Check whether the CRA applies to a product
- Identify your role
- Check the dates
- Choose a conformity assessment route
- Submit a CRA report
- Report a vulnerability or another event
- Report possible product non-compliance
- Find legislation or an official source
Frequently asked questions
1. Does the CRA apply to my product?
Short answer: Probably, if hardware or software is made available on the EU market and its intended or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network. Also test commercial activity, specific exclusions, open-source conditions and whether remote data processing forms part of the product.
Do now: Open Submit a CRA report for route selection and submission guidance.
Watch out: Digital functionality alone is not the complete scope test. SaaS is not automatically a product with digital elements; qualifying remote data processing may form part of one.
Sources: CRA Articles 2–3; final Commission guidance of 27 July 2026.
2. Does the CRA cover an internally developed product that we do not sell?
Short answer: Pure internal use without making the product available on the market will generally not meet the core scope condition. The answer may change if it is supplied to another legal person or customer in the course of a commercial activity, including without a direct price.
Do now: Identify separate legal entities, recipients, supply terms and direct or indirect monetisation. Do not rely only on the labels “internal” or “free”.
Sources: CRA Articles 2–3; Commission guidance.
3. Does an open-source licence mean that the CRA does not apply?
Short answer: No. Free and open-source software developed or supplied outside a commercial activity receives specific treatment, but the licence alone is not decisive. A legal person that systematically and sustainably supports the development of specific open-source products intended for commercial activity and ensures their viability may be an open-source software steward. An entity marketing or monetising a product under its own name may be a manufacturer.
Do now: Map legal entities, funding, monetisation, distribution, product control and project support. Assess contributors, stewards and manufacturers separately.
Sources: CRA Article 3(14), Article 24 and Recitals 18–20; Commission open-source page.
4. Am I a manufacturer, importer or distributor?
Short answer: A manufacturer develops/manufactures, or has a product developed/manufactured, and markets it under its own name or trademark. An EU-established importer places a product bearing a non-EU person’s name or trademark on the market. A distributor is another supply-chain actor making it available without affecting its properties. One organisation can perform several roles.
Important: An importer or distributor can become a manufacturer by marketing under its own name/trademark or substantially modifying the product.
Do now: Identify roles per product, brand, contract and market—not once for the whole company.
Sources: CRA Article 3(13), (17)–(18); Articles 19–22.
5. Which obligations apply now and which start later?
Short answer: The CRA entered into force on 10 December 2024. Chapter IV on notification of conformity-assessment bodies has applied since 11 June 2026. Article 14 reporting applies from 11 September 2026. Most other obligations apply from 11 December 2027.
Do now: Manufacturers need an operational reporting process now. Open-source software stewards should prepare for the Article 24(3) duties from 11 December 2027. In parallel, prepare portfolio scope, secure development, evidence, support and conformity for general application in 2027.
Watch out: Earlier reporting can cover products made available before 11 December 2027. Other main requirements generally catch earlier products when substantially modified from that date.
Sources: CRA Articles 69 and 71; Commission timeline.
6. Must a product placed on the market before 11 December 2027 meet all new requirements?
Short answer: Not automatically. Main CRA requirements generally apply to those products if they undergo a substantial modification from 11 December 2027. Article 14 reporting is an express exception and starts earlier.
Do now: Record each version’s placement date and assess later changes. If a change affects conformity with essential requirements or the intended purpose used in the original assessment, perform a legal and technical substantial-modification review.
Sources: CRA Article 69(2)–(3); Commission guidance.
7. Do I need a notified body, or may I use internal control?
Short answer: It depends on category and route. Products outside important and critical categories generally permit internal control. Important class I products permit it only on the Article 32 conditions; otherwise third-party assessment is required. Important class II and critical products use the prescribed third-party or available and applicable certification routes.
Do now: Determine core functionality, check Annexes III–IV and Implementing Regulation 2025/2392, then verify current standards, common specifications, certification schemes and a notified body’s NANDO scope.
Watch out: CE is not a warranty that a product has no vulnerabilities. Accreditation and notification are not synonyms.
Sources: CRA Articles 27 and 32, Annex VIII; Implementing Regulation (EU) 2025/2392; Commission conformity-assessment page.
8. What must an importer or distributor check before supplying a product?
Short answer: Before placing a product on the market, an importer checks conformity assessment, technical documentation, CE, declaration, instructions, identification and manufacturer information, and support information. A distributor exercises due care and checks CE and required manufacturer/importer information and documents. Their duties are not identical.
Do now: If you have reason to believe the product is non-compliant or presents a significant cybersecurity risk, stop placement or further availability, notify the relevant actors and follow the steps for your role and risk.
Sources: CRA Articles 19–21.
9. When must I submit a CRA report?
Short answer: A manufacturer reports an actively exploited product vulnerability and a severe incident affecting product security. The staged process starts on awareness: early warning within 24 hours and a fuller notification within 72 hours. The final vulnerability report is due no later than 14 days after a corrective or mitigating measure becomes available; the severe-incident final report is due within one month after the 72-hour notification.
Do now: Do not wait for a complete fix or analysis. Preserve awareness time, affected products/versions, scope, exploitation or incident status and mitigations; continue to Do I need to report?
Sources: CRA Article 14; Commission reporting page; ENISA SRP FAQ.
10. Where do I submit a mandatory CRA report?
Short answer: JISKB is Slovakia’s preferred route, but the entry point depends on access and occurrence type. Start with the SK-CERT route page: a CRA-related vulnerability is directed to CVD, while a severe incident uses JISKB sign-in or the public form according to access. Direct SRP access is also available.
Do now: Open Submit a CRA report for current service status, the JISKB entry point and submission steps.
Sources: CRA Articles 14–16; ENISA SRP and SRP FAQ.
11. What if no vulnerability fix is available yet?
Short answer: The absence of a fix does not postpone the initial report. Submit what is known at the applicable stage, describe investigation and available mitigations, and update the report as the process requires.
Do now: Limit harm, preserve evidence, prepare safe user communications and document decisions. Do not publish sensitive technical details outside the designated channel.
Sources: CRA Article 14; ENISA submission/update guidance.
12. Which route should I use: CRA, NIS2, CVD or product complaint?
Short answer: They serve different purposes; one route may not discharge another duty.
| Situation | Start here |
|---|---|
| Manufacturer reports an actively exploited vulnerability or severe product-security incident | Mandatory CRA report through the verified SRP route |
| NIS2 entity reports an incident affecting its network or service | National NIS2 incident-reporting route |
| Researcher or another person voluntarily reports a vulnerability | CVD or Article 15 voluntary report; use the manufacturer’s security contact first where appropriate |
| Buyer/user flags possible breach of product requirements | Market-surveillance product concern |
| General question | Contact or FAQ; contact does not replace a statutory report |
Do now: Where CRA and NIS2 may both apply, assess and fulfil both. Do not assume “one submission covers all” unless the relevant rules and services expressly confirm it.
Sources: CRA Articles 14–16 and 52; Directive (EU) 2022/2555 and Slovak implementation.
13. What can a buyer or user check?
Short answer: Check product and manufacturer identification, CE, declaration availability, security instructions, update method, vulnerability contact and support end date. CE indicates declared conformity with applicable requirements; it does not mean vulnerability-free.
Do now: Compare support periods and security-update delivery before purchase. Contact the manufacturer about a problem; disclose vulnerabilities safely and route possible product non-compliance to the designated surveillance authority.
Sources: CRA Article 13(16), (18)–(20); Annex II; Article 52(11).
14. Is an answer in this FAQ legally binding?
Short answer: No. This FAQ aids navigation. Applicable law and decisions of competent authorities and courts control. Commission guidance and NBÚ explanations must identify their author, version and legal status.
Do now: For a decision with legal or security consequences, open the source below the answer and verify its date, version, scope and provision.
Glossary
The Slovak glossary above and English definitions must be stored as one paired term set, not maintained as unrelated pages. Required English preferred terms are:
| English preferred term | Plain-language definition | Primary source |
|---|---|---|
| Cyber Resilience Act (CRA) | Regulation (EU) 2024/2847 setting horizontal cybersecurity requirements for products with digital elements. | CRA |
| product with digital elements | A software or hardware product and its remote data-processing solutions, including separately marketed components, within the CRA definition. | Art. 3(1)–(2) |
| making available on the market | Supplying a product for distribution or use on the EU market in a commercial activity, whether paid or free. | Art. 3 |
| placing on the market | The first making available of a product on the EU market. | Art. 3 |
| manufacturer | An actor that develops/manufactures, or has a product developed/manufactured, and markets it under its name or trademark. | Art. 3(13); Arts. 21–22 |
| importer / distributor | An EU actor placing a non-EU branded product on the market / another supply-chain actor making it available without affecting its properties. | Art. 3(17)–(18); Arts. 19–20 |
| authorised representative | An EU-established actor with a written manufacturer mandate for specified tasks. Core manufacturer responsibility remains. | Art. 3(15); Art. 18 |
| open-source software steward | A legal person, other than a manufacturer, sustainably supporting specified FOSS intended for commercial activity and ensuring its viability. | Art. 3(14); Art. 24 |
| substantial modification | A post-market change affecting conformity with essential requirements or changing the assessed intended purpose. | Art. 3; Arts. 21–22 |
| important / critical product | A product whose core functionality falls in Annex III or IV and current technical descriptions. | Arts. 7–8; Annexes III–IV |
| essential cybersecurity requirements | Risk-proportionate product properties and vulnerability-handling process requirements. | Annex I |
| cybersecurity risk assessment | Documented assessment applied through planning, design, development, production, delivery and maintenance. | Art. 13; Annex VII |
| SBOM | Machine-readable inventory of software elements covering at least top-level dependencies. It is not automatically public. | Annex I Part II; Annex VII |
| support period | Time during which the manufacturer effectively handles vulnerabilities and supplies security updates. | Art. 13 |
| actively exploited vulnerability | A vulnerability with reliable evidence of malicious exploitation without the system owner’s permission. | Arts. 3 and 14 |
| severe incident | An incident affecting product security and meeting the CRA severity criteria. | Art. 14(5) |
| coordinated vulnerability disclosure (CVD) | A safe intake, verification, remediation and coordinated disclosure process. | Annex I Part II; Art. 15 |
| Single Reporting Platform (SRP) | ENISA’s platform for CRA reporting. It is not a NIS2 portal, email inbox or market-surveillance complaint. | Art. 16; ENISA |
| coordinator CSIRT | A nationally designated CSIRT receiving and coordinating CRA notifications under Articles 14–17. | Arts. 14–17 |
| market-surveillance authority | Authority checking compliance and able to require correction, restriction, withdrawal or recall. | Arts. 52–60 |
| conformity-assessment body / notified body | Independent body meeting CRA requirements / such a body notified to perform specified third-party procedures. Accreditation alone is not notification. | Arts. 35–51 |
| presumption of conformity | Defined legal effect of fully applying a relevant harmonised standard, common specification or recognised certification route. | Art. 27 |
| EU declaration of conformity / CE marking | Manufacturer’s conformity declaration / marking that signifies declared compliance with applicable EU harmonisation requirements. Neither promises zero vulnerabilities. | Arts. 28–30; Annexes V–VI |
| withdrawal / recall | Preventing further supply-chain availability / recovering a product already supplied to the end user. | CRA; Regulation (EU) 2019/1020 |
Related help
- Mandatory reporting questions – decisions, deadlines, required information and the submission route.
- Legal acts and official sources – binding texts and routes to specialist material.
- European Commission guidance – the detailed official FAQs and implementation guidance.
This page provides general orientation. For a specific legal or security decision, verify the source, version and date.