Can I use this as my technical documentation?

Not as it stands. Annex VII requires documentation specific to your product, and a template filled with archetype defaults will not survive market surveillance. Use it to structure the work and to avoid missing a category of threat, then replace every placeholder with what your product actually does.

Where do the threats come from?

They are drawn from a CRA threat catalogue mapped to Annex I Part I essential cybersecurity requirements, filtered to the ones that apply to this archetype's assets. Each row carries its STRIDE category and its Annex I reference so you can trace a threat to the requirement it evidences.

How is this different from just running the assessment in CVD Portal?

It is the same content. This page is the copyable version. CVD Portal seeds it into a live product. There the assets, threats and risk scores stay linked to your classification, your conformity route and your Annex I checklist as they change.

Does a risk assessment expire?

It has to stay current for the whole support period under Article 13. Any of three events means the assessment is revisited rather than archived. They are a substantial modification to the product, a new vulnerability class in a component you ship, and a change in how the product is deployed.

All templates

Free Template

Agricultural IoT gateway CRA Risk Assessment Starter

Q: Is this classification correct for my product?

It fits the archetype described above (Agricultural IoT gateway), and it is a starting point rather than a verdict. The gateway terminates the farm network and connects it to the internet. That places it under Annex III, Class I, point 12 (routers, modems and switches intended for connection to the internet). Sensor endpoints that only report to the gateway are assessed as default-class components of the same product. Verify it against your own product's marketed functions before relying on it, because classification determines whether self-assessment is available to you at all.

A pre-filled Cyber Resilience Act risk assessment for a field gateway aggregating soil, weather and machinery sensors over LPWAN, with a cloud backhaul and a farm-management app. It covers the Annex III/IV classification and the conformity route that follows from it. It also covers a starter asset inventory and a STRIDE threat analysis mapped to Annex I Part I essential cybersecurity requirements. It ends with the likelihood and impact scales those threats are scored against. Treat it as a first draft to challenge and replace with your own product's specifics before it becomes a technical file.

Article 13 · Article 32 · Annex I Part I · Annex V

Last updated 21 July 2026

ForProduct, engineering and compliance leads at manufacturers in agriculture starting a CRA self-assessment, and the consultants who onboard them.

CRA Articles

Article 13Article 32Annex I Part IAnnex V

User Manual: How to Use This Functionality

Implementation Guide

1. Purpose and Scope

This template provides the legal and technical structure for Agricultural IoT gateway CRA Risk Assessment Starter. It addresses obligations under Article 13 and Article 32 and Annex I Part I and Annex V for Product, engineering and compliance leads at manufacturers in agriculture starting a CRA self-assessment, and the consultants who onboard them..

2. Customisation Instructions

Replace all bracketed placeholders [LIKE THIS] with your specific details.
Review section guidance notes to align terms with your product operations.
Verify response timelines and single point of contact details before release.

3. Deployment and Maintenance

Publish the final document at your official documentation endpoint. Store version records for regulatory audit readiness. Review this document annually.

4. Platform Automation

CVD Portal automates this process. The platform logs vulnerability submissions, tracks response deadlines, generates CSAF advisories, and maintains an audit trail.

Access Template · Magic Link Required

Unlock Agricultural IoT gateway CRA Risk Assessment Starter

Enter your work email to receive a single-use magic access link. Clicking the link in your email verifies your domain and unlocks all templates.

Key takeaways

This template produces a starter CRA risk assessment mapped to Annex I Part I essential cybersecurity requirements.
The proposed classification is Important, Class I (Annex III, Class I, point 12), where self-assessment under Article 32(2) requires applying harmonised standards in full.
The risk assessment must remain current throughout the support period under Article 13 and undergo review upon substantial product modifications.
A manufacturer replaces every placeholder with what the product actually does before the assessment becomes a technical file.

1. Product classification and conformity route

Article 7, Annex III, Annex IV, Article 32

Product: [your product name]

Proposed classification: Important, Class I (Annex III, Class I, point 12: Routers, modems intended for the connection to the internet, and switches)

