Quick summary

In safety-critical embedded software, a defect can cause physical harm, so quality assurance is governed by functional safety standards rather than general best practice. The work centres on rigorous verification, complete traceability and, increasingly, proving that a system is secure as well as safe.

Introduction

In most software, a bug is an inconvenience. In a brake controller, an infusion pump or a railway signalling system, it can injure or kill. That difference reshapes everything about how quality assurance is done, turning it from a development phase into a regulated discipline with its own standards, evidence requirements and audits.

Safety-critical QA is not about testing more of the same things. It is about a fundamentally different relationship between code and consequence, where every requirement must be traceable, every verification must be justified, and the entire process must withstand external scrutiny. Increasingly, it also means proving the system is secure, because a vulnerability in a connected safety system is now a safety problem too.

What makes safety-critical QA different

The defining feature of safety-critical QA is that the process itself is the product. It is not enough for the software to work; the organisation must be able to demonstrate, with documented evidence, why it can be trusted to work even when something goes wrong.

This is the concept of the safety case: a structured argument, backed by evidence, that a system is acceptably safe for its intended use. Standards such as ISO 26262 mandate its production, requiring that safety requirements are shown to be complete and satisfied by evidence gathered throughout development. The implication is that QA activity which is not documented and traceable effectively did not happen, as far as an assessor is concerned.

In safety-critical software, an untraceable test has no value, because the evidence trail is what proves the system safe, not the test alone.

This is why safety-critical QA demands a different mindset from commercial software. The goal is not only to find defects but to build a defensible argument that the system behaves correctly and fails safely.

Takeaway: Safety-critical QA centres on a documented safety case, so traceable evidence of correct and safe behaviour matters as much as the testing itself.

The functional safety standards landscape

The foundation of this field is IEC 61508, the generic international standard for the functional safety of electrical, electronic and programmable electronic systems. It defines a risk-based safety lifecycle and four Safety Integrity Levels, from SIL 1 to SIL 4, with higher levels demanding progressively more rigorous verification.

From this parent standard, a family of sector-specific derivatives has grown, each tailored to its domain:

• ISO 26262 for road vehicles, using Automotive Safety Integrity Levels from ASIL A to ASIL D

• IEC 62304 for medical device software lifecycles, often paired with risk management under ISO 14971

• EN 50128 and EN 50716 for railway software

• DO-178C for airborne systems

The reason this structure matters is that the chosen standard dictates the QA effort. A SIL 3 industrial function or an ASIL D automotive system requires far more stringent verification than a lower-integrity component, and that requirement shapes the project from the first design decision. Delivering it reliably is the core of verification and validation for regulated systems, where the standard's demands have to be engineered into the process rather than checked at the end.

Takeaway: IEC 61508 and its sector derivatives set the QA effort according to integrity level, so the applicable standard and target level shape the entire development process from the outset.

The verification the standards demand

Functional safety standards do not leave verification to judgement; they prescribe techniques appropriate to the integrity level. A mature safety-critical QA process typically combines several rigorous methods.

Static analysis examines code for defects and rule violations without executing it, often enforcing coding guidelines that restrict risky language features. Structural coverage analysis measures how thoroughly tests exercise the code, with higher integrity levels requiring more demanding coverage criteria. For the highest integrity systems, formal methods, which use mathematical proof to show that software meets its specification, are a recommended technique because they provide a far stronger guarantee of correctness than testing alone.

Two further requirements distinguish this work from ordinary testing. The first is traceability: every requirement must link to its design, its implementation and the tests that verify it, in both directions. The second is tool qualification: the tools used to build and verify the software must themselves be qualified or certified, because an unqualified compiler or test tool could mask a defect. The reason this matters is that the standards treat the toolchain as part of the safety argument, not a neutral utility.

Takeaway: Safety standards prescribe static analysis, structural coverage and, at high integrity levels, formal methods, all bound together by complete traceability and a qualified toolchain.

When safety meets security

Historically, functional safety and cybersecurity were separate disciplines. Connectivity has fused them. A safety-critical system that is networked, and most now are, can be compromised through a vulnerability, which means a security flaw can become a safety hazard.

