Which edition of IEC 61508 is currently applicable?

The reference edition is IEC 61508:2010, designated Ed 2, published in seven parts. A third edition is under preparation within SC 65A WG 14; no firm public schedule has been communicated. The derived standards have their own publication cycles: ISO 26262 is in its second edition (2018), IEC 61511 in its second edition (2016) with Amendment A1 (2017), EN 50128 has been complemented by EN 50657 (on-board embedded software). Manufacturers must verify, on each project, which edition the authority or the customer has pinned.

How is the SIL of a safety function determined?

SIL is allocated to each Safety Instrumented Function (SIF, or safety function) identified by the risk analysis. The sequence is: identification of hazards and hazardous events (HAZOP, what-if, safety study), assessment of the risk without mitigation, identification of the required safety functions, allocation of a target SIL to each function using a recognised method (LOPA, risk graph, risk matrix). SIL is not a property of a product; it is a property of the safety function. A single PLC can carry one SIL 2 SIF and one SIL 3 SIF simultaneously, provided the most demanding requirements are honoured on the relevant paths.

What is the difference between PFD_avg and PFH?

IEC 61508 distinguishes safety functions in low-demand mode and high-demand or continuous mode. For low-demand mode (typically fewer than one demand per year), the target is expressed as PFD_avg, average probability of failure on demand. For high-demand or continuous mode, the target is expressed as PFH, probability of dangerous failure per hour. The numerical ranges per SIL are fixed in Part 1 of the standard, tables 2 and 3. The mode of operation for a function is selected based on the real expected demand frequency.

What do HFT and SFF mean?

HFT is Hardware Fault Tolerance, the number of additional failures the architecture can sustain while still performing the safety function (0, 1 or 2). SFF is Safe Failure Fraction, the share of failures that are either safe or detected over the total failures. For Type A subsystems (well-characterised failure behaviour), HFT and SFF together set a lower bound on the achievable SIL according to Table 2 of Part 2 (Route 1H). For Type B subsystems (poorly characterised failure behaviour), Table 3 of Part 2 applies with stricter requirements. Route 2H opens an alternative based on proven reliability data, without relying on the SFF bound.

Do ISO 26262 and IEC 61511 replace IEC 61508 in their sector?

Yes on the sector scope, no on the genealogy. ISO 26262 (automotive, originally road vehicles below 3.5 t, extended since to trucks, motorcycles and buses) supersedes IEC 61508 for vehicle-series components; it introduces ASIL (A to D) in place of SIL and adapts the lifecycle. IEC 61511 (process industry) supersedes IEC 61508 for the on-site safety-instrumented-system integrator; equipment vendors are still typically assessed under IEC 61508, with a reusable "compliant item" claim that the integrator carries forward. EN 50128 / EN 50657 play the equivalent role for railway software, IEC 62061 for machinery (in parallel with ISO 13849), and IEC 60601-1 covers medical devices through an ISO 14971 risk approach without a formal SIL.

What does "SIL 3 capable" mean on a component datasheet?

A microcontroller, transmitter or PLC datasheet may declare "IEC 61508 SIL 3 capable" or "SIL 2 / SIL 3 capable": the precise wording indicates that the component has been assessed by a third-party assessor and is usable in a safety function up to the declared SIL, subject to integration in line with the supplied safety manual. This status is referred to as a "compliant item" in 61508 language. It does not relieve the integrator from justifying SIL achievement at the complete-function level (architecture, diagnostics, reliability data, validation); it provides a reusable building block with its PFH figures, its SFF, its usage constraints and its application requirements.

Who assesses an IEC 61508 dossier and what is the role of FSA?

