← Industry Guides
MaritimeCRA Guide

EU Cyber Resilience Act Guide for Port & Logistics Automation System Vendors

Important — Class I (logistics software); Class II (automated handling equipment control systems)

Port and logistics automation vendors supplying terminal operating systems (TOS), automated container handling equipment, vessel traffic services software, and cargo tracking platforms to EU ports face CRA obligations as manufacturers of products with digital elements. EU ports are classified as critical infrastructure under multiple frameworks including the CER Directive and NIS2, making supply chain cybersecurity a regulatory obligation for port operators — and therefore a procurement requirement for their automation vendors. The CRA deadline of September 2026 coincides with accelerating port automation investment across EU member states.

Article 13Article 14Annex IAnnex IIIArticle 10Article 11
Deadline: September 2026Classification: Important — Class I (logistics software); Class II (automated handling equipment control systems)

CRA Scope and Classification for Port Automation

Port and logistics automation products placed on the EU market — including terminal operating systems (TOS), automated stacking crane control systems, automated guided vehicle (AGV) management systems, vessel traffic service (VTS) software, gate automation systems, and port community systems (PCS) — are products with digital elements under Article 3(1). Classification requires function-specific analysis: AGV management systems and automated crane control systems that directly command physical equipment carrying multi-ton cargo loads are strong candidates for Class II Important Products due to their safety-critical function. TOS platforms and logistics optimisation software with no direct equipment control may qualify as Class I. VTS software used by port authorities for maritime traffic management may qualify as Class II given its role in vessel safety within port approaches. Vendors must document classification analysis for each product line.

CRA reference:Article 3(1), Annex III

Technical Security for Port Automation Infrastructure

Port automation systems operate at the intersection of OT (operational technology) and IT networks, with complex integrations between crane control systems, AGV fleets, cargo management databases, customs systems, and shipping line interfaces. Annex I requirements include: implementing authenticated and encrypted communications between all system components — crane controllers, AGV fleet management, TOS, and external carrier interfaces; eliminating default credentials and implementing strong authentication for all operator and maintenance interfaces; providing firmware and software update mechanisms that can be applied during planned maintenance windows without disrupting continuous port operations; implementing network segmentation isolating OT crane and AGV control networks from IT logistics management and external carrier interfaces; providing comprehensive audit logging of all cargo movements, equipment commands, and access events; and maintaining SBOMs for all software components including crane control PLCs, AGV navigation software, and TOS application layers.

CRA reference:Annex I Parts I and II

CVD Policy Under Article 13 for Port Technology Vendors

Article 13 requires a published CVD policy. Port automation systems have attracted increasing attention from cybersecurity researchers following high-profile attacks on port infrastructure (e.g. the 2017 NotPetya attack on Maersk's port operations). The CVD policy must address: dedicated security reporting channels for researcher disclosure; coordination with European Maritime Safety Agency (EMSA) and relevant maritime CSIRTs for vulnerabilities with port safety implications; notification procedures for port authority customers when security updates are available; and the operational challenge that port security patching must accommodate continuous terminal operations. The policy should specify interim mitigation procedures for critical vulnerabilities that cannot be patched during ongoing terminal operations, including network isolation measures and enhanced monitoring. For VTS systems, coordination with national maritime authorities is appropriate.

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

Article 14 Incident Reporting for Critical Maritime Infrastructure

Article 14 requires CSIRT notification within 24 hours of confirmed active exploitation. For port automation vendors, exploitation scenarios — disruption of TOS causing port congestion, manipulation of AGV navigation creating collision risks, compromise of VTS causing maritime traffic management failures — can have cascading impacts on supply chains and maritime safety across multiple EU member states, particularly at major hub ports like Rotterdam, Hamburg, or Antwerp. Vendors must maintain incident response capabilities that can assess the scope of exploitation across the installed customer base rapidly and generate CSIRT notifications within the 24-hour window. For incidents affecting VTS or safety-critical equipment control, simultaneous notification to maritime safety authorities and port authority operations centres is warranted. Pre-established incident communication protocols with key port operator customers are essential.

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

Conformity Assessment and Port Operator Procurement

Class II port automation products — automated equipment control systems and safety-critical VTS platforms — require notified body assessment. Class I logistics software may use self-declaration against harmonised standards, with IEC 62443 being the most applicable framework for operational technology components. EU port operators, as NIS2-regulated critical infrastructure entities, must assess the cybersecurity of their supply chain under NIS2 Article 21. CRA-compliant products with CE marking provide the assurance level that port procurement teams and national port security authorities require. Major EU port authorities are expected to incorporate CRA compliance requirements into automation procurement specifications, and vendors who achieve compliance early will benefit from a competitive advantage in tender processes. Technical file documentation should be structured to support port operator supply chain security questionnaires.

CRA reference:Article 24, Article 25, 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 Port & Logistics Automation System Vendors.

Start your free portal

Frequently asked

Our TOS platform interfaces with customs authorities and shipping lines through EDI and API connections. Are these external interfaces in scope?+

Yes. All external interfaces — including EDI connections to customs systems, APIs to shipping line booking platforms, and data feeds from vessel tracking services — are in scope for Annex I security assessment. Your technical file must enumerate these interfaces, document the authentication and encryption mechanisms used, and assess the security implications of data received from external partners. For customs system interfaces, the security requirements of the customs authority should be documented as a security requirement for the interface. Supply contracts with data partners should include security requirements consistent with your Annex I obligations, particularly for interfaces carrying cargo manifest or container tracking data.

Our automated crane control system uses proprietary OT protocols. How do we demonstrate Annex I compliance for protocols that predate security standards?+

Annex I requires security proportionate to the risk, taking into account the state of the art. For legacy OT protocols without native security support, the approach is compensating controls with documentation: deploy encrypted gateways or protocol translators at the boundary between secure OT management networks and legacy field protocols; implement network segmentation isolating legacy protocol traffic; deploy anomaly detection monitoring OT traffic for unexpected commands; and document the risk assessment justifying the compensating approach. For next-generation product versions, migrate to protocols with native security support (e.g. OPC-UA with security policies, authenticated Modbus extensions). Include the migration roadmap in your product security strategy documentation.

A ransomware attack on a port operator disrupted our TOS software. As the vendor, what are our Article 14 obligations?+

Article 14 is triggered when you become aware of an actively exploited vulnerability in your product. If the ransomware attack exploited a specific vulnerability in your TOS software, then yes — you must notify the CSIRT within 24 hours of becoming aware of that exploitation. If the ransomware accessed the TOS through a vulnerability in third-party infrastructure (Windows servers, VPN) rather than in your software, your Article 14 obligation may not be triggered, but you should investigate actively and document your findings. In either scenario, you should offer immediate technical assistance to the affected port operator and assess whether the attack vector is present in other customer deployments. Clear, timely communication with the affected customer and proactive assessment of other customers' exposure is both a reputational and regulatory best practice.

Need a CVD policy template for Port & Logistics Automation System Vendors?

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

Browse templates →