What Is IEC 61508? A Guide to the Functional Safety Standard

A pressure transmitter on a chemical reactor spikes past its safe limit. A programmable logic controller reads the signal, trips a safety function, and a valve closes before anything downstream notices. The only trace is a line in the event log and a proof-test record that has to hold up years later when an assessor asks how that shutdown was verified.

That is the kind of system IEC 61508 is written for. The standard sets the ground rules for functional safety across process industries, machinery, rail, and any sector without a dedicated framework. This guide walks through what IEC 61508 is, the seven parts and the safety lifecycle, how Safety Integrity Levels work, and what a credible path to certification looks like.

What Is IEC 61508?

IEC 61508 is the international standard for functional safety of electrical, electronic, and programmable electronic safety-related systems, published by the International Electrotechnical Commission (IEC). It is a Basic Safety Publication, which means it sets safety principles that apply across industries instead of writing rules for one vertical. The standard is goal-based, so teams run risk analysis, set risk reduction targets, and show through structured evidence that those targets are met.

The scope covers safety functions run on electrical elements (relays), electronic elements (semiconductors), and programmable electronic elements (PLCs). It applies whether that function is a single relay interlock or a PLC running a full emergency shutdown, and it extends to any software the function depends on.

Industries That Use IEC 61508

Sectors with high safety risk adopt IEC 61508 directly or through a sector-specific derivative. Common adopters include oil and gas, chemical processing, power generation, rail, industrial machinery, and medical devices. Typical applications include emergency shutdown, fire and gas detection, turbine control, gas burner management, machinery guard interlocks, and rail signalling.

Each sector may layer its own rules on top of the parent standard, but the lifecycle and SIL concepts trace back to IEC 61508. Teams building cross-sector products anchor the safety case to the parent standard and adapt the documentation from there.

The Seven Parts of IEC 61508

Parts 1 through 3 contain the normative requirements teams are assessed against. Part 4 supplies definitions, and Parts 5 through 7 offer non-binding guidance:

• Part 1, General Requirements: Defines the overall safety lifecycle, conformance rules, documentation expectations, and how functional safety management and assessment should run.
• Part 2, Hardware Requirements: Covers the hardware safety lifecycle, architectural constraints, and the control of random and systematic failures through fault tolerance rules and diagnostic coverage.
• Part 3, Software Requirements: Defines the software safety lifecycle with SIL-dependent techniques for design, coding, analysis, and testing. Part 3 cannot be applied on its own.
• Parts 4 through 7: Part 4 supplies definitions, Part 5 shows example methods for SIL determination, Part 6 gives worked probability calculations, and Part 7 catalogs hardware and software safety techniques.

Assessors still expect teams to show awareness of the techniques in Parts 5 through 7, so treating them as optional reading is one of the easier ways to lose ground during an audit.

The IEC 61508 Safety Lifecycle

The safety lifecycle is the phased process IEC 61508 uses to carry a safety function from concept to decommissioning. It runs on three connected tracks. The overall lifecycle is the master framework, the system lifecycle covers hardware under Part 2, and the software lifecycle under Part 3 expands the realisation phase. Verification, functional safety assessment, and functional safety management apply across every phase.

The phases group into three stages that run the length of the program.

• Analysis phases: The first five phases establish what must be protected and how much risk reduction is needed. They move from defining the Equipment Under Control through hazard and risk analysis, then specify each safety function and assign it a target SIL. Techniques like FMEA feed this work.
• Realization phases: Three parallel planning phases cover operation and maintenance, safety validation, and installation and commissioning. The systems realization phase handles hardware design, software development, integration, failure calculations, and verification against architectural constraints.
• Operation phases: Installation and commissioning, overall safety validation, ongoing operation with proof testing, and modification and retrofit keep the system meeting its safety requirements over its operational life. Decommissioning is also covered.

The lifecycle is iterative by design. Any phase that reveals unmet requirements triggers a feedback loop back to where the gap originated, and that loop is what keeps the trace chain honest when a late discovery forces upstream rework.

Safety Integrity Levels (SIL) and Target Failure Measures

A Safety Integrity Level (SIL) is a quantitative measure of how reliably a safety function performs when demanded. IEC 61508 defines four levels, where SIL 1 delivers the lowest risk reduction and SIL 4 the highest. SIL is a property of the safety function itself, so a component or product on its own doesn’t carry a SIL.

