Agricultural IoT gateway CRA Risk Assessment Starter
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, a starter asset inventory, a STRIDE threat analysis mapped to Annex I Part I essential cybersecurity requirements, and 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.
1. Product classification and conformity route
Article 7, Annex III, Annex IV, Article 32Product: [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]
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]
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) |
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. |
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]
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 14Coordinated 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]
The risk assessment is one half of Annex I. Part II obligations run for the whole support period, so 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