Justification: The gateway terminates the farm network and connects it to the internet, which places it under Annex III, Class I, point 12 (routers, modems and switches intended for connection to the internet). Sensor endpoints that only report to the gateway are assessed as default-class components of the same product.

Conformity route: Article 32(2). Self-assessment requires applying harmonised standards in full, otherwise a notified-body route applies

Standards to apply: ETSI EN 303 645; EN 18031-1

Decision owner: [name, role]
Decision date: [date]

Note

Classification drives everything downstream, so settle it before writing the assessment. Check whether any component of your product is separately listed, and record who signed the decision and when. If your product is marketed with a function listed in a higher class, that class wins.

2. Asset inventory

Annex I Part I (1), Article 13(3), Annex VII

Asset	Type	Classification	Why it matters
Field gateway firmware	component	internal	Boot chain, OS and application firmware running on the gateway.
LPWAN sensor link	network	internal	LoRaWAN/NB-IoT radio link between field sensors and the gateway.
Cloud backhaul channel	network	confidential	TLS uplink carrying telemetry to the farm-management backend.
Agronomic telemetry	data	confidential	Soil, yield and machinery data that reveals commercially sensitive farm performance.
Device provisioning credentials	data	restricted	Join keys and device certificates stored on the gateway.
Remote configuration function	function	internal	Over-the-air configuration and irrigation/actuator control paths.
Farm operator account	user related	confidential	Operator identity and access rights in the management app.

Assets to add: [anything specific to your architecture, such as third-party services, hardware security modules or region-specific data stores]

Note

An asset is anything an attacker would want to reach, break or abuse. Delete rows that do not exist in your product and add the ones that make yours different, since generic inventories produce generic threats. Classify each asset by the harm its exposure would cause rather than by where it happens to be stored.

3. Threat analysis (STRIDE)

Annex I Part I (2), Article 13(2)

Threat	STRIDE	Asset	L / I	Annex I ref
An attacker exploits known, not fixed vulnerabilities in the product under review.	elevation of privilege	Field gateway firmware	high / high	ANNEX I Part I (2)(a)
An attacker exploits a vulnerability for which a security update is available but not installed.	elevation of privilege	Field gateway firmware	high / high	ANNEX I Part I (2)(c)
An attacker exploits a weakness in the default configuration of the product under review.	elevation of privilege	Field gateway firmware	high / high	ANNEX I Part I (2)(b)
An attacker discloses confidential data transferred to or from the product under review.	information disclosure	Cloud backhaul channel	medium / high	ANNEX I Part I (2)(e), ANNEX I Part I (2)(m)
An attacker tampers with data transferred to or from the product under review.	tampering	LPWAN sensor link	high / high	ANNEX I Part I (2)(f), ANNEX I Part I (2)(m)
An attacker discloses confidential data stored in the product under review.	information disclosure	Device provisioning credentials	medium / high	ANNEX I Part I (2)(e)
An attacker gains unauthorized access to the product under review.	elevation of privilege	Remote configuration function	high / high	ANNEX I Part I (2)(d)
An attacker impacts the availability of basic or essential functions after an incident.	denial of service	Field gateway firmware	medium / high	ANNEX I Part I (2)(h)
An attacker performs a security-relevant activity that is not recorded or monitored by the product under review.	repudiation	Remote configuration function	medium / medium	ANNEX I Part I (2)(l)
An attacker extracts remaining data because the product cannot be reset to its original state.	information disclosure	Agronomic telemetry	medium / high	ANNEX I Part I (2)(b)

Note

Each threat is tied to an asset and to an Annex I Part I essential requirement, which is what an authority will ask you to evidence. Likelihood and impact here are starting values from the CRA threat catalogue. Re-score them against your own deployment: an interface that is unreachable in your architecture is not a medium risk just because the catalogue says so.

4. Risk criteria

Annex I Part I (1), Article 13(3), Annex VII

