← Industry Guides
AgricultureCRA Guide

EU Cyber Resilience Act Guide for Livestock Monitoring & Precision Livestock Farming

Standard Default (most PLF sensors and wearables); Important Class I if linked to automated feeding or medication systems

Precision livestock farming (PLF) technology vendors — supplying connected ear tags, activity monitors, automated milking systems, indoor climate sensors, and livestock health monitoring platforms to EU farmers — must comply with the CRA for their network-connected products. While agricultural technology has not traditionally been considered high-risk from a cybersecurity perspective, the increasing connectivity of livestock management systems and their role in food production and animal welfare creates obligations that vendors must address. The agricultural sector's CRA compliance journey is typically earlier-stage than industrial sectors, making now the critical time to establish foundations.

Article 13Article 14Annex IArticle 10Article 11Article 3
Deadline: September 2026Classification: Standard Default (most PLF sensors and wearables); Important Class I if linked to automated feeding or medication systems

CRA Scope for Precision Livestock Farming Technology

Precision livestock farming products placed on the EU market — including RFID and GPS ear tags with cellular data transmission, accelerometer-based activity and rumination monitors, automated milking system management software, indoor climate monitoring sensor networks, electronic identification (EID) readers with cloud connectivity, and livestock health monitoring platforms — are products with digital elements under Article 3(1) where they incorporate internet connectivity or communication with other networked devices. The CRA classification for most PLF devices will be Default (non-important), subject to standard security requirements. However, automated systems that directly control feeding, medication dispensing, or milking processes — where software errors or cyberattacks could affect animal welfare or food safety — may qualify as Important Products Class I. Vendors should document their classification analysis, noting any integrations with automated control systems.

CRA reference:Article 3(1), Article 7

Technical Security for Agricultural IoT Devices

PLF devices present typical agricultural technology challenges: outdoor deployment with weathering and physical access risks, long battery life requirements constraining available processing power for cryptographic operations, cellular or LPWAN connectivity with limited bandwidth, and deployment by farmers who are not IT professionals. Annex I requirements for PLF vendors include: implementing device authentication for cloud connectivity — using unique device credentials rather than shared secrets; encrypting livestock health and location data in transit; providing firmware update mechanisms that can deliver updates over cellular or LoRaWAN connections automatically; eliminating default shared credentials on farm management platforms; securing APIs used by farm management software and third-party integrations (e.g. veterinary health records, milk recording organisations); and providing clear end-user documentation on network security configuration. The SBOM must cover device firmware and cloud platform components. Data minimisation is particularly important given that livestock location and farm operational data can reveal commercially sensitive farm management practices.

CRA reference:Annex I Parts I and II

CVD Policy Under Article 13 for AgriTech Vendors

Article 13 requires a published CVD policy with a dedicated security reporting channel. For PLF vendors — many of whom are growth-stage companies or established agricultural equipment manufacturers diversifying into digital services — establishing a CVD programme is often a new capability requirement. The CVD policy must specify: a security contact email and machine-readable security.txt file; acknowledgment timelines for vulnerability reports; the process for issuing and communicating security updates to farmer customers who may not actively monitor vendor communications; and coordination with relevant agricultural sector authorities for vulnerabilities with animal welfare implications. CVD Portal provides hosted CVD programme management that meets Article 13 requirements for vendors without dedicated security teams. The policy should also address how customers are notified when end-of-support dates for devices or cloud services are approaching.

CRA reference:Article 13(6), Article 13(7)

Article 14 Incident Reporting for Agricultural Technology

Article 14 requires CSIRT notification within 24 hours of confirmed active exploitation. For PLF vendors, exploitation scenarios are primarily concerned with data access (livestock tracking data, herd health records, farm operational data) and, for automated systems, potential interference with feeding or medication dispensing. The 24-hour notification obligation requires a designated person within the vendor organisation with authority to make regulatory notifications, and pre-established contact details for the relevant national CSIRT. Agricultural technology incidents are less likely than energy or transport sector incidents to trigger concurrent notifications to other regulatory bodies, but for automated feeding or medication systems with animal welfare implications, consultation with relevant veterinary or food safety authorities is prudent. Notification procedures should be documented, tested annually, and include customer notification templates.

CRA reference:Article 14(1), Article 14(2)

Conformity Assessment for Agricultural IoT Products

Most PLF devices qualify as Default-category products and may use manufacturer self-declaration. The most applicable harmonised standard is ETSI EN 303 645 (IoT device cybersecurity), which covers the key requirements for connected agricultural sensors and monitors including default credential elimination, update mechanisms, and vulnerability disclosure. The technical file for PLF products must include: product security architecture documentation; SBOM for device firmware and cloud platform; evidence of security testing including at minimum a structured vulnerability assessment; CVD policy documentation; update and support period policy; and the declaration of conformity. For vendors selling products across multiple EU member states, the technical file may need to be available in multiple languages on request from market surveillance authorities. Agricultural market surveillance authorities are likely to focus on CRA compliance as part of their broader oversight of precision farming technology markets.

CRA reference:Article 24, Article 28, Annex VIII

CVD Portal handles your CRA Article 13 obligations automatically.

Public CVD submission portal, 48-hour acknowledgment tracking, Article 14 deadline alerts, and CSAF advisory generation. Free forever for Livestock Monitoring & Precision Livestock Farming.

Start your free portal

Frequently asked

Our livestock ear tags use LoRaWAN and have very limited processing power. Can we meet Annex I encryption requirements on constrained devices?+

Yes. LoRaWAN v1.1 provides AES-128 encryption and device authentication that is feasible on constrained IoT hardware, including low-power ear tag devices. The CRA's requirement for security measures proportionate to the risk accommodates the technical constraints of embedded agricultural devices — you are not required to implement TLS 1.3 on a microcontroller with 32KB flash. What is required is that: device communications are authenticated and encrypted using appropriate lightweight protocols; device provisioning (key management) is handled securely; and default shared credentials are not used. LoRaWAN v1.1 with proper key provisioning meets these requirements. Document your cryptographic implementation and key management process in the technical file.

We are a small precision farming startup with a team of eight. How do we approach CRA compliance practically?+

Focus on the fundamentals with the resources available: eliminate shared default credentials across all products immediately; implement automatic over-the-air firmware updates if you haven't already; create a security.txt file and basic CVD policy using a hosted platform like CVD Portal; generate an SBOM using open-source SCA tooling (Syft or Trivy) integrated into your build pipeline; and conduct a focused security review of your cloud API and device communication security. Document your threat model — even a brief one — and compile your technical file incrementally over 2025. These steps are achievable for a small team and address the highest-priority CRA obligations. Assign one team member as the designated CRA compliance lead who maintains the technical file and handles CVD and Article 14 obligations.

Our platform stores herd health records including veterinary prescription data. How does GDPR interact with our CRA security obligations?+

Herd health records with veterinary prescription data may include personal data if they relate to identified farmers or farm employees. They may also include information about prescribed veterinary medicines subject to veterinary prescription regulations. Your CRA Annex I security obligations — access control, encryption, audit logging — align closely with GDPR Article 25 data protection by design requirements. Implement strong access controls on health record access, encrypt health data at rest and in transit, maintain access logs, and support data deletion on customer request. For GDPR purposes, determine whether you are a data controller (if you determine the purpose of processing) or processor (if the farmer determines the purpose) — this affects which GDPR obligations fall on you versus the farmer.

Need a CVD policy template for Livestock Monitoring & Precision Livestock Farming?

Download a free CRA-compliant vulnerability disclosure policy and deploy it in minutes.

Browse templates →