Assessment is conducted by a functionally independent assessor, the Functional Safety Assessor, who may be internal or third-party depending on the SIL and the manufacturer's Functional Safety Management policy. Part 1 of the standard requires increasing independence as SIL rises: person independence for SIL 1, department independence for SIL 2, organisation independence for SIL 3 and SIL 4. The Functional Safety Assessment (FSA) is the formal review activity; it is complemented by confirmation measures (audits, reviews, verifications) throughout the lifecycle. For a product sold as SIL-capable, the third-party assessor is typically a recognised body (TUV Rheinland, TUV SUD, exida, DEKRA, and so on).

IEC 61508: generic functional safety and SIL levels

Q: What is the role of IEC 61508?

IEC 61508 is the international generic functional-safety standard for electrical, electronic and programmable electronic (E/E/PE) safety-related systems. Published by the International Electrotechnical Commission and maintained by sub-committee SC 65A (working group WG 14) of Technical Committee TC 65, it defines the concept of Safety Integrity Level (SIL 1 to 4), the safety lifecycle, and the requirements covering both random hardware failures and systematic failures, including software. It acts above all as a parent standard: the sector standards ISO 26262 (automotive), EN 50128 / EN 50657 (railway software), IEC 61511 (process industry) and IEC 62061 (machinery) are direct derivations from it.

Author Hugues Orgitello Last updated 27 May 2026 ~14 min read

Guide · IEC 61508

IEC 61508 is the generic functional-safety standard for electrical, electronic and programmable electronic safety-related systems (E/E/PE systems). First published in 1998, restructured in 2010 (Edition 2), and maintained by sub-committee SC 65A WG 14 of the International Electrotechnical Commission, it defines the concept of Safety Integrity Level (SIL 1 to 4), the safety lifecycle, the architectural requirements on random hardware failures, and the requirements on systematic failures, including software. Its main role is that of a parent standard: the sector standards ISO 26262 for automotive, EN 50128 and EN 50657 for railway software, IEC 61511 for process industry, and IEC 62061 for machinery are direct derivations. This page sets out the seven-part structure, the SIL classification, the allocation approach through HAZOP and LOPA, the Route 1H constraints on HFT and SFF, and the tree of derived standards.

Seven-part structure

IEC 61508:2010 is published in seven parts that span the entire safety lifecycle, from concept through to decommissioning. The breakdown is useful for scoping a project and for locating a requirement or a table during a review.

Part	Topic	Indicative content
Part 1	General requirements	Overall safety lifecycle, Functional Safety Management, competency requirements, SIL allocation, FSA and confirmation measures, tables of PFD_avg and PFH ranges per SIL
Part 2	Requirements for E/E/PE safety-related systems	Hardware architecture, Type A and Type B subsystems, HFT/SFF/SIL tables (Routes 1H and 2H), diagnostics, integration, integration of "compliant items"
Part 3	Software requirements	Software lifecycle, techniques and measures per SIL, restricted languages, defensive coding, testing, verification and validation, requirements on pre-existing software
Part 4	Definitions and abbreviations	Normative vocabulary: SIL, SIF, PFD, PFH, HFT, SFF, random vs systematic failure, low-demand vs high-demand mode
Part 5	Examples of methods for the determination of SIL	Quantitative and semi-quantitative methods, ALARP (As Low As Reasonably Practicable), risk graph, calibration of criteria
Part 6	Guidelines on the application of Parts 2 and 3	Worked examples, PFD_avg / PFH calculations by architecture, diagnostic techniques, component integration
Part 7	Overview of techniques and measures	Annotated catalogue of techniques (formal, semi-formal, defensive) referenced in the normative annexes of Parts 2 and 3

Parts 1 to 4 are normative in the strict sense. Parts 5, 6 and 7 are informative: they do not add requirements, but their worked examples are often cited during assessor reviews to justify an architectural choice or a coding technique.

SIL, SIF and functional chain

SIL is not an attribute of a product; it is an attribute of a Safety Instrumented Function (SIF), or safety function. A SIF is an E/E/PE function that keeps or brings a process into a safe state when a hazardous event occurs. It is implemented by a complete functional chain: sensor, logic processing (PLC, microcontroller, software function), actuator, together with the associated diagnostics, power supply and communication paths.