Scale	Level	Score	Meaning
likelihood	Rare	1	Exceptional occurrence. Highly unlikely during the product lifecycle.
likelihood	Unlikely	2	Could occur, but only under limited circumstances or with significant effort.
likelihood	Possible	3	Realistic occurrence under credible attack conditions.
likelihood	Likely	4	Expected to occur in multiple realistic scenarios or repeated attempts.
likelihood	Almost Certain	5	Expected to occur frequently or with minimal attacker effort.
impact	Negligible	1	Minimal operational disruption and no meaningful cybersecurity consequence.
impact	Minor	2	Limited disruption or localized loss with low recovery effort.
impact	Moderate	3	Noticeable service disruption, data exposure, or recovery effort requiring management attention.
impact	Major	4	Severe business disruption, major data compromise, or significant recovery cost.
impact	Catastrophic	5	Critical operational failure, widespread compromise, safety implications, or major regulatory impact.

Note

Document the scales before you score anything, otherwise the scoring is unfalsifiable. These are the default five-by-five scales. Adjust the wording so it reflects consequences your organisation actually recognises, and state your risk acceptance threshold explicitly.

5. Risk treatment and mitigations

Annex I Part I (2), Article 13(1)

Field gateway firmware: Address known exploitable vulnerabilities before release and maintain an effective vulnerability management process.
Field gateway firmware: Ensure timely deployment of security updates and monitor update compliance.
Field gateway firmware: Harden default settings, minimise enabled services, and require secure initial configuration.
Cloud backhaul channel: Terminate the backhaul in mutually authenticated TLS and reject downgrade to unauthenticated transports.
LPWAN sensor link: Authenticate and integrity-protect sensor frames so spoofed readings cannot drive irrigation or dosing actuators.
Device provisioning credentials: Hold join keys in a secure element or encrypted store rather than in flash accessible over the debug port.
Remote configuration function: Require authenticated, rate-limited sessions for actuator and configuration commands.
Field gateway firmware: Ensure the gateway degrades to safe local operation when the backhaul is unavailable during a growing season.
Remote configuration function: Log and monitor security-relevant events by default and protect monitoring evidence.
Agronomic telemetry: Provide a factory reset that erases tenant telemetry and credentials before equipment resale.

For each risk, record: treatment (accept / mitigate / transfer / avoid), the control that implements it, the residual score after treatment, and the owner.

Accepted risks: [list, with the justification and who accepted them]

Note

A mitigation that is not implemented is not a mitigation. Point each line at a real control, a configuration default or a design decision you can evidence. Accepted risks are legitimate, but they need a named accepter and a reason that survives scrutiny.

6. Vulnerability handling and reporting readiness

Annex I Part II, Article 13(8), Article 14

Coordinated vulnerability disclosure contact: [security.txt URL, security contact]

Support period: [end date, per Article 13(8)]

SBOM: [format, where it is maintained]

Article 14 reporting: actively exploited vulnerabilities and severe incidents are reported to ENISA and the CSIRT within 24 hours (early warning) and 72 hours (notification).

Named responsible person: [name, role]

Note

The risk assessment is one half of Annex I. Part II obligations run for the whole support period. The reporting path has to exist before you place the product on the market, ready ahead of your first exploited vulnerability.

Start this assessment in CVD Portal

Create the product and CVD Portal pre-fills this asset inventory, the matching STRIDE threats and your risk criteria, ready to review and adjust.

Start the assessment

Frequently asked questions

Skip the copy-paste

CVD Portal seeds this assessment into a live product, then tracks the classification, risk treatment and conformity route.

Start the assessment

Related templates

EU CVD Policy Template

A CVD policy template specifically written for EU manufacturers placing products on the European market. References EU-specific obligations (CRA, NIS2 intersection, ENISA), using terminology aligned with EU regulatory guidance.

CRA Technical Documentation Template (Annex VII)

A structured template for the technical file required by Article 31 and Annex VII of the EU Cyber Resilience Act. Covers the required content areas, from product description and cybersecurity risk assessment through support period justification, standards applied, test reports, and the EU Declaration of Conformity.

EU Declaration of Conformity Template (CRA Annex V)

A field-by-field EU Declaration of Conformity template structured on CRA Annex V. Each section covers one required element of the declaration, from product identification through to signature, with guidance on Article 28 obligations and the simplified Annex IX option.

This template is part of the EU Cyber Resilience Act guide, which explains Regulation (EU) 2024/2847 article by article.