Jorge Aldegunde is Global Head of Railway Services at DNV, where he leads the company’s systems assurance and cybersecurity work across the rail sector. He sits on the working group drafting IEC 63452, the emerging international rail cybersecurity standard, and is DNV’s cybersecurity representative for NB-Rail, the European association of notified bodies responsible for conformity assessment in rail.
Sam Sherwood-Hale spoke to Jorge Aldegunde about embedding cybersecurity into the Santiago de los Caballeros monorail from the design stage, trialling the draft IEC 63452 standard on a live project, and why GoA4 automation raises the stakes of a successful attack
SSH: The Santiago de los Caballeros monorail is being delivered to GoA4, the highest automation grade, running fully driverless. Does that level of automation change the cybersecurity brief compared with a driver-operated system?
JA: In cybersecurity, much as in safety, we use a risk-based approach built on likelihood, exposure, attack surface and consequence. Because the system is designed from the outset to run at GoA4, fully automated, the severity of any disruption caused by a cyber attack will be far greater than it would be under GoA2 or conventional driver-based operation, even where that operation is supported by technical assistance systems.
GoA4 isn’t new in itself. It’s part of a broader trend in the automation and digitalisation of transport systems, a logical consequence of how much these systems now rely on technical infrastructure. But there’s a key difference from functional safety. In safety, the question is essentially whether an incident can occur. In cyber, the question is when an attack will succeed, not if. So the analysis isn’t really focused on the attack surface itself, it’s focused on consequence.
That’s why we take a holistic approach: the technology layer, but also process and procedure. Preparedness needs to be in place before commissioning, so that once the system is in full operation there are known routines for how to respond. Alongside that sits protection at component level, system level and supply chain level.
In a system built to run automatically, with passengers on board trains and in stations, the key question becomes what happens when an issue affects a train, a station, or the Operations Control Centre, where control is centralised, or when the attack is at system level rather than a single point. In safety, consequences are measured in damage to technical systems and assets, and harm to people, including injuries or casualties. In cybersecurity, we’re also weighing impact on system availability and reliability, since that’s a core part of what a successful attack can take away.
SSH: Cybersecurity has traditionally been treated as something added on to rail projects rather than built in from the start. Is that changing?
JA: Yes, and I think this project is a good illustration of it. In systems engineering more broadly, you’d typically look at reliability, availability, maintainability and safety (RAMS), alongside things like life-cycle costing, electromagnetic compatibility and fire safety. Cybersecurity has traditionally sat outside that, treated 52 INNOTRANS as something complementary rather than integrated into the full life cycle.
What we’re now seeing in emerging regulation is the same risk-based, life cycle approach that underpins safety, from concept through to acceptance, then operations and maintenance, being applied to cyber for the first time. That’s the real change.
On Santiago de los Caballeros, DNV started out as the systems assurance provider under a RAMS-style, concept to-acceptance scope. We then proposed to the different project stakeholders, systems integrators, contractors and the end customer that cybersecurity be incorporated as part of that same scope from the start, rather than being disconnected or only partially connected. As part of that, we chose to work with IEC 63452, a cybersecurity standard for rail that’s still in draft form but is expected to become an international railway cybersecurity standard, potentially in early 2027. Our reasoning was that if this was going to be the benchmark within six months or so, it was worth trialling it now, on a live, greenfield project, so we could learn firsthand what applying it actually means, and feed that experience back into the standard.
Aligning stakeholders around this took time and effort, and it’s still ongoing. It isn’t only a matter of using the same terminology, though that matters too. Different stakeholders come to cyber from different backgrounds: some move across from signalling and safety because of the safety implications, some come from an IT background and are still building their connection to OT, and a smaller group come from OT itself. They don’t all weight the same things as the dominant risk factor, whether that’s supply chain, the human factor, or the purely technical side, which tends to be the instinct for people with a signalling and safety background.
Being a greenfield project helps in one sense, since every component, from telecoms and signalling to rolling stock, is new rather than legacy. But it also means not every stakeholder or contractor started out with the same level of cyber maturity or the same cyber goals, and that alignment remains one of the main challenges of bringing this in from day one.
SSH: The contract runs across design, construction, integration and testing for the monorail. At what point does DNV’s involvement typically end?
JA: Our base proposal mirrors our classical systems assurance, RAMS-style engagement: concept through to systems acceptance. That’s where our baseline scope currently concludes, in the same way it would on a conventional RAMS contract.
Beyond that, we’ve proposed a flexible, optional package to define what a Security Operations Centre (SOC) for the system might look like after commissioning: the technology layers, such as endpoint protection systems, intrusion detection systems, and SIEM (security information and event management) platforms, together with the process and procedure layers and the qualifications needed for the people running it. We’re vendor- and technology agnostic in that proposal. The point isn’t to promote a particular brand or component, but to set out what’s available in the market and how it could be used as a post commissioning layer.
The rationale is that cybersecurity doesn’t really end at commissioning. If you take a snapshot of the system’s cybersecurity case at that point and treat it as settled, it can become obsolete almost immediately once any change is made to switches, routers, firewalls, signalling devices or OCC-related systems, however small. Given that in an OT system the data flowing through the network tends to stay largely consistent over time, there’s also real value in being able to build up a picture of what a normal pattern looks like, and by extension what an attack pattern might look like, which supports the case for continuous monitoring rather than a one-off assessment.
There’s also scope to scale this SOC beyond the monorail itself. The same Operations Control Centre also serves a cable car system already operating in the city, so a SOC built for the monorail could potentially extend to cover both.
The operational and contractual model for this post-commissioning phase isn’t yet fully defined, which is part of the complexity, and the optional scope may or may not ultimately involve DNV operating it directly. The aim is to define what the SOC needs to look like regardless of who eventually operates it.
SSH: Cybersecurity has been named one of InnoTrans’ headline themes this year, alongside AI and autonomous public transport. What’s changed since previous editions to earn it that billing?
JA: I’ve been attending InnoTrans more or less continuously since around 2008, so I’ve seen the trends evolve. The last two years in particular have shown a real change with respect to digital transformation in rail, with cyber and related topics starting to connect as part of a wider picture rather than sitting in isolation.
Cyber is, in a way, coming of age. It’s still a niche area within rail, much as OT is a niche area generally, but there’s a growing level of maturity among stakeholders. Two years ago, there was often little alignment in these discussions, and in some cases not even recognition of the need for it. Conversations could go on without reaching anything close to agreement, more like disconnected satellites than a shared conversation. Cybersecurity regulation is evolving now, and even though that regulatory picture is still complex, you can see stakeholders coming together around it, along with related questions like what cybersecurity by design means for a large enterprise versus an SME, and the human factor as a weak link in the supply chain.
AI is part of the same shift. Narrow applications, such as machine vision used to detect anomalies or isolated objects at stations via CCTV, have existed for a long time, and machine learning has already been used for use cases like maintenance. What’s newer is generative AI and more fully AI-enabled applications, and there’s a cyber dimension to that too: what happens when AI is applied by attackers, and what happens when it’s applied by those defending systems.
There’s also a growing recognition, partly driven by regulation, that cybersecurity isn’t only a cost, but can also be a source of value, and that regulation brings liabilities that sit with senior management, not just with a technical team. The Cyber Resilience Act, for example, applies to products with digital elements, which by now is almost every product. And we’re operating in a geopolitically complex environment, where conflict increasingly takes hybrid forms across multiple operating scenarios at once. For critical sectors like transport, that’s no longer something that can be treated as background noise. Two years ago it wasn’t quite as prominent in these discussions. Now it can’t be skipped.
SSH: InnoTrans has framed this year’s edition around mobility on a global scale, with infrastructure increasingly planned and delivered across borders. Are client standards and delivery teams genuinely crossing borders on a single project when it comes to cybersecurity?
JA: European rail wasn’t originally designed to interoperate. That came later, and it’s how the industry ended up building interoperability, and everything linked to it around safety, into a shared framework. You see similarly large-scale, cross-border projects in other regions too, the GCC in the Middle East being one example.
Cyber, for cross-border projects, is still at an early stage by comparison. You could say we’re seeing the tip of the iceberg, with what’s underneath still largely unaddressed. Different regions apply different standards, often with different levels of detail and sometimes describing different things: the US has one applicable set of horizontal regulation, Europe another, Australia its AS7770 standard, and these need to be reconciled and interpreted against each other.
Emerging vertical rail standards should help provide more of a common denominator. IEC 63452 is a genuinely international IEC standard rather than a European one; roughly 150 professionals are involved in drafting it, from countries including Japan and Korea as well as across Europe. Even once contracts in different geographies are asking for adherence to the same standard, there will still be plenty to interpret and contractual requirements will still differ, but a shared standard base should help.
Cross-border cyber alignment remains a challenge, partly because cross-border rail projects are already challenging without a cyber dimension. We see that in projects across the Middle East, including the UAE and Saudi Arabia, where different parts of a programme can sit at very different levels of maturity. Europe is somewhat more straightforward, since the EU’s cybersecurity agency ENISA and the European Union Agency for Railways already work together.
SSH: Will DNV have a presence at InnoTrans this year, and what’s the focus?
JA: DNV carries a lot of value as a brand, and that’s something we lean on. The core message we want to bring is that we’re alongside stakeholders through the current transformations in rail, not only on safety, but on smart solutions, smart supply chains, smart stakeholders, smart contracts and smart railways more broadly. We’re pitching as an entity that’s there to listen and understand the pain points across different clients, rather than only delivering assurance or systems engineering. Our offering in rail is holistic: we act as a third party certification entity, but we also want to be present on the digital side and help introduce innovation.
Santiago de los Caballeros is a good example of that approach in practice. We’re not there to run a formal assessment against IEC 63452, since it isn’t yet a published standard. We’re there to work out how best to apply it, both to improve the standard itself and to improve cyber resilience on that project.
We also want to reinforce our position close to the operators and owners actually running these assets, and our focus on asset performance and sustainability, both being central to DNV’s wider vision and mission beyond rail specifically. That matters in an industry where assets can remain in service for up to 50 years. Beyond our established position in third-party risk and safety management, we’d like to be seen as engaged in the wider conversation around AI governance and the ethical use of AI in rail, in line with existing and emerging regulation, but grounded in a pragmatic approach to how assets actually perform.
SSH: How much of DNV’s rail work now is about meeting the regulatory bar set by rules like NIS2 and the Cyber Resilience Act, as opposed to driving genuine operational risk reduction?
JA: We made an internal effort to understand this regulation in depth, position ourselves at the leading edge of it, and work out where the gaps are that will affect its implementation. Talking to people who sit on the technical groups drafting this regulation, the common theme is that the real difficulty emerges once you try to bring it down to a specific contract. That’s where the discussion gets complicated, and it’s where we’ve tried to work.
That effort runs across three areas. The first is cyber risk scouting, understanding 54 INNOTRANS what’s actually available in the market, within Europe and beyond. The second is participating directly in the regulatory frameworks themselves. Alongside our role in the IEC 63452 working group, DNV is the cybersecurity representative for NB-Rail, the European association of notified bodies responsible for conformity assessment in rail, covering both interoperability and safety-related aspects.
That puts us in a position to bridge between other conformity assessment bodies, industry bodies such as UNIFE, and the wider sector. The third is finding practical projects, Santiago de los Caballeros being the clearest example, where we can trial application of the regulation, encourage stakeholders to be among the first to use it, and identify where the regulation itself may still need fixing or isn’t fully adjusted to reality.
We also share what we learn, internally and externally. Since DNV’s new strategy began on 1 January 2026, cyber has become a core element within the business, not confined to rail. It runs across maritime, our classical industry, energy systems and industrial services more broadly, of which rail is part.
On the specific instruments: NIS2 targets operators of critical infrastructure, while the CRA targets products and introduces mandatory manufacturer obligations, and there are working groups trying to work out what that means specifically for rail, without full consensus yet on some points. Our aim is to ground that regulation in the practical realities of rail: long life cycles, existing contracts, and delivery dates that clients are already working towards, rather than dealing with it only at the level of headlines.
SSH: Do you think the maturity of cybersecurity regulation and AI regulation are running in parallel?
JA: Cybersecurity is more advanced. AI regulation remains more open, closer to a ‘wild west’, even though the potential of AI is huge. That creates a real tension between the right governance approach, the right ethical use, and how you assure AI itself against the range of innovations being built on it, something DNV sees regularly in its own work and in dealing with contractors.
Combining cybersecurity and AI raises further questions: how AI can be used for more dynamic protection of assets and for cyber resilience, but equally how it might be used by attackers, including AI-led tools already being marketed that claim to help identify unprotected points in a system. Historically, use cases in emerging technology tend to arrive first, with regulation trying to catch up and anchor them afterwards, and there’s no reason to expect AI’s development to be any different. Cyber regulation already assigns liability directly to individuals in management positions within a company. It’s likely something similar will develop for AI, including in Europe’s AI Act, though that will take time given how geopolitically charged the debate around AI already is.
