Cylus's IEC 63452 webinar sparked an engaging conversation around the standard and its real-world implications. The session was packed with insightful questions from attendees, but due to time constraints, not all of them could be addressed live. As promised, the experts from the working group took the time afterwards to review the unanswered questions and provide their insights carefully.

In this follow-up article, we’ve compiled their detailed response, ensuring that every question raised during the webinar receives the attention it deserves.

Missed the live session? You can still catch the discussion here.

1. Could you explain the difference to  EN 50701, please?

A CENELEC Technical Specification (TS) is a pre-standard document, often used when there is not yet enough consensus or maturity in the industry to issue a full European Norm (EN). It provides guidance and recommendations, but compliance is not mandatory, and it may later evolve into an EN. An IEC standard, on the other hand, is an internationally agreed and formalized document developed by the IEC, carrying stronger authority and usually representing a stable, consensus-based reference that is expected to be applied globally.

TS50701 is a European Technical Specification that has been used as the main input to create the IEC63452. But as explained during the webinar, the IEC is an international standard that has many improvements over the TS50701.

2. By when are we expecting this standard to be effective?

The IEC63452 is aimed to be approved and officially published by July 2026

3. IEC 63452 supports security measures for the Cloud. Is it related to Public Cloud or Private Cloud?

Provided recommendations and guidance apply to both.

4. Does it go down to the level of recommended SL-T for each subsystem?

The IEC63452 provides a process on how to derive or define an SL-T in the same way that the IEC62443 does, but it does not provide recommendations of SL-T for each kind of rail subsystems since it needs to be defined in a risk-based approach, and that risk might be very different for the same subsystem in different operators from different countries.

5. Does it mean the Baseline Product must be IEC62443 certified/compliant?

No, the IEC63452 does not oblige to certify products following IEC62443. It does not enter into defining the security controls at the component level but at the system level, and keeps the approach flexible to be followed at the component level, which can use IEC62443 or other equivalent standards or best practices.

6. IEC 63452 shall be applied at the System Level?

The standard is aimed at being applied at the Railway Application level. This can be a system, a subsystem, or a system of systems. The scope might differ, and it is up to the asset owner in each case to properly define the scope.

7. What would be the scope of the Independent Safety Assessment of sub-systems and the whole system with respect to this standard? Please also highlight any kind of coordination required during the V cycle as per EN 50126 with regard to Cybersecurity.

The Independent Safety Assessment does not play a direct role in IEC 63452. However, the standard identifies the synchronization points between safety and cybersecurity processes; for example, the identification of safety-related assets to be protected, the potential safety impacts from attacks, which will be useful for the cybersecurity risk assessment; the resulting cybersecurity requirements specifications and their potential impact on safety functions, which will be useful for the safety process.

8. As it is in line with CSM-RA, Safety Case for SIL certified; Is it a Cybersecurity Case with a similar 6 Section covered? ( Changing Section 4 Safety Management Report to Cybersecurity Management Report)

The Safety Case and the cybersecurity case are different concepts. The approach is similar since the Cybersecurity Case concept is “inspired” by the Safety Case, but the mandatory content of the Cybersecurity case is specified within the IEC 63452 standard itself.

9. How much work would you estimate it to be for a System Integrator to adopt an existing Cyber security framework according to TS50701 and to the new IEC63452?

It is very difficult to estimate that, since it will change a lot depending on the scope and other factors. However, a company that has already adopted the TS50701 will need a much shorter journey towards IEC63452 than one starting from scratch.

10. To what extent do the essential elements of the processes and the required documentation have to be changed?

It will really depend on the starting point. If the organization already has strong cybersecurity processes in place, or it has already adopted TS50701 processes, the change would be smaller than for a company that is introducing cybersecurity on the rail systems.

11. Will you propose certification paths for a vendor, integrator, operators, and products against the new standard?

Certification paths will not be part of this first version of the IEC63452 standard.

12. When preparing IEC 63452, were the architectures outlined in IEC 61375, particularly regarding train coupling, taken into account in the assessment? Are there examples/guidelines on applications to railway systems such as ETCS or Energy Systems?

Technical architectures from IEC 61375 were not directly considered in the development of IEC 63452, and the standard does not provide guidelines for specific systems such as ETCS or Energy systems and substations. Its purpose is not to deliver technical recommendations for individual subsystems, as it would be impossible to cover all possibilities, but rather to establish a framework and processes that can be applied to bring cybersecurity monitoring to any railway application.

13. I am curious about how new tools, such as generative AI, may or may not have influenced the drafting process of standards like IEC 63452. Could you share your perspective?

AI tools have not been forbidden nor encouraged in the drafting process of the standard. Each expert from the working group had the flexibility to use the resources and the expertise he or she considered more adequate for their collaboration. Nevertheless, the development process requires thorough revision, verification, discussion, and agreement from the project team members for the entire document.