Low-Demand, High-Demand, and Continuous Mode

In low-demand mode, the safety function is demanded no more than once per year. High-demand mode applies when the demand rate exceeds once per year, and continuous mode covers functions that run as continuous control. The mode selection decides which target failure measure applies, and getting it wrong leads to the wrong SIL target, wrong architectural constraints, and an assessment the team can’t defend.

Target Failure Measures by SIL

The table below reproduces the quantitative targets from IEC 61508. PFDavg applies in low-demand mode, and PFH applies in high-demand and continuous modes.

SIL	PFDavg (Low Demand)	PFH per Hour (High Demand / Continuous)	Risk Reduction Factor
SIL 1	≥ 10⁻² to < 10⁻¹	≥ 10⁻⁶ to < 10⁻⁵	> 10 to ≤ 100
SIL 2	≥ 10⁻³ to < 10⁻²	≥ 10⁻⁷ to < 10⁻⁶	> 100 to ≤ 1,000
SIL 3	≥ 10⁻⁴ to < 10⁻³	≥ 10⁻⁸ to < 10⁻⁷	> 1,000 to ≤ 10,000
SIL 4	≥ 10⁻⁵ to < 10⁻⁴	≥ 10⁻⁹ to < 10⁻⁸	> 10,000 to ≤ 100,000

Each SIL is an order-of-magnitude improvement over the level below it, and SIL 4 is the upper bound for complex programmable electronic safety systems.

Determining the Required SIL

SIL determination methods include fully quantitative analysis, semi-quantitative approaches like Layer of Protection Analysis (LOPA), and qualitative methods like risk graphs. The right method depends on the data available and the conventions in the target sector. Once a target SIL is assigned, the design has to clear three hurdles. Probability of failure has to fall within the SIL band, hardware fault tolerance rules have to be met, and systematic capability has to be shown through process evidence tied to a disciplined risk management approach.

Managing Systematic and Random Hardware Failures

IEC 61508 splits dangerous failures into two categories that need different treatment. Random hardware failures happen at statistically predictable rates and are handled through architecture, diagnostics, and quantitative analysis like Failure Modes, Effects, and Diagnostic Analysis (FMEDA). Systematic failures come from design errors, software bugs, specification omissions, or human error, and because their probability can’t be quantified, they’re controlled through disciplined development backed by traceable evidence.

Safe Failure Fraction (SFF) is the ratio of safe failures plus dangerous detected failures to total failures. It gates the architectural constraint tables that set the maximum SIL a team can claim for a given hardware fault tolerance. Type A subsystems have well-defined failure modes and available failure data, so they earn more favorable limits than Type B subsystems with complex elements like microprocessors.

Sector-Specific Derivatives of IEC 61508

IEC 61508 is the parent standard for most sector-specific functional safety frameworks. Where a derivative exists, it inherits the same lifecycle logic while adapting terminology, metrics, and rigor to that industry. The table below summarizes the main derivatives teams encounter.

Sector	Derivative Standard	What Changes from IEC 61508
Automotive (passenger cars)	ISO 26262	Uses Automotive Safety Integrity Levels (ASIL A to D) based on severity, exposure, and controllability.
Process industries	IEC 61511	Applies to Safety Instrumented Systems (SIS) at the plant level and typically caps at SIL 3.
Machinery control	IEC 62061	Introduces the SIL Claim Limit (SILCL), caps at SIL 3, and now covers hydraulic and pneumatic systems.
Railway	EN 50126, EN 50128, EN 50129	Places functional safety inside the broader RAMS framework for reliability, availability, maintainability, and safety.

The split between IEC 61508 and ISO 26262 shows how the inheritance pattern works. ISO 26262 adapts IEC 61508 for passenger cars, and the two are assessed separately because ASIL and SIL aren’t directly interchangeable. IEC 61511 works alongside IEC 61508 in process industries, where component manufacturers certify to IEC 61508 and plant owners and integrators comply with IEC 61511 on the same physical system.

IEC 61508 Certification and Compliance Challenges

