A Product Is Called “Critical” Under the CRA: What Must Be Known Before Quoting the Assessment?
Qualify a CRA conformity-assessment request through the exact product version, Annex category, assessment route, evidence file and EU market date before proposing work.
Signals to watch
- A named product and software or firmware version are connected to an EU market-placement or release decision
- The requester can show why the product falls in the CRA default, Annex III important or Annex IV critical category
- A proposed conformity-assessment route is connected to available standards, a notified-body need and a defined evidence gap
A CRA conformity-assessment request is ready to discuss only after five things are joined in one record: the exact product version, the manufacturer’s role, the reason for its product category, the proposed assessment route and the evidence that exists before the next EU market decision. If “critical” is only an adjective in a Telegram message, do not quote a critical-product assessment. First determine whether the product is in Annex IV of the Cyber Resilience Act (CRA), in an Annex III important-product class, or in the default category.
This is the working problem for a product-cybersecurity conformity-assessment consultancy business-development lead following authorised Telegram groups used by device makers, software vendors, test laboratories, notified-body specialists and product-compliance teams. The useful Signal is not “CRA help needed.” It is a named product approaching an EU release or market-placement decision while its category, route and evidence disagree. Seeing that combination a day late can mean an assessment workshop or laboratory slot is planned against the wrong product version. It still does not prove budget, legal scope or buyer authority.
Start with a five-line assessment record
The CRA is Regulation (EU) 2024/2847, which sets cybersecurity requirements for products with digital elements made available on the European Union market. A conformity assessment is the process used to demonstrate that the applicable requirements have been met. Under the Commission’s conformity-assessment explanation, most products remain in a default category where manufacturer self-assessment is allowed. Annex III important products and Annex IV critical products face stricter routes.
Before asking a technical assessor for effort or availability, record these five lines:
- Product: commercial name, model, hardware revision, software or firmware release, intended purpose and supplied components.
- Role: the entity acting as manufacturer, plus any importer, distributor or open-source software steward relevant to the request.
- Category basis: default, Annex III class I or II, or Annex IV, with the exact listed category and the product facts used to reach it.
- Route and evidence: the proposed procedure, standards or specifications applied, notified-body status and current technical-file artifacts.
- Decision date: what will happen, to which version, in which EU market, and whether the date concerns release, placing on the market or an internal design gate.
This record is the article’s original class-to-evidence decision method. It does not decide compliance. It stops a commercial proposal from silently assuming the very category and evidence that the engagement may need to establish.
Freeze the product before debating its class
“Industrial firewall” or “secure gateway” is not a product record. A gateway sold with two operating-system builds can present different functions and components. A software product deployed as a standalone application may not be the same assessment object as code embedded in an appliance. Accessories and separately marketed components can also change the boundary.
Ask which configuration will carry the EU declaration of conformity and CE marking. Then capture the supplied version, intended purpose, remote-processing dependencies and the hardware or software components needed for the product to perform its functions. If the requester cannot name that object, classification work is the first deliverable; a fixed assessment quote would be premature.
The manufacturer role matters at the same time. A reseller asking on behalf of a vendor, an importer preparing a file and a manufacturer controlling product design do not own the same evidence or declarations. A Telegram author may know the deadline but not have authority to release the technical documentation. Keep that authority unknown until a person verifies it.
Replace “critical” with the Annex entry and product facts
A product can be vital to a customer’s operations without being a CRA “critical product with digital elements.” The legal category comes from Annex IV. Annex III separately lists important products and divides them into class I and class II. The default category covers other in-scope products.
For each classification claim, write two sentences. The first names the exact Annex category being relied on. The second states which product functions make the described version fit that category. If either sentence is missing, record the class as proposed rather than confirmed.
For example, a composite group fragment might say, “secure element, CRA critical, need assessment before release.” This is deliberately incomplete and is not a customer message. It omits the product model, supplied function, whether the secure element is the marketed product or one component, the manufacturer, the Annex analysis, current standards, available evidence and the release event. It deserves a question, not a critical-product quotation.
Select the route only after the category is evidenced
The Commission describes the routes in practical terms: default-category products may use manufacturer self-assessment, while important and critical categories require the Article 32 decision to be applied more carefully. Annex III class, use of applicable harmonised standards or common specifications, and any qualifying certification scheme affect which route is available. For Annex IV products, an applicable European cybersecurity certification scheme can supply the route under the Regulation’s conditions; without one, the Regulation points to EU-type examination plus conformity to type, or full quality assurance—third-party procedures involving a notified body. The binding Regulation, including Article 32 and Annex VIII, governs the actual route.
That means “we will use a standard” is not yet a route. Record which applicable requirements it covers, whether the standard or common specification is available and applied in full where the route depends on it, and what remains outside its coverage. If a notified body is proposed, identify the body or at least the required designation scope and availability status. A commercial lead should not promise an appointment that has not been confirmed.
Do not turn a possible certification scheme into a current shortcut. At the actual market-decision date, verify the applicable scheme, assurance level, implementing or delegated acts, product coverage and uncovered CRA requirements. Likewise, do not promise a notified-body appointment until designation scope and availability have been confirmed.
Turn the technical file into an evidence inventory
A broad question such as “Do you have the technical file?” invites a broad yes. Ask instead for the artifacts that support this product and route: the product description and architecture, cybersecurity risk assessment, applicable-requirement mapping, secure-development and vulnerability-handling records, support-period decision, test evidence, standards analysis, component information and draft declaration material where available.
For each artifact, record four states: present for the assessed version, present for another version, missing, or not yet reviewed. Then add an owner and a source location. A penetration-test report can be useful evidence without covering the development process, update mechanism or vulnerability handling. An earlier radio-equipment cybersecurity report can inform technical analysis without settling the CRA category or route.
The distinction between RED, EN 18031 and CRA evidence is examined in the EU product-security source-routing article. For the separate vulnerability-reporting workflow that begins applying earlier, use the CRA reporting-request analysis. Those are adjacent questions, not substitutes for this conformity record.
Tie the proposal to a real product decision
The CRA applies generally from 11 December 2027, while some provisions apply earlier. A date in a request therefore needs an event, not merely “before CRA.” Ask whether the team is freezing a design, booking testing, changing a supplier, preparing an EU market placement or updating an already marketed product. Ask which version the event covers and who can release evidence.
An engagement is ready for a scoped discussion when the product boundary and decision date are known, the category is supported or classification is explicitly part of the work, the candidate route is stated with assumptions, and the evidence inventory reveals reviewable gaps. Hold the quote when the request mixes multiple versions, treats “critical” as an unsupported label or assumes a notified-body slot. Decline or refer work when the requester cannot authorise access to the necessary records.
TOP Prospect can connect fragments from Telegram groups a user intentionally connects and is authorised to access, preserve the original text, source and time, merge duplicates and rank the thread for human review. It cannot classify the product, inspect a technical file, select a legal route, confirm a notified body, contact the requester or certify conformity. If authorised-group discovery later becomes part of the buying discussion, the pricing page describes the public product options.
The finished commercial note should make one uncertainty visible rather than hide it: “critical product” is either an evidenced Annex IV classification, a classification task inside the proposed engagement, or an unverified phrase that is not ready to price.
FAQ
Does calling a product security-critical make it a CRA critical product?
No. Critical products with digital elements are the categories listed in Annex IV. Ordinary security importance does not establish that category.
Does every CRA product require a notified body?
No. The default category can use manufacturer self-assessment. Annex III routes depend on class and use of applicable standards, specifications or certification schemes. Annex IV follows Article 32: an applicable EU cybersecurity certification scheme may supply the route; without one, third-party procedures apply.
What belongs in the first assessment request?
The exact product and version, manufacturer role, intended purpose and functions, claimed category and basis, proposed route, standards used, current evidence inventory and dated EU market decision.
Can an EN 18031 report prove CRA conformity?
No. It may provide relevant bounded technical evidence, but it does not by itself establish CRA scope, category, conformity route or all lifecycle obligations.
Frequently asked questions
Does calling a product security-critical make it a CRA critical product?
No. Critical products with digital elements are the categories listed in Annex IV of Regulation (EU) 2024/2847. Security importance in ordinary language does not establish that legal category.
Does every CRA product require a notified body?
No. The default category can use manufacturer self-assessment. Annex III routes depend on the class and how applicable standards, specifications or certification schemes are used. Annex IV follows Article 32: an applicable EU cybersecurity certification scheme may supply the route; without one, the Regulation sends the product through third-party conformity procedures.
What should be collected before requesting an assessment proposal?
Collect the exact product and version, manufacturer and economic-operator role, intended purpose and functions, claimed Annex category, proposed assessment route, standards or specifications used, current technical-file evidence and the dated EU market decision.
Can an EN 18031 report prove CRA conformity?
No. It may supply relevant technical evidence for a covered product and requirement, but it does not by itself decide CRA scope, product category, conformity route or all lifecycle obligations.
Sources and further reading
How a Signal worth attention is found
See how Top Prospect finds and organizes Signals worth checking, keeps the original Telegram context, removes duplicates, and helps you decide what to review first. You decide whether to follow up and what to do next.
