Cybersecurity has rapidly become a key component of new rail projects. It’s now rare to see a tender that doesn’t include security considerations, and that’s a great sign of progress. But as more projects embrace cybersecurity, we’ve also seen patterns emerge, areas where even well-intentioned efforts can fall short. By recognizing these blind spots early, project teams can turn their cybersecurity vision into practical, lasting protection.

Here are three of the most common gaps we’ve seen, and how to avoid them.

1. Referencing Standards Without Setting the Compass

Standards like IEC 62443 or CENELEC TS 50701 provide a solid starting point, and it’s great to see them referenced more frequently. But one common pitfall is stopping there: mentioning a standard without defining how it should apply. For example, a requirement might simply state “follow IEC 62443,” but without specifying a target Security Level (SL), teams are left to guess what success looks like. 

What to do instead:

• Be specific about scope and intent. When referencing IEC 62443, cite the exact standard in the series and pair it with a clear objective. For example: “Achieve SL 3 for operational zones that include signaling equipment, in accordance with IEC 62443-3-3.”
• Clearly articulate your risk tolerance and acceptable risk levels. Since most standards follow a risk-based approach, your input is essential for meaningful application.

2. Listing Controls Without Context

It's common to see cybersecurity requirements that include an inventory of controls: firewalls, antivirus, intrusion detection, and logging. These are essential components, but the real value comes when they’re described in an operational context. For instance, a requirement might call for a firewall, but omit details on security zones, rule management, or change procedures. In those cases, implementers may install the tool without integrating it meaningfully into the system’s architecture. Thinking through how each control fits into day-to-day operations prevents security from becoming an isolated layer.

What to do instead:

• Describe controls as part of a system, not standalone tools. Say more than “include a firewall.” Instead: “Deploy a firewall at the zone boundary between passenger Wi-Fi and onboard control networks, configured to enforce zone separation.”
• Ensure that you refer to specific features when making requirements. Mere mention of a tool is often insufficient; clarity and specificity are essential to ensure that the requested control serves its intended purpose. For example, requiring an IDS without further detail can result in the deployment of a generic IT IDS, which may be ineffective in rail environments due to their specialized nature.
• Link controls to threats. Use threat modeling to show why each control is needed and how it mitigates risk.

3. Skipping Validation Steps

Many projects lay out strong requirements - on paper. But they fall short when it comes to validation. Cybersecurity often gets treated like a checkbox during the design phase, with little follow-up during commissioning or operation. Without structured reviews and testing, there’s no way to ensure that requirements have been met, or that they continue to be effective as the system evolves.

What to do instead:

• Build cybersecurity gates into the lifecycle. Include reviews at key milestones: architecture design, factory acceptance testing, site acceptance testing, and post-deployment audits.
• Define what “done” looks like. Don’t just say “verify firewall is installed”; say “verify that the firewall is actively enforcing key policies, and that logs show policy enforcement activity is monitored and reviewed weekly for three months post-launch.”
• Test in the real world. Whether through penetration testing, red-teaming, or hands-on commissioning checks, validate the system in conditions that resemble day-to-day operations.

Building Cybersecurity That Lasts

Greenfield rail projects offer a unique opportunity: a blank canvas to build cybersecurity from the ground up. By moving beyond broad references and checklists and instead focusing on clarity, integration, and validation, teams can set themselves up for success.

The industry is already on the right path. With just a few targeted improvements, we can ensure that cybersecurity requirements don’t just exist, they deliver real-world protection, today and well into the future.

‍