Topics / Standards and assurance
EN 50128 and EN 50716: which applies to your software?
EN 50128 addresses software for railway control and protection systems. EN 50716:2023 is its successor and also covers onboard rolling-stock software. For an existing project, establish the applicable edition and modification scope with the responsible authority before changing the assurance basis.
What EN 50128 covers
EN 50128 concerns the development of software used in railway control and protection applications. It is a lifecycle assurance basis, not a single test or a generic cybersecurity certification.
The EVS catalogue for EN 50716:2023 records EN 50128 and EN 50657 in its history. The successor brings control and protection and onboard rolling-stock software into its scope. A catalogue’s withdrawal date does not by itself settle the contract and assessment basis for an existing system.
Record the basis for this modification
- System and baseline: identify the software, application and versions being changed.
- Applicable documents: record the contract, standard editions and any project-specific obligations.
- Modification scope: explain the functional effect and the rationale for its classification.
- Assessment: record the responsible authority’s determination and required independence.
- Evidence delta: identify reusable evidence, new verification and unresolved assumptions.
For a timeout change, a small diff can still alter a safety-relevant response. Review the behavioral consequence and affected interfaces rather than using lines changed to decide assurance effort. Keep the change-impact analysis and assessment decision together.
Do not silently substitute an edition.
The EVS standards catalogue lists EN 50716:2023 for railway software development and records earlier EN 50128 and EN 50657 editions in its history. The published scope primarily covers new development. It applies in full to existing systems undergoing major modifications; for minor changes, it specifies clause 9.2. The assessor reviews whether the documented classification and scope of the changes are adequate. Record that rationale rather than classifying the change by patch size alone.
Source: EVS: EN 50716:2023. Scope and edition reviewed 9 October 2026.
Confirm the contract, national adoption and assessment basis with the responsible project authority. Keep the source and rationale for the applicable edition in the record.
Show what the modification changes.
Illustrative example
A maintenance update changes a timeout.
The code edit is small, but it may affect how a control function treats delayed input. Identify the governing software requirement, related interfaces and previous evidence. Explain which conclusions remain usable and which require new verification.
- Identify the system and software versions and document the modification classification.
- Record the intended behavioral delta and preserved obligations.
- Attach verification under relevant operating conditions.
- Retain the reviewer’s assessment of unresolved risks.
Prepare evidence without claiming a safety approval.
Proof can help connect requirement, implementation and verification records for the modification. It does not replace railway assessment, required independence or the project’s full lifecycle evidence.
A useful starting point is a change whose evidence currently requires manual reconciliation across several tools. Have the assessor judge the usefulness of the connected view.
Try it on your software
Bring one railway software modification.
We can map its engineering evidence against the project basis you already use.