Cylus's IEC 63452: The Final Countdown webinar brought together members of the working group writing the standard, just as its final ballot was closing. Attendees sent in great questions before and during the session, and not all of them could be covered live.

‍

In this follow-up article, we've compiled answers to the questions raised, so every question gets the attention it deserves.

‍

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

‍

1. Can you discuss NIST IR 8576 and how it relates to IEC 63452? What will the regulatory approach be in the USA?

NIST IR 8576 is the Transit CSF Community Profile that NIST's NCCoE finalized in August. It's voluntary and built on CSF 2.0, and it sets out the cybersecurity outcomes a US transit agency should aim for across both IT and OT. IEC 63452 works at a different level. It tells you how to engineer and assess security into a railway system over its lifecycle, using risk assessment, zones and conduits, and security levels. The two fit together nicely: the NIST profile helps an agency decide what it needs to achieve, and IEC 63452 gives suppliers and integrators a way to show how a system delivers it.

On regulation, the US is going a different way than Europe. Instead of product rules like the CRA, it puts obligations on operators, mainly through TSA's cyber risk management requirements for higher-risk railroads and transit agencies, which lean on the NIST framework. Rail-specific standards like IEC 63452 are likely to come in through procurement specs, not law.

‍

2. Does IEC 63452 work with Security Levels as described in the current version of IEC 62443?

Yes. IEC 63452 uses IEC 62443-3-3 as a normative reference and uses the same SL-T definition. It also gives guidance on applying IEC 62443-3-3 requirements in a railway context. So if you already work with IEC 62443, nothing needs translating. You set SL-T per zone and conduit from the risk assessment, then show that the components and countermeasures reach it. What IEC 63452 adds is the railway context: how to do that alongside the safety lifecycle and for rail-specific systems like signaling and rolling stock.

‍

3. I heard a rumor that Security Levels will no longer be used in general, because of harmonization with the CRA. Is that true?

Not quite. Security Levels aren't going away in IEC 62443. Parts 3-3 and 4-2 still use them, and IEC 63452 builds on the same SL-T approach. What's true is that the CRA harmonized standards CEN/CENELEC are writing (the EN 40000 series and OT product standards like prEN 50770) don't use IEC 62443 SLs as the yardstick for conformity. They work from the CRA's essential requirements and talk about levels of implementation instead. So for CRA compliance of a product you'll see a different vocabulary, but for designing and risk-assessing a rail system under IEC 63452, SLs are still the main tool.

‍

4. Will IEC 63452 be a CRA-harmonized standard?

IEC 63452 is an IEC Technical Specification. CRA harmonized standards are European Norms that CEN/CENELEC write under the Commission's standardization request and that get cited in the Official Journal. They're also about products with digital elements, while IEC 63452 is about securing whole railway systems across a project lifecycle. Using IEC 63452 won't give you presumption of conformity with the CRA. Still, a lot of the work you do for it (risk assessment, vulnerability handling, secure maintenance) will be useful evidence when a rail product has to meet the CRA. On the other hand, CENELEC WG26 is working on a technical report that will map and show the gap between IEC 63452 and the CRA's requirements.

‍

5. How does IEC 63452 address emerging technologies such as AI and quantum computing? How flexible is it in accommodating fast-changing technologies without frequent revisions?

It doesn't name specific technologies, and that's deliberate. The standard is risk-based, built on zones and conduits, threat analysis, and target security levels. A new technology goes through the same risk assessment as everything else, without waiting for its own clause. If an AI component or a new communication link changes the threat picture, the risk assessment should show it, and the countermeasures follow from there. For quantum, the practical concern is crypto agility: being able to swap algorithms over a 30-year asset life. That fits under the standard's maintenance and vulnerability-management requirements. IEC standards are also reviewed periodically, so more specific guidance could come in later editions.

‍

6. For the responsibility split during system operation, does IEC 63452 say who does what in maintaining system cybersecurity?

Partly. IEC 63452 defines the roles: the railway duty holder, the integration service provider, and the maintenance service provider. Its lifecycle also covers operation and maintenance activities like patch and vulnerability management, access management, monitoring and incident response. What it doesn't do is fix exactly who does each task. That's meant to be agreed per project and written into the cybersecurity management plan and the contracts. In practice, the duty holder stays accountable for security in operation, while suppliers commit to things like vulnerability notifications and patch support.

‍

7. How will IEC 63452 affect work or projects already completed under TS 50701?

Completed work isn't thrown out. IEC 63452 was built on TS 50701, so the core concepts carry straight over: risk assessment, zones and conduits, SL-T and the security lifecycle. The new standard completes, improves and expands TS 50701, allowing for future improvement of ongoing or already completed work.

‍

8. Will applications assessed under TS 50701 be cross-accepted when they're integrated into projects developed under IEC 63452?

The standard doesn't decide that on its own. It's up to the assessors and authorities on each project to decide. The overlap is large, though, so the evidence from a TS 50701 assessment should be mostly reusable. Most probably, you should expect a gap analysis against the new requirements rather than a fresh assessment from scratch.

‍

9. If a TS 50701 project has to be reassessed, how much extra effort will reassessment under IEC 63452 take?

It should be a delta, not a full redo. Most of the existing work maps across: the risk assessment, zoning, SL-T allocation and countermeasures definition. The focus should be on implementing the new requirements to close the gap between the two standards.

‍

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

‍