When a retail company suffers a cyberattack, the consequences are serious: data is compromised, operations are disrupted, and reputational damage follows. Recovery is measured in days or weeks. When a transportation infrastructure system is successfully attacked, the consequences can be immediate and physical, because the system is operational technology (OT) driving physical processes, not merely an IT database. A tunnel ventilation system that stops responding to commands during a fire event. Traffic signals that display contradictory instructions at a busy intersection. Enforcement data that is tampered with, making months of legally admissible evidence inadmissible overnight.<\/p>\n
This is why cybersecurity in transportation infrastructure cannot be treated the way it is treated in most enterprise IT environments. The threat model is different, the consequences of failure are different, and the technical environment presents challenges that standard IT security approaches were not designed to handle.<\/p>\n
For most of their operational history, transportation infrastructure systems were physically isolated. A tunnel control system ran on proprietary hardware, communicated over dedicated cabling, and had no connection to the outside world (effectively air-gapped). Security through isolation was imperfect, but it was genuinely effective against the vast majority of threats that existed at the time.<\/p>\n
That isolation is gone. Modern traffic management platforms connect to cloud analytics services. Enforcement systems transmit data to central processing facilities over public networks. Roadside units communicate with vehicles (V2X \/ C-ITS), with each other, and with operations centres in real time. Remote monitoring and maintenance access means that a technician can connect to a field device from an office or a laptop, typically over a VPN or vendor remote-access link, without being physically present at the installation.<\/p>\n
Each of these connectivity requirements is operationally justified. Remote access significantly reduces maintenance costs, and cloud analytics enables capabilities that local processing cannot economically match. Vehicle-to-infrastructure communication is a prerequisite for the safety applications that modern transportation networks depend on. The connectivity is not going away. The question is whether the security architecture was designed to handle it, or whether it was added as an afterthought to a system that was not built with it in mind.<\/p>\n
Most transportation infrastructure was designed by engineers whose primary expertise is in traffic, structural, or mechanical engineering. Cybersecurity was not a design requirement when most of the currently operational systems were specified. The result is that a significant proportion of active transportation infrastructure relies on operational technology built for reliability and availability (the OT domain now framed by the IEC 62443 industrial-security standard), with security considerations addressed only minimally, if at all.<\/p>\n
This creates a specific vulnerability profile. Many field devices run embedded software that cannot be patched without physical access or system downtime. Communication protocols used between subsystems were designed for reliability on closed networks and do not include authentication or encryption (for example legacy serial\/fieldbus links, or Modbus and early NTCIP profiles with no native security). Default credentials on installed hardware are often left unchanged from factory settings because the device is on a network assumed to be isolated – a practice the EU Cyber Resilience Act will effectively prohibit for new products. Configuration data is sometimes stored in plaintext because the system predates any expectation that the storage medium could be accessed remotely.<\/p>\n
None of these are the result of negligence. They reflect the design assumptions of a different era, applied to systems that are now connected to networks their designers never anticipated. The problem is compounded by asset lifecycles. Transportation infrastructure has a long service life. Hardware installed fifteen years ago is still operational and will remain operational for another decade. Upgrading the cybersecurity posture of that hardware is technically constrained and often expensive.<\/p>\n
The IT systems that most organisations are familiar with (such as standard office networks, email platforms, and enterprise software) operate under an availability model that tolerates planned downtime for patching and maintenance. A server that needs to restart for a security update can be scheduled for a maintenance window and applications can be taken offline temporarily without physical consequences.<\/p>\n
Operational technology in transportation infrastructure does not have this flexibility. A tunnel management system cannot be taken offline for a software update during peak hours; a traffic signal controller that needs to restart mid-cycle creates a safety event. Enforcement systems that go offline lose evidential continuity. The availability requirement in OT environments is often 99.99%, meaning less than an hour of unplanned downtime per year, so patching is tied to redundancy and scheduled maintenance windows rather than automatic updates, and even planned downtime requires careful coordination with operational teams.<\/p>\n
This means that standard enterprise IT security practices, regular patching cycles, centrally pushed software updates, and aggressive monitoring that generates high volumes of alerts requiring human review do not translate directly into OT environments without adaptation – passive, OT-aware intrusion detection and network anomaly monitoring are usually preferred to intrusive active scanning. Security measures that are routine in an office network can be genuinely disruptive when applied to a tunnel control system or a signal management platform.<\/p>\n
Vendors who propose the same security architecture for transportation infrastructure that they use for enterprise IT deployments reveal something important about how deeply they understand the environment they are working in.<\/p>\n
The cybersecurity posture of a transportation infrastructure deployment is largely determined before a single cable is laid. The hardware selected, the software platform, the communication protocols, the network architecture, and the access control model: these decisions, made during the design and specification phase will determine the security envelope of the completed system. Retrofitting security to a system not designed for it is especially expensive. This is precisely the \u201csecurity by design and by default\u201d principle that the EU Cyber Resilience Act (Regulation (EU) 2024\/2847) now makes a legal obligation for products with digital elements placed on the EU market.<\/p>\n
This has direct implications for procurement, since the cybersecurity requirements in a tender document must to go beyond mere certification compliance. ISO 27001 certification tells you that a vendor has a documented information security management system (and, for OT, IEC 62443 certification of both the product and the integrator\u2019s processes is more telling), but it does not tell you how authentication is implemented between field devices and the central platform; whether communication between roadside units and the control centre is encrypted end-to-end (for example mutual TLS with per-device certificates), or how the system detects and isolates a compromised component before it affects the broader network.<\/p>\n
Hardware provenance is also a genuine consideration in critical infrastructure. Equipment manufactured in jurisdictions with different regulatory frameworks governing data access and security disclosure obligations poses risks that are difficult to evaluate and manage once the hardware is installed. The supply chain question, which includes hardware vendors, software components, and communication platforms, belongs in the security assessment alongside the architecture questions. Under NIS2 this is explicit: operators must manage supply-chain and vendor risk, and a software bill of materials (SBOM) – now expected under the Cyber Resilience Act – is becoming the baseline evidence for it.<\/p>\n
In the European Union, the NIS2 Directive (Directive (EU) 2022\/2555) substantially expanded the scope of cybersecurity obligations for operators of essential services, and transportation infrastructure (road, rail, air and water transport are named in Annex I) falls explicitly within its scope. Operators are required to implement appropriate technical and organisational measures to manage cybersecurity risks – the baseline set of measures is detailed in Commission Implementing Regulation (EU) 2024\/2690 -, report significant incidents within defined timeframes (a 24-hour early warning and a 72-hour incident notification to the national CSIRT), and ensure that their supply chains meet adequate security standards. Member states began enforcement from late 2024, with direct senior-management accountability and fines of up to \u20ac10 million or 2% of global annual turnover, and the implications for infrastructure operators and their technology vendors are material.<\/p>\n
Two newer EU instruments matter just as much for procurement. The Cyber Resilience Act (Regulation (EU) 2024\/2847) sets mandatory cybersecurity requirements for \u201cproducts with digital elements\u201d – which covers the controllers, roadside units, cameras and software in a transport deployment – mandating secure-by-default configuration, no hard-coded default passwords, coordinated vulnerability handling and security updates for the support period, evidenced by CE marking (its main obligations apply from 2027). The Critical Entities Resilience (CER) Directive (Directive (EU) 2022\/2557) adds physical-resilience duties for the same transport operators, complementing NIS2 on the cyber side. And the Cybersecurity Act (Regulation (EU) 2019\/881) established ENISA and the EU cybersecurity certification framework – including the EUCC scheme – against which OT products can be certified. Read together: NIS2 governs the operator, the CRA governs the product, CER governs physical resilience, and the Cybersecurity Act governs certification.<\/p>\n
GDPR (the General Data Protection Regulation, Regulation (EU) 2016\/679) comes into play whenever transportation systems collect data that can be linked to identifiable individuals. Enforcement cameras that capture vehicle registration plates, V2X systems that communicate with specific vehicles, and monitoring platforms that record movement patterns: all of these involve personal data under EU law. Data minimisation, purpose limitation, and appropriate technical safeguards are not optional additions; they are legal requirements that affect how systems must be designed, not just how they are operated.<\/p>\n
Neither NIS2 nor GDPR (nor the CRA) compliance is primarily a documentation exercise. The compliance status of a transportation system is a function of how it was designed and built, which means the time to address it is during specification and procurement rather than after deployment.<\/p>\n
A transportation infrastructure system with a mature cybersecurity architecture exhibits several characteristics evident during procurement evaluation. The network is segmented into IEC 62443 zones and conduits, with a demilitarised zone (DMZ) between the IT and OT networks, so that a compromise in one zone (a public-facing web interface, a maintenance access point, a field device) cannot propagate freely to other zones. Authentication between system components is explicit rather than assumed; devices identify themselves to each other using per-device credentials or certificates (mutual TLS) rather than relying on network location as a proxy for trust. Logging is comprehensive enough that a security event can be reconstructed after the fact, ideally aggregated into a SIEM, supporting both incident response and legal proceedings if required. The system should be able to detect anomalous behaviour in field devices and isolate them without taking the broader system offline.<\/p>\n
Perhaps most importantly, security has been considered in the context of what happens when things go wrong. Fail-safe and fail-secure behaviour during a cyberattack, specifically maintaining safety-critical functions while isolating and recovering compromised components, requires that the system was designed with that scenario in mind from the outset.<\/p>\n
Procurement evaluation processes that ask vendors to describe their security architecture in operational terms, rather than simply providing certification documentation, surface the difference between vendors who have genuinely embedded security in their design practice and those who have not.<\/p>\n
Lillyneir\u2019s approach to cybersecurity in transportation systems starts at the architecture design phase and is built around the specific operational constraints of OT environments: availability requirements, long asset lifecycles, multi-vendor subsystem integration, and the regulatory obligations applicable in each deployment jurisdiction. If cybersecurity is a consideration in a current or upcoming project evaluation, it is a conversation worth having early. As an intelligent transport systems (ITS) integrator, Lillyneir designs to IEC 62443, engineers NIS2- and CRA-aligned security by design (network segmentation, mutual authentication, SBOM and coordinated vulnerability handling, secure remote access), and maps each requirement to the specific EU obligation – NIS2, the Cyber Resilience Act, the CER Directive, the Cybersecurity Act and GDPR – that applies in your deployment jurisdiction.<\/p>","protected":false},"excerpt":{"rendered":"
Transportation infrastructure is critical (essential) infrastructure under EU law. A cyberattack can halt traffic and disable tunnel safety systems, not just leak data – which is why NIS2, the Cyber Resilience Act and GDPR now shape how these OT systems must be designed, not only operated.<\/p>","protected":false},"author":4,"featured_media":2270,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_seopress_titles_title":"Why transportation infrastructure needs different cybersecurity","_seopress_titles_desc":"Transportation infrastructure is critical infrastructure. A cyberattack can halt traffic and disable tunnel safety systems, not just data.","_seopress_robots_index":"","_seopress_robots_follow":"","_seopress_robots_imageindex":"","_seopress_robots_snippet":"","_seopress_robots_primary_cat":"","_seopress_robots_breadcrumbs":"","_seopress_robots_freeze_modified_date":"","_seopress_robots_custom_modified_date":"","_seopress_robots_canonical":"","_seopress_social_fb_title":"","_seopress_social_fb_desc":"","_seopress_social_fb_img":"","_seopress_social_fb_img_attachment_id":0,"_seopress_social_fb_img_width":0,"_seopress_social_fb_img_height":0,"_seopress_social_twitter_title":"","_seopress_social_twitter_desc":"","_seopress_social_twitter_img":"","_seopress_social_twitter_img_attachment_id":0,"_seopress_social_twitter_img_width":0,"_seopress_social_twitter_img_height":0,"_seopress_redirections_value":"","_seopress_redirections_enabled":"","_seopress_redirections_enabled_regex":"","_seopress_redirections_logged_status":"","_seopress_redirections_param":"","_seopress_redirections_type":0,"_seopress_analysis_target_kw":"","_seopress_news_disabled":"","_seopress_video_disabled":"","_seopress_video":[],"_seopress_pro_schemas_manual":[],"_seopress_pro_rich_snippets_disable_all":"","_seopress_pro_rich_snippets_disable":[],"_seopress_pro_schemas":[],"footnotes":""},"categories":[8],"tags":[],"class_list":["post-2269","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog-article"],"_links":{"self":[{"href":"https:\/\/lillyneir.com\/zh\/wp-json\/wp\/v2\/posts\/2269","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/lillyneir.com\/zh\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/lillyneir.com\/zh\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/lillyneir.com\/zh\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/lillyneir.com\/zh\/wp-json\/wp\/v2\/comments?post=2269"}],"version-history":[{"count":1,"href":"https:\/\/lillyneir.com\/zh\/wp-json\/wp\/v2\/posts\/2269\/revisions"}],"predecessor-version":[{"id":2271,"href":"https:\/\/lillyneir.com\/zh\/wp-json\/wp\/v2\/posts\/2269\/revisions\/2271"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/lillyneir.com\/zh\/wp-json\/wp\/v2\/media\/2270"}],"wp:attachment":[{"href":"https:\/\/lillyneir.com\/zh\/wp-json\/wp\/v2\/media?parent=2269"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/lillyneir.com\/zh\/wp-json\/wp\/v2\/categories?post=2269"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/lillyneir.com\/zh\/wp-json\/wp\/v2\/tags?post=2269"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}