Regulation has caught up with this reality. Under the EU Cyber Resilience Act, products with digital elements must be designed to be secure and supported with vulnerability handling, with breaches of the essential requirements attracting fines of up to 15 million euros or 2.5 percent of global annual turnover (European Commission, 2025). For a manufacturer of safety-critical equipment, this means QA must now produce evidence of security as well as safety.

The standards landscape is converging accordingly. IEC 62443-4-1 defines secure product development lifecycle requirements for industrial components, covering secure design, implementation, verification and defect management (IEC, 2018). The interpretive point is that the disciplined, evidence-driven process that functional safety already demands is the natural home for these security requirements, because both rest on the same foundations of rigour and traceability.

Takeaway: Connectivity has merged safety and security, so QA for safety-critical systems must now generate security evidence too, and the rigorous functional-safety process is the natural place to do it.

Building a QA process that survives an audit

Because the process is the product, the test of a safety-critical QA programme is whether it survives external assessment. An assessor will follow the thread from a hazard, through the safety requirements that address it, to the design, the code and the tests that verify it, expecting an unbroken chain at every step.

Building that chain is far easier when it is designed in from the start than when it is reconstructed before an audit. The most effective programmes establish requirements management, traceability and a qualified toolchain at the beginning, then generate evidence continuously rather than retrofitting documentation under deadline pressure. Manufacturers across the DACH region and the Nordics, where automotive, medical and industrial safety expectations run high, tend to treat this discipline as a competitive asset rather than a compliance burden.

The strategic lesson is that rigour compounds. A process built to satisfy a demanding integrity level produces software that is not only certifiable but genuinely more reliable, and that reliability is what the standards exist to protect.

Takeaway: A safety-critical QA process that builds traceability and a qualified toolchain from the start, generating evidence continuously, is both audit-ready and genuinely more reliable.

Conclusion

Quality assurance for safety-critical embedded software is a discipline apart, governed by functional safety standards that demand documented evidence, prescribed verification techniques and complete traceability. The process itself, not just the code, is what proves a system safe.

That discipline is now expanding to encompass security, as connected safety systems fall under regulations like the Cyber Resilience Act. For organisations building these systems across the EU, the encouraging reality is that the rigour functional safety already requires is the strongest possible foundation for meeting the security expectations now arriving alongside it.

FAQ

What standards govern quality assurance for safety-critical software?

The foundational standard is IEC 61508, which defines a risk-based safety lifecycle and Safety Integrity Levels from SIL 1 to SIL 4. Sector-specific derivatives include ISO 26262 for automotive, IEC 62304 for medical devices, EN 50128 and EN 50716 for railways, and DO-178C for airborne systems. The applicable standard and integrity level determine how rigorous the QA process must be.

What is a safety case in safety-critical software?

A safety case is a structured argument, supported by documented evidence, that a system is acceptably safe for its intended use. Standards such as ISO 26262 require its production, showing that safety requirements are complete and satisfied by evidence gathered throughout development. It is central because in safety-critical work, undocumented or untraceable testing carries little weight with an assessor.

Why is traceability so important in safety-critical QA?

Traceability links every requirement to its design, implementation and verifying tests, in both directions, creating an unbroken evidence chain from hazard to test. Assessors follow this chain during audits, so a gap anywhere undermines the safety argument. Building traceability in from the start is far more effective than reconstructing it before an assessment.

How do cybersecurity requirements affect safety-critical software QA?

Because most safety-critical systems are now connected, a security vulnerability can become a safety hazard, so QA must produce evidence of security alongside safety. The EU Cyber Resilience Act requires products with digital elements to be secure by design, and IEC 62443-4-1 defines secure development lifecycle requirements. The rigorous, traceable process that functional safety already demands is well suited to generating this security evidence.

Sources

• Cyber Resilience Act, summary of the legislative text – European Commission – 2025 – https://digital-strategy.ec.europa.eu/en/policies/cra-summary

• IEC 62443-4-1:2018, secure product development lifecycle requirements – IEC – 2018 – https://webstore.iec.ch/en/publication/33615

• Testing and verification of neural-network-based safety-critical control software, a systematic literature review – arXiv (peer-reviewed preprint) – 2020 – https://arxiv.org/pdf/1910.06715