14. I noted the use of the term "Railway Cloud" (in relation to OT)  in Serge's slide deck.  What is meant by this term, and is it being defined in 63452 or its annexes?  Also, what is the current content within the standard pertaining to remote VPN access to railroad systems for O&M purposes?

As mentioned during the webinar, the current version of the draft for the standard has an informative annex recommending how to bring cybersecurity to the usage of cloud for OT environments. The standard doesn’t bring specific controls related to remote access, but it is rather covered as part of the proposed general risk assessment process.

15. What is the time duration suggested for getting approval under the IEC63452 process, normal /min/max? Secondly, if a product is already approved under IEC62443, then how can it help in obtaining compliance for IEC63452?

There is no process yet defined to get approval under the IEC 63452 standard. If the questions mean how much time the adoption of the standard will require, that would be highly dependent on what the starting point of cybersecurity maturity for the organization is, and how many resources are dedicated to the adoption of the standard. For some organizations, it might only require a few months; for others, it might require much more time. Components that are already compliant with IEC62443 will make it easier to demonstrate how they contribute to the compliance with IEC63452 at the system level.

16. Why is IEC62443 not a normative reference?

IEC 62443 is not listed as a normative reference because the standard is intended to be self-contained and tailored specifically to the rail sector. While it is heavily inspired by and aligned with IEC 62443 principles, making it normative would force full and direct compliance with a standard designed for all industrial sectors, which might not fit rail’s particular requirements and which might evolve in different directions in the future. Instead, IEC 62443 is treated as an informative reference, meaning its concepts guide the structure and content without imposing obligations that could conflict with the railway-specific context.

17. How specific are the requirements? I often find that cyber requirements can be quite generic and open to interpretation. How does this standard address that?

The requirements in this standard are written to be more concrete than generic cybersecurity guidance, but they are not prescriptive down to the implementation detail. They define what must be achieved in terms of processes and security outcomes, while leaving flexibility for rail operators and suppliers to adapt solutions to their systems and risk profiles. This balance ensures the standard is applicable across diverse railway environments, yet still provides clear expectations that reduce ambiguity and make compliance auditable.

18. Will V&V for Cybersecurity be followed in RAMS LC as per EN50126?

Verification and validation of cybersecurity can be integrated into the RAMS lifecycle defined by EN 50126. The idea is that cybersecurity activities are not treated separately but follow the same structured lifecycle approach, ensuring that requirements are verified and validated at each stage. This alignment makes cybersecurity an integral part of system assurance rather than an add-on process. However, the standard does not force one or another approach; it’s up to each organization to decide how that integration shall happen.

19. To what extent do cybersecurity assessments play a role in the standard? For instance, Threat and vulnerability assessments, penetration tests, etc. Is the standard also framed on an underlying risk-based approach?

Cybersecurity assessments play a central role in the standard, as it is framed on a risk-based approach. Activities such as threat and vulnerability assessments, risk analysis, and penetration testing are explicitly encouraged as part of the process to identify, evaluate, and mitigate risks. The standard does not prescribe exact test methods but ensures that these assessments are systematically integrated into the lifecycle to maintain an appropriate level of security for railway applications.

20. Can the draft standard, or its "Preview," be distributed to me and this audience?

The draft standard is currently available through the IEC National Committees and is undergoing the voting process. Following formal approval under the IEC procedures, the definitive version is planned for publication in July 2026.

21. Will IEC 63452 be considered a harmonized standard under NIS2?

That’s not up to us to decide, but it probably will not be a harmonized standard under NIS2. However, as explained during the webinar, the TS50701 will probably evolve to be a guide on how to use IEC 63452 to be compliant with NIS2 and CRA requirements.

22. Will IEC 63452 become a requirement under TSI?

Again, not up to the IEC 63452 Project Team to decide. However, a parallel voting of the standard to become an IEC/EN 63452 will be performed. That means that if approved, being an EN it could become a requirement in the future.

23. Once the standard is published, how often will it be reviewed and updated?

Probably every 2 to 4 years, but it is still not defined.

24. Do you have some ideas to encourage adoption of the standard upon publication?

Training and awareness will be the main activities helping its adoption. Also, of course, its usage in tenders or by regulators would be a big push through all the rail ecosystem.

25. Rail projects and operations can differ a lot from country to country. How does the standard handle these differences?

The standard addresses national and operational differences by defining a framework and processes that are technology- and country-agnostic, rather than prescribing fixed technical solutions. This allows each railway organization to apply the requirements in line with its local context, regulatory environment, and operational practices, while still ensuring a consistent level of cybersecurity across the sector.

26. Are new experts still accepted as part of the group to contribute, or is it now too late?

Absolutely, new experts are still accepted and encouraged to join the group. The requirement is for the organization to already be, or to join the IEC National Committee of its country, and then the NC to propose or nominate the specific experts to join the Project Team.

Have more questions? Email them to daniella.julius@cylus.com.

‍