A typical process safety function:

sensor: pressure transmitter on a storage tank,
logic: safety PLC comparing the measurement against a setpoint,
actuator: shut-off valve with fail-safe spring return,
diagnostics: cyclic self-tests of the transmitter and PLC, valve position readback,
power and communication: redundant power supply, safety bus (PROFIsafe, openSAFETY, FSoE depending on context).

The SIL allocated to this SIF flows from the risk analysis, not from a product catalogue. A single installation may carry SIFs at different SILs, which is the rule in a refinery or a chemical plant, and the exception only on a standard product where one dominant SIF shapes the design.

SIL 1 to 4: PFD_avg and PFH bands

Part 1 of IEC 61508:2010 sets the numerical ranges per SIL in tables 2 (low-demand mode) and 3 (high-demand or continuous mode). The values below are those published in the standard, reproduced here for reference; any regulatory application points back to the pinned IEC document.

SIL	Low-demand mode: PFD_avg	High-demand / continuous mode: PFH (per hour)
SIL 4	>= 10^-5 to < 10^-4	>= 10^-9 to < 10^-8
SIL 3	>= 10^-4 to < 10^-3	>= 10^-8 to < 10^-7
SIL 2	>= 10^-3 to < 10^-2	>= 10^-7 to < 10^-6
SIL 1	>= 10^-2 to < 10^-1	>= 10^-6 to < 10^-5

The choice of operating mode is driven by the expected demand frequency on the function. The conventional threshold is one demand per year: above that, the function is in high-demand mode and the target unit is PFH; below it, the function stays in low-demand mode with PFD_avg. For a protection function triggered by rare events (anti-overflow of a tank), low-demand is usual. For a continuous function (speed regulation, anti-collision), high-demand is the rule.

SIL 4 is an extreme level reserved for a handful of catastrophic-process applications (nuclear power, certain major chemical installations). The vast majority of industrial, automotive and machinery SIFs sit between SIL 1 and SIL 3. ISO 26262 caps at ASIL D, which corresponds roughly to SIL 3 in terms of architectural constraints (the correspondence is not strict, as the two standards diverged on the target metric).

Random vs systematic failures

One of the structural contributions of IEC 61508 is the distinction between random and systematic failures. That distinction governs the nature of the applicable requirements.

Random hardware failures: failures occurring stochastically over time, driven by hardware physics (wear, fatigue, thermal drift, latent manufacturing defect). They are characterised by a failure rate lambda, split into lambda_sd (safe detected), lambda_su (safe undetected), lambda_dd (dangerous detected) and lambda_du (dangerous undetected). The SIL targets on PFD_avg and PFH are essentially about these failures.
Systematic failures: failures resulting from an error in specification, design, implementation, integration or use. A software failure is, by construction, systematic: a bug is either present or absent, it does not appear spontaneously. IEC 61508 does not propose a quantitative bound on the probability of systematic failure (the community accepts there is no universal method for quantifying it); instead it imposes a set of techniques and measures whose rigour scales with the SIL.

This duality explains why SIL is not "computed" from PFH or PFD_avg alone: a dossier that demonstrates a SIL 3 compliant PFD_avg but fails to apply the Part 3 techniques on software does not sustain the SIL 3 claim.

SIL allocation: HAZOP, LOPA, risk graph

Allocating a SIL target to each SIF is done with a recognised method. Three approaches dominate.

HAZOP (HAZard and OPerability study): structured investigation by guide words (no, more, less, as well as, part of, reverse, other than) applied to process parameters, conducted by a multidisciplinary team. It identifies possible deviations and their consequences, feeding into a risk matrix. HAZOP is widespread in chemicals and oil and gas, and remains the upstream stage for identifying SIFs.