IEC 61508 compliance rests on independent assessment backed by process-based evidence that stays current over the system’s life. A functional safety assessment covers both management areas (FSM planning, lifecycle governance, modification control) and technical areas (hardware design, software lifecycle, verification, validation). “Shall” items are mandatory, and “may” items have to be justified when omitted.

The Path to Certification

Third-party certification isn’t mandated by the standard itself, but a functional safety assessment is. The required degree of independence is set by the target SIL and lifecycle phase. Accredited bodies like TÜV SÜD, exida, and Intertek run assessments covering systematic capability, hardware reliability analysis, and safety function testing. Certificate validity varies by body, so teams with long product lifecycles plan for re-assessment from the start.

Common Compliance Challenges

A few recurring patterns show up across assessment reports, and every one traces back to weak process discipline.

• Missing functional safety management plans: Without a project-specific FSMP, teams work with clashing assumptions about proof test intervals, verification methods, and failure rate data sources.
• Late-stage compliance engagement: Retrofitting safety lifecycle documentation onto a finished design costs far more than building the lifecycle from the concept phase.
• Software traceability gaps: Part 3 requires bidirectional traceability between safety requirements, implementation, and verification, which is hard to reconstruct after the fact.
• Copy-paste documentation: Reusing documents from prior projects without adapting them produces contradictions and content that doesn’t reflect the system under assessment.

Every one of these points back to the same core issue of keeping a connected, auditable trace chain from hazard analysis through verification. When that chain breaks, the cost of fixing it usually lands right before an assessment gate.

How Jama Connect Supports IEC 61508 Compliance

A safety requirement changes mid-program, and nobody can see which hardware designs, software components, and test cases are affected. The rework absorbs weeks the schedule doesn’t have, and the assessment date doesn’t move to accommodate it. That is the scenario purpose-built requirements tooling is built to prevent.

Jama Connect® keeps safety requirements, hardware artifacts, software items, and verification evidence connected through Live Traceability™. The bidirectional trace chain from hazard analysis through allocation, design, and test stays live, so it can be reviewed during an assessment instead of reconstructed before one. Jama Connect was certified by TÜV SÜD as a software tool for safety-related development up to SIL 3 under IEC 61508 and up to ASIL D under ISO 26262. When a baselined safety requirement changes, every downstream item like design elements, test cases, and risk entries gets flagged as suspect so owners can see exactly what needs review.

Building an Audit-Ready IEC 61508 Program

Programs that handle IEC 61508 well use the standard to make engineering decisions defensible across a system’s life. When hazard analysis, SIL allocation, design, and verification are connected from day one, the assessment reduces to showing evidence that already exists. Keeping that evidence current across long product lifecycles is where most programs lose ground, and it is where the gap between a well-run program and a scrambling one shows up in real cost.

Jama Connect supports this workflow with Live Traceability across requirements, designs, tests, and risk items, so teams can see where they stand against IEC 61508 at any point in a program. If you want to see how that holds up on your own safety program, start a free 30-day trial of Jama Connect today.

Frequently Asked Questions About IEC 61508

Is IEC 61508 certification mandatory?

IEC 61508 is voluntary in most jurisdictions, but regulatory references, customer requirements for SIL-certified components, and industry practice in high-risk sectors often make it effectively required. What the standard itself requires is a functional safety assessment, not a third-party certificate.

What’s the difference between SIL and ASIL?

SIL under IEC 61508 is a cross-industry metric based on target failure probability or frequency, with four levels (SIL 1 through SIL 4). ASIL under ISO 26262 is an automotive metric derived from severity, exposure, and controllability, with levels QM through ASIL D. There is no direct mapping between the two, so a component sold into both markets needs separate assessments.

Does IEC 61508 apply to software-only products?

Yes, through Part 3, which covers software requirements for safety-related systems. Because Part 3 cannot be applied on its own, a software-only supplier has to show compliance inside the broader system context and target SIL, usually by coordinating with the integrator so the lifecycle evidence maps cleanly to the system safety case.

How long does IEC 61508 compliance typically take?

There is no universal timeline. Duration depends on product complexity, process maturity, the target SIL, and whether a derivative standard also applies. Setting up the safety lifecycle infrastructure before engaging a certification body is one of the few reliable ways to shorten the overall effort.

This blog was authored by Mario Maldario and published on April 30, 2026.