How it is created — REG-REC-020 CRA Product Classification Determination

1. What this determines

Classification decides how much of the rest of your compliance programme costs. Default products may self-assess; important and critical products can require a Notified Body, which adds months of lead time. Everything downstream — the conformity route, the project plan, the budget — depends on this one determination.

The record also protects you in the far more common case where the answer is "default": it shows an auditor that Annex III was considered and reasoned, not overlooked.

2. Inputs

• The intended purpose, written as a product statement rather than a marketing claim: what the product does, for whom, in what environment.
• Reasonably foreseeable misuse.
• The function list, with special attention to anything that authenticates, filters, manages, monitors or protects other devices.
• The current Annex III and Annex IV texts and any implementing acts.

3. Steps

1. Write the intended purpose and the negative statements. The sentences that matter most are the ones saying what the product is not: not a security component, performs no authentication for other devices, no network management function. These are what the categories turn on.
2. Walk every Annex III category in a table — all of them, including the ones that obviously do not apply. Record "no" with a one-line reason. An auditor reads the reasons, not the conclusion.
3. Repeat for Annex IV. Note the distinction that trips up hardware teams: integrating a security-capable microcontroller is not the same as placing that microcontroller on the market as a product.
4. Assess accessories and companion parts separately. A gateway, an app or a cloud component may classify differently from the device; do not let one determination silently cover three products.
5. State the determination in one sentence and name the consequence: which conformity routes remain available.
6. Add the sensitivity note. List the planned or discussed features that would change the answer — a safety-relevant autonomous action, a filtering function, a management capability — and state that classification is re-run before development of that feature starts.
7. Have management approve and date it. Then reference it from the conformity-route decision and the technical documentation.

4. Done when

• Every Annex III and Annex IV category is addressed with a reason, not just the matching one.
• The determination names the resulting available routes.
• The re-assessment trigger is concrete enough to fire by itself (feature names, not "significant changes").
• The record is dated, signed, and referenced by the technical documentation.

5. Common mistakes

Classifying the company rather than each product. Confusing "our product is used in a security context" with "our product performs a security function" — only the latter drives Annex III. Deciding once and never re-running it when the roadmap adds the feature that changes the answer.

6. In TRA Studio

The intended purpose, the environment assumptions and the foreseeable misuse you write here are the same inputs the TRA needs — capture them once on the product and reuse them, so the classification record and the risk assessment cannot drift apart.