LOPA (Layer Of Protection Analysis): semi-quantitative analysis that counts the independent protection layers (IPL) between an initiating event and a hazardous event, comparing the residual risk to a tolerability criterion. The SIF is dimensioned to close the gap between tolerable risk and residual risk after the non-SIS layers. LOPA is the reference tool in process industry, codified by IEC 61511 Part 3.

Risk graph: graphical method, calibrated through parameters (consequence, exposure, avoidability, frequency), leading to a SIL target. Part 5 of IEC 61508 gives a calibration example, warning that any calibration must be justified by the application context. Risk graph is widely used in automotive (HARA, Hazard Analysis and Risk Assessment, is the calibrated equivalent for ASIL in ISO 26262) and in machinery.

Other methods are accepted: Fault Tree Analysis (FTA), Markov, criticality analysis (FMEDA, Failure Modes, Effects and Diagnostic Analysis) at component level. What matters is not the method itself; it is the documented justification of the allocation, traceable to the quantitative target PFD_avg / PFH and to the requirements on software and integration.

Route 1H: HFT and SFF

Part 2 of IEC 61508:2010 sets an architectural constraint that caps the achievable SIL based on Hardware Fault Tolerance (HFT) and Safe Failure Fraction (SFF) of the subsystem. This is Route 1H, the "architectural constraints route". An alternative Route 2H builds on proven reliability data and does not reproduce the tables below.

Subsystems are classified into two types according to how well the failure modes are characterised:

Type A: well-characterised failure modes, known behaviour in fault condition, available field data. Simple discrete components, contacts, relays, analogue transmitters.
Type B: failure modes not fully characterised, or behaviour in fault not fully specified. Microcontrollers, complex ASICs, FPGAs, programmable components with firmware.

Table 2 (Type A subsystems), Route 1H:

SFF	HFT = 0	HFT = 1	HFT = 2
< 60 %	SIL 1	SIL 2	SIL 3
60 % to < 90 %	SIL 2	SIL 3	SIL 4
90 % to < 99 %	SIL 3	SIL 4	SIL 4
>= 99 %	SIL 3	SIL 4	SIL 4

Table 3 (Type B subsystems), Route 1H, stricter:

SFF	HFT = 0	HFT = 1	HFT = 2
< 60 %	not allowed	SIL 1	SIL 2
60 % to < 90 %	SIL 1	SIL 2	SIL 3
90 % to < 99 %	SIL 2	SIL 3	SIL 4
>= 99 %	SIL 3	SIL 4	SIL 4

Practical takeaway: a Type B subsystem (typically a general-purpose microcontroller) at HFT 0 (no redundancy) cannot carry a function beyond SIL 2, and even then only if SFF is high enough. To reach SIL 3 on software, two common routes: a 1oo2D architecture (one channel out of two with diagnostics) at HFT 1 with SFF between 60 % and 90 %, or a specialised Type B component (lockstep, internal redundancy, on-die diagnostics) achieving SFF >= 90 % at HFT 0.

Self-diagnostics is central: the more dangerous failures the diagnostics detects, the higher the SFF, and the higher the achievable SIL. Much of the SIL 3 / SIL 4 design effort goes into internal diagnostic mechanisms (RAM test, ROM test, independent watchdog, channel comparison, ECC on memories, and so on).

Architectures and MooN notation

IEC 61508 uses MooN notation (M-out-of-N) to describe the architectural voting of a safety chain, with or without diagnostics. The common variants:

1oo1 (1-out-of-1): a single channel with no redundancy. The Route 1H ceiling on Type B is harsh, generally limited to SIL 1 or SIL 2 depending on SFF.
1oo1D: a single channel with diagnostics; the diagnostic drives the system to a safe state when a fault is detected. SFF is typically higher, but HFT stays at 0.
1oo2 (1-out-of-2): two parallel channels, either alone is sufficient to execute the safety function; good availability, but sensitive to Common Cause Failure (CCF).
2oo2: two channels in series, both must vote for execution; minimises spurious trips but weakens safety (a single channel can mask a dangerous failure).
1oo2D: two channels with diagnostics, the most common architecture for SIL 3 on Type B. The diagnostic identifies the failed channel and falls back to the healthy one.
2oo3: three channels with majority voting, a strong availability/safety compromise used on critical processes (power plants, refineries).

Computing PFD_avg for a MooN architecture combines channel failure rates, diagnostics, the proof-test interval (T1), and the Common Cause Failure share (beta, beta_D in the IEC 61508-6 formulation). The formulas in Part 6 Annex B give analytical expressions per architecture. A typical beta of 1 to 10 % can dominate the PFD_avg of a redundant architecture: design effort therefore targets beta reduction through diversification (distinct hardware channels, diversified software, separate power supplies, sensors of different technology).

Safety lifecycle and software per SIL

Part 3 organises the software requirements around a V-cycle: software architecture specification, module specification, coding, unit testing, integration, validation. At each stage, techniques and measures are listed in normative annexes with a recommendation level per SIL: "HR" (Highly Recommended), "R" (Recommended), "NR" (Not Recommended), "---" (no recommendation).

A few salient requirements per SIL:

SIL 1: dynamic module testing, defensive coding, formal code review, identification of input/output data.
SIL 2: semi-formal specification techniques (HR), formal inspection review (HR), statement and branch coverage testing.
SIL 3: semi-formal or formal techniques (HR), MC/DC coverage often requested, extended static analysis (HR), integration tests with temporal performance verification (HR), language restriction (safe subset such as MISRA C for C, no dynamic memory allocation during operation).
SIL 4: formal techniques HR for critical portions, languages with restricted semantics, qualified development environment (compiler qualification), formal proofs or advanced static analysis.

Pre-existing software (PSW, Pre-existing Software; SOUP, Software Of Unknown Pedigree) is handled by a dedicated mechanism. A commercial OS, middleware or library can be integrated into a SIL-N SIF provided its assessment is documented: documentation review, known-defect analysis, dedicated testing, restriction of use, defensive wrapping. The simplest route is to select a component already assessed by a third-party assessor as a "compliant item".

Functional Safety Management and competency

Part 1 imposes a Functional Safety Management (FSM): organisation, processes, resources, planning, document and configuration management, change management, non-conformance handling, lessons-learned management. The FSM is verified during the FSA and during surveillance audits.

The competency requirements (Part 1 Clause 6) require every actor with a role in the safety lifecycle to be competent for the role held, with that competency documented. The criteria include training, experience, authority, and understanding of the application context. For SIL 3 and SIL 4 projects, industry has converged on recognised individual qualifications (Certified Functional Safety Engineer / Expert delivered by TUV Rheinland, exida, TUV SUD, CFSE / CFSP), though the standard does not require them explicitly.

Assessor independence rises with SIL:

SIL	Required FSA independence
SIL 1	Person independence (the assessor is not the direct author)
SIL 2	Department independence
SIL 3	Organisation independence (typically third-party assessor)
SIL 4	Organisation independence, generally an accredited body

Confirmation measures complement the FSA: phase audits, milestone reviews, independent verifications, traceability of corrective actions. They are distinct from internal project reviews; they carry the character of independent attestation.

Derivation to sector standards

The IEC 61508 architecture has spawned a family of sector standards that inherit its skeleton (lifecycle, integrity levels, techniques per level), adapted to the constraints and vocabulary of each sector.

Sector	Derived standard	Integrity level	Specifics
Process industry	IEC 61511	SIL 1 to 4 (same as 61508)	SIS / SIF / IPL vocabulary, LOPA codified in Part 3, separation between equipment vendor (under 61508) and integrator (under 61511)
Automotive	ISO 26262	ASIL A to D	HARA in place of HAZOP, controllability added to severity and exposure, dedicated work products, qualification of components ("SEooC", Safety Element out of Context)
Railway (software)	EN 50128 + EN 50657	SIL 0 to 4 (SSIL)	SSIL 0 for non-safety items, signalling (50128) split from on-board (50657)
Railway (system)	EN 50126 + EN 50129	SIL 1 to 4	RAMS approach (Reliability, Availability, Maintainability, Safety), detailed Safety Case for acceptance by national authority
Machinery (control)	IEC 62061	SIL CL 1 to 3 (SIL claim limit)	Capped at SIL 3, compatible approach with ISO 13849 (which uses Performance Levels PL a to e in a parallel approach)
Medical	IEC 60601-1 + ISO 14971	No formal SIL, risk approach via MOOP/MOPP and essential performance	For software, IEC 62304 classifies into A, B, C, in a parallel approach to 61508
Nuclear	IEC 61513	Categories A, B, C	Dedicated approach, cross-references to 61508 on architectures

An important caveat: sector standards do not mechanically reproduce IEC 61508; they adapt it. A SIL 3 claim under IEC 61508 is not automatically equivalent to an ASIL C or ASIL D claim under ISO 26262. A component developed under 61508 and reused in a 26262 project goes through a documented gap analysis, justifying the reuse against the sector-specific requirements.

"Compliant item" and proven-in-use

A commercial component can be integrated into a SIF of a given SIL through two routes, short of full development under the targeted SIL.

Compliant item: the supplier has had the component assessed by a third-party assessor under IEC 61508 Part 2 (hardware) and Part 3 (software), and publishes a certificate together with a safety manual. The safety manual lists the figures to feed into the PFD_avg / PFH calculation (lambda_dd, lambda_du, lambda_sd, lambda_su, SFF), the integrated diagnostics, the usage assumptions and the application constraints. The integrator carries those figures into its own dossier and strictly applies the safety-manual constraints. "SIL 2 / SIL 3 capable" microcontrollers and SoCs (TI Hercules, Infineon AURIX, Renesas RH850, ST SPC58, etc.), safety PLCs (Siemens S7-1500F, ABB AC800M HI, Rockwell GuardLogix), and process transmitters (Emerson, Yokogawa, ABB) fall into this category.

Proven-in-use: the component has not been formally assessed under 61508, but its field record demonstrates sufficient reliability. The conditions are strict (Part 7): documented usage over a significant duration, on a statistically significant population, in a comparable environment, with traced failure reporting. A proven-in-use justification is harder to document than it first appears; it remains uncommon in practice for reaching SIL 3 on a complex component, more common for SIL 1 / SIL 2 on simple components.

A "standard industrial" microcontroller without a 61508 certificate and without a proven-in-use dossier cannot directly carry a SIF of SIL 2 or higher. It can be used in a subsystem implementing a redundant architecture with an independent diagnostic channel, but the architectural effort (1oo2D, channel comparison, external monitoring) increases sharply.

Common pitfalls observed in the field

Several recurring pitfalls show up in integrator and assessor feedback.

Confusion between component SIL and function SIL: a "SIL 3 capable" component does not make a SIL 3 SIF. The complete SIF (sensor + logic + actuator + diagnostics + power) must reach the PFD_avg / PFH target at system level, and every element must satisfy the Route 1H or Route 2H constraints.
HFT 0 architecture on Type B aiming at SIL 3: not allowed under Route 1H unless SFF >= 99 %. Very few Type B components reach that SFF at HFT 0 without internal redundancy; the design is usually forced into a 1oo2D architecture or into a lockstep component.
Software techniques not aligned with the SIL: MISRA C compliance is not sufficient for SIL 3 if extended static analysis, MC/DC coverage, development-environment qualification, and semi-formal or formal specification are missing.
Safety manual not applied: the safety manual of a "compliant item" carries usage assumptions (junction temperature, supply voltage, clock frequency, peripheral configuration) and application constraints (mandatory diagnostic cadence, proof-test interval, restriction on internal functions). Any deviation invalidates the component's SIL claim.
Confusion between proof test and self-diagnostics: internal self-diagnostics runs continuously and catches a fraction of dangerous failures (measured by SFF). The proof test is a periodic, typically annual, manual test that catches dangerous failures missed by the diagnostics. Both feed into PFD_avg, but they are distinct objects.
Subcontracted integration without FSM dossier transfer: a vendor that ships SIL-capable hardware without transferring the safety manual and the assumptions does not let the integrator close its dossier; the final assessor sends the package back as-is.
Unjustified SIL allocation: a SIL allocated without explicit linkage to a risk analysis (documented HAZOP, LOPA or risk graph) is generally requalified during assessment, sometimes downwards, sometimes upwards.
Confusion between parent and derived standards: a supplier certified under IEC 61508 SIL 3 does not relieve the automotive OEM from a gap analysis to ASIL; a PLC vendor certified under 61508 does not relieve the site integrator under IEC 61511 from their own SIF analysis.

Proof test, MTTR and calculation assumptions

The PFD_avg of a safety function in low-demand mode is computed over the duration of one proof-test cycle, interval T1, after which the function is verified in full, often manually, sometimes partially. The shorter T1 is, the lower PFD_avg, but operational cost climbs; a typical compromise on a process installation is T1 = 1 year, sometimes extended to 3 or 5 years with a partial proof test (PTC, Proof Test Coverage, usually between 60 and 95 %).

The MTTR (Mean Time To Restoration) applies to failures detected by the diagnostics: it is the average time between fault detection and return to operational state after repair. For a function in high-demand or continuous mode, MTTR weights the PFH directly, because the function is unavailable during repair.

The T1 / MTTR pair drives PFD_avg / PFH as much as the lambda rates do. A well-specified 1oo2D chain with low lambda_du but T1 = 10 years can exceed its SIL target; the same chain with T1 = 1 year stays comfortably within the band. The proof test is not an accessory; it is part of the safety case.

Calculation assumptions (T1, MTTR, beta, detailed lambdas, diagnostic coverage) must be explicitly listed in the component's safety manual and carried into the integration dossier. An assessor review systematically checks the consistency between the stated assumptions and the actual operating conditions, including environmental temperature range, vibration class, and proof-test procedure feasibility on site. A safety case that reports a compliant PFD_avg but relies on a T1 the operator cannot meet in practice is treated as non-compliant on review.

Certificate validity and maintenance

A third-party IEC 61508 certificate is typically valid for 3 to 5 years, with annual or biennial surveillance audits. Any significant change to the product (board revision, major firmware update, change of supplier on a critical component) triggers a delta review of the safety case. Change management is codified by Part 1 of the standard: each modification is subject to an impact analysis, a traceable review, a validation-dossier update and, depending on severity, a partial or full new FSA.

For the full glossary of terms used here (SIL, SIF, PFD_avg, PFH, HFT, SFF, FSA, FSM, ALARP, HAZOP, LOPA, Route 1H, compliant item, proven-in-use), see the glossary.

Articulation with CE marking

IEC 61508 is not itself a harmonised standard under Regulation (EU) 2023/988 (general product safety) or the Machinery Regulation (EU) 2023/1230, but its derivatives are. For a machine, IEC 62061 or ISO 13849 provide presumption of conformity on the safety-related control-systems side. For process equipment, IEC 61511 (transposed as EN 61511). For a vehicle, ISO 26262, articulated with the EU type-approval regulation.

For CE marking of products containing a safety function, the issue is to demonstrate that the allocated SIL is achieved by the integrated components, and that the safety documentation (safety case, safety manual for the end-user, operating manual, required training) is available. Moving from a 61508 dossier to a CE dossier is not a change of standard; it is an assembly: the harmonised sector standard provides the presumption, the underlying 61508 dossier provides the technical traceability.

For the general framework of CE marking, see the CE page and the harmonised standards. For sector deep-dives, see ISO 26262 (automotive) and EN 50128 / EN 50657 (railway software).