The real risks of non-compliance with IEC 61508

IEC 61508 provides the definitive framework for building functional safety into your electrical, electronic, and programmable electronic (E/E/PE) safety-related systems. This blog focuses on embedded software specifically, but the principles apply to all PE systems covered by the standard.

If you’re reading this, you may be hoping to learn that functional safety is optional. Good news: compliance with IEC 61508 *is not* a legal requirement. But given what’s at stake, you’d be wise to treat it as one.

In this blog, we’ll look at why the standard matters, what non-compliance could mean for your safety-related projects, and where teams most often get caught out.

Why IEC 61508 matters in practice

The IEC 61508 standard applies to safety-related systems that rely on electronics or software, where failure could pose an unacceptable risk to people, the environment, or economic assets. For example, a train signalling system incorrectly shows that a track is clear when it’s occupied by another train.

Its principles show up across countless global safety regulations, such as IEC 62061 for machinery and ISO 26262 for automotive. By complying, it shows that your products can be trusted to reliably perform their intended safety functions (and that you care).

But functional safety isn’t something that you can just plug in and switch on at the end of a project to score points with regulators, markets, and discerning consumers. It’s a way to structure how safety is considered throughout the entire development lifecycle.

This means IEC 61508 and its Safety Integrity Levels (SILs) influence how requirements are defined, systems are designed, software is implemented, and everything is verified. Treat it as a late-stage activity, and you’ll likely find that crucial design and engineering decisions have already been made that are painfully slow and costly to unpick. But that isn’t the only risk to consider.

The legal, commercial, and reputational risks

Developing software for safety-related embedded systems without following functional safety requirements can have serious consequences, including:

• Harm to people, the environment, and assets

IEC 61508 exists to reduce the risk of safety-related system failure to a tolerable level. If you start development without properly identifying hazards, putting the right safeguards in place, and verifying that they work, the likelihood of failure increases. In safety-related systems, failure has real consequences, including harm to people, damage to the environment, or disruption to critical infrastructure and services.

For example, the 2011 Wenzhou train collision in China was triggered by a lightning strike that caused a signalling failure, incorrectly showing a section of track as clear. This allowed a high-speed train to collide with a stationary train ahead, killing 40 people. While the lightning strike itself couldn’t have been prevented, the system didn’t fail into a safe state—exactly the kind of error that IEC 61508 is designed to prevent.

• Legal, reputational, and financial damages

While IEC 61508 isn’t a legal requirement, following its principles can help protect you against significant legal and commercial risk, especially if a safety-related system fails.

If a failure leads to harm, you’ll likely be asked to demonstrate that functional safety best practices were followed, including rigorous testing and validation. Without clear evidence, you may face increased legal scrutiny, financial penalties, and long-term reputational damage that’s hard to recover from.

In 2003, the Northeast Blackout left around 55 million US and Canadian citizens without power, and brought several major cities, including New York, to a standstill. The outage was caused, in part, by a software failure in an alarm management system that left operators unaware of escalating faults. The event’s scale and impact led to intense regulatory scrutiny and revised grid reliability standards.

• Blocked market access and delayed projects

In many industries, customers and regulators expect you to align with IEC 61508 or standards derived from it as a condition of approval and market access. This includes, but is not limited to, industrial machinery, automotive, rail, and energy.

If you can’t demonstrate that your system has been developed to these standards, you may struggle to win contracts, pass assessments, build partnerships with distributors, or integrate into larger systems.

Even if your product and its embedded systems are fully functional, commercial release may be delayed—or even cancelled—unless you can provide evidence that functional safety has been properly addressed.

For instance, in the energy sector, power generation and distribution systems must often demonstrate compliance with IEC 61508 before they can be deployed. Projects are frequently delayed when suppliers can’t provide sufficient evidence of functional safety, including validated software and a complete safety case. Without this, systems may fail approval, delay commissioning, and increase costs.

Where teams often get caught out

Most teams don’t deliberately ignore IEC 61508, but it’s often perceived as a burden rather than an opportunity to build safer software and work more effectively.

This is more common in traditional development approaches—like Waterfall—where work is done in a linear, sequential way. In these environments, functional safety is often treated as something to address later, rather than continuously shaping decision-making throughout development.

As a result, assumptions go unrecorded, traceability isn’t established early enough, and critical engineering decisions are made without considering their impact on end-user safety. By the time compliance gaps become visible—usually during verification and validation—they’re difficult to resolve without costly rework.

Your functional safety companion

IEC 61508 and its many clauses can be hard to navigate and follow, especially when teams often face greater pressure to deliver commercially viable software within ever-tightening budgets and timelines.

That’s why we’ve unpacked the IEC 61508 clauses most relevant to embedded software teams working on safety-related projects.  Our functional safety checklist covers everything embedded software teams need to navigate IEC 61508 — including how to:

• Reframe proactive compliance as a significant business opportunity
• Integrate functional safety principles into every step of every project
• Build accountable teams with clear safety targets for smoother certification

Get the essential IEC 61508 checklist

Download your functional safety companion guide, including a bespoke IEC 61508 maturity assessment and repeatable checklist for use across safety-related embedded software projects.