Penetration testing of connected agricultural robots and machinery

Before the service: You are developing a connected AI or robotic solution for agriculture or food production, but you do not know how well it would withstand a cyberattack. Customers, investors and new EU regulations increasingly ask how the product is protected, and you have no independent test results to show. After the service: You receive documented findings on the vulnerabilities identified within the agreed test scope, how serious they are and in which order to fix them. A penetration test cannot show that a product is free of vulnerabilities; it shows what was found within the agreed scope and time. You have an independent test report from RISE that you can use in your development work, in your risk assessment and in discussions with customers and partners. Depending on which rules apply to your product, the results can also be useful input when you prepare for cybersecurity requirements such as those in the EU Machinery Regulation (EU) 2023/1230, which applies from 20 January 2027, and the Cyber Resilience Act (EU) 2024/2847, whose reporting obligations for manufacturers apply from 11 September 2026 and whose main requirements apply from 11 December 2027. Finding and fixing weaknesses early saves money compared with dealing with an incident in the field. Please note that the service does not certify the product or confirm that it complies with any regulation; for compliance support, see the related services below.

The penetration test is carried out with a RISE method based on the Penetration Testing Execution Standard (PTES), in three steps: · Planning: Together we agree on what to test, the type of test, test windows, safety precautions and which information and access you will provide. · Testing: RISE simulates realistic attacks on the agreed parts of your product, using both automated tools and manual testing. · Reporting: You receive a written report with the results and recommendations. Duration: The initial project setup, including preparation of the test environment, normally takes one to two days. The main testing activities are usually completed within a few days and potential follow-up testing afterwards. After all testing activities have been finalized, the report writing and review process typically takes around two weeks. All together the service typically takes three to five weeks from project initiation to delivery of the final report, depending on the complexity of the product and the scope of testing. Location: The testing is carried out at your premises or remotely where applicable, provided the necessary access is available. Depending on customer preferences, product size, complexity, and other practical considerations, testing may also be performed partly or entirely at RISE test laboratories. Where relevant, the whole system or specific parts of the system can be evaluated at a RISE test facility. Which customers can receive the service within agrifoodTEF follows the project's eligibility rules. Timing: Testing of digital systems is generally not tied to the growing season. If the assessment requires machinery operating in a field environment, the testing schedule is planned together with you based on machine availability and operational requirements. What you provide: · Access to the product to be tested (the machine, robot or a representative test set-up), including its network interfaces, apps and the cloud services in scope · Technical documentation, such as system architecture, interfaces, software versions and configuration · Test accounts and any credentials needed for the agreed tests · A contact person who coordinates the testing on your side · Permission from third-party providers whose systems are included in the test, for example cloud or telecom services · Support installation and setup of the system · Source code in specific cases What you receive: a written report that includes: · The agreed test scope, the product versions tested and the limitations of the test · The vulnerabilities identified and how serious they are (for example rated with CVSS) · Practical recommendations for how to fix them, in order of priority · Insights into how the product responds to the simulated attacks Repetitions: after you have fixed the vulnerabilities, a retest can be agreed separately to confirm that the fixes work.

The service is adapted to your product and needs. Examples of options: What to test · The machine itself: control units, internal machine networks (for example CAN-based networks), service and diagnostic ports, and firmware. · Wireless communication: Wi-Fi, Bluetooth, radio links and remote controls. · Apps, web portals and cloud services used to control the machine or to handle farm data, including their interfaces (APIs). · Connected sensors and IoT devices that are part of the solution. How deep to test · Vulnerability scanning: a quicker check for known weaknesses. Even scanning can affect control systems and communication, so possible effects on the machine are assessed during planning. · Full penetration test: realistic attack scenarios, including manual testing and attempts to exploit the weaknesses found. · Grey- or white-box testing: the tester needs to be provided with some or full knowledge of the system, for example documentation and source code before the testing. Combination with other services · The penetration test can be combined with RISE’s services for compliance with cybersecurity standards and regulations (S00400), compliance assessment for robotic machines (S00009), and testing of GPS/GNSS-based products (S00372) and 4G/5G-connected equipment (S00374). Limitations and what you should know in advance · Product maturity: the product must be working, either in operation or in a realistic test set-up. Prototypes can be tested, but the limitations are agreed in advance. · Safety: tests that could make a machine move or change its behaviour are only carried out under agreed safety precautions, for example in a closed area without people or animals nearby. · Third-party systems: cloud, telecom and other third-party services are only tested to the extent the provider allows. · Proprietary protocols: highly customised systems or proprietary communication protocols may require more preparation time. · Operational constraints: tell us early about restrictions such as limited test windows or periods when the machine must not be disturbed. · Not included: fixing the vulnerabilities, certification, or confirmation that the product complies with a regulation. The report gives recommendations for how to fix what was found.