Segregation first, patches second.
Cybersecurity now accompanies every safety conversation in rail. The useful answer is architectural, because a security control added after the architecture is fixed can only do so much.

NEAT / TECHNICAL ENGINEERING
BY DESIGN
What the architecture provides.
- A separate non-vital communication computer, distinct from the safety nodes
- Firmware integrity protection on mass memory, with signature verification at boot and on every restart
- Access protection inside the PVS stack
- Configuration data verified against its signature before it is loaded
- Safe state entered and retained on integrity failure
AT PRODUCT LEVEL
And what still has to be done.
The platform documentation is explicit about this: a full threat analysis, following for example IEC 62443-3-2, can only be performed at the level of a GeminiX-based product. What can be done at platform level is a preliminary analysis of the external interfaces treated as security conduits.
Saying so is more useful than claiming a security posture the platform alone cannot deliver.
- Standards and frameworks applied: EN IEC 62443, TS 50701
- Secure development lifecycle
- Vulnerability handling and disclosure policy, with a named contact
- Patching and update strategy, including the boot selector route
- Key management and cryptographic practice, linked to KMC Subset-137
