IEC 61508 divides functional-safety work between the device maker and the system integrator: makers establish the safety capability of a product, while integrators determine how that product satisfies a defined safety function in the installed system [S1][S4].
A typical electrical, electronic, and programmable electronic safety-related system comprises input devices, a controller, and output devices or final elements [S1].
Where the responsibility boundary sits
IEC 61508 describes functional safety as the part of overall safety that depends on a system or equipment operating correctly in response to its inputs [S1]. For a device maker, the deliverable is therefore not merely a tested instrument or controller, but documented evidence about the product's intended use, failure behavior, safety parameters, and limitations.
A typical E/E/PE safety-related system comprises input devices, a controller, output devices, and final elements [S1]. Neither decision can be delegated to a catalog specification.
A practical allocation is:
Device maker: define the product, safety-related specification, architecture, hardware and software failure behavior, verification results, assumptions of use, and declared safety parameters.
Integrator: perform site-specific hazard analysis and risk assessment, select and combine elements, define the safety function, allocate SIL requirements, design the application, establish interfaces, validate the complete system, and maintain the operational safety case.
Device-maker evidence scope
The device maker should produce a claim that is precise enough for an integrator to use without guessing. IEC 61508-3 addresses software lifecycle and product development, while the demand for continuous, bidirectional traceability from hazard analysis through requirements, design, implementation, and verification is described as a challenge that development organizations struggle to deliver [S5]. Device-level software documentation must therefore connect the safety requirements to code and test evidence rather than relying on an isolated certificate or generic datasheet.
For a safety sensor, the evidence package may need to cover the sensing principle, diagnostic coverage, failure modes, output behavior under fault, electrical interfaces, environmental limits, and the conditions under which the safety claim remains valid. For a safety controller, it must additionally cover software requirements, architecture, coding controls, verification, tool qualification where applicable, and configuration management.
Software evidence is not a document exercise. ISO 26262 addresses automotive software, while IEC 61508-3 addresses safety-critical software across industries [S5].
The device maker must also state assumptions clearly. A declared safety capability applies only under the specified architecture, configuration, diagnostic assumptions, maintenance conditions, and external interfaces. If the integrator changes a sensor response time, alters a controller task cycle, removes a redundant channel, or substitutes an output element, the original product evidence does not automatically cover the modified system.
Integrator responsibility and system evidence
The integrator owns the argument that the installed combination is suitable for the hazard. That system boundary can extend from one interlock loop to an emergency shutdown, fire and gas, or turbine-control application.
This matters particularly where an emergency stop is only one element. The integrator must prove that the initiating device, logic, output, final element, response time, and reset philosophy work together for the defined hazard.
Device or system certification, by decision criteria
Compare the two scopes against the question being answered, required evidence, configuration freedom, and lifecycle ownership.
For a standalone safety component with a stable architecture, start with device-level evidence and then map its limitations into the system file. For a multi-vendor shutdown chain, burner-management system, or safety instrumented arrangement, require application-specific analysis and validation even when every component has credible product documentation.
Who should use which approach
Device makers should use IEC 61508 when they design products intended for safety-related E/E/PE applications and need evidence that an integrator can assess. IEC 61508 provides product-manufacturers with guidance for designing safety-related equipment, while the product standard and product-level assessment form part of a broader conformity route [S4].
Integrators should use IEC 61508 as the umbrella framework for lifecycle and system assurance. The framework is deliberately generic and can be complemented by sector standards for process industry, machinery, or product-specific applications [S1][S8].
IEC 61508 is not the right sole framework for every machine. ISO 13849 addresses machine safety, whereas IEC 61508 covers the full functional-safety lifecycle. Where a machine-safety requirement is governed by ISO 13849, that route should not be replaced with generic IEC 61508 language (2026-04) [S7]. For process-sector applications, IEC 61511 is the sector-specific route built around the IEC 61508 framework [S8].
Manufacturers of simple mechanical products, non-E/E/PE devices, or products with no role in a safety function generally do not need to create an IEC 61508 product claim. A supplier should nevertheless identify whether its product is a safety-related element, a standard equipment item, or part of the selected architecture, because that classification changes the documentation and interface obligations.
Common evidence failures
The most frequent failure is treating certificate status as system approval. IEC 61508 certification can support confidence in a supplier's product or management system, but it does not replace the integrator's hazard analysis, risk assessment, application design, and validation [S2][S6].
A second failure is broken traceability. If a hazard no longer maps to a safety requirement, design element, implementation record, and verification result, assessors cannot determine whether the safety argument still holds after engineering changes (2026-03) [S5].
A third failure is treating component diagnostics as system diagnostics. A sensor can perform a self-test, but the complete chain may still contain an undetected failure in wiring, logic, output elements, final elements, or shared services. The integrator must analyze the arrangement, including common-cause and systematic effects where relevant.
A fourth failure is undocumented use limits. A device's declared assumptions may omit maximum response time, minimum voltage, permitted load, diagnostic interval, environmental range, storage conditions, or required maintenance. A datasheet parameter without an operating boundary is not a safety specification.
A fifth failure is changing a certified product in a way that invalidates its evidence. Modification control must identify affected requirements, failure analyses, tests, and safety claims. For proof-test intervals, the interval must follow the selected risk basis and device characteristics rather than an arbitrary calendar schedule; the linked guide explains how to set safety-function proof-test intervals from risk.
Procurement and assurance checklist
Before accepting a device maker's IEC 61508 evidence, request the product identification, intended purpose, safety-relevant specification, architecture, permitted configurations, failure and diagnostic assumptions, interfaces, verification records, and declared limitations. Certification body and accredited scope should match the product and activity being claimed, not just the supplier's organization. [S5]
Before releasing an integrator's safety case, confirm that it identifies the protected hazard, safety function, target SIL, proof-test interval, response time, environmental constraints, final-element behavior, bypass controls, operating procedures, and maintenance provisions. It should also show which evidence came from each device maker and which conclusions were established at system level.
Change control should route product changes through both parties. The maker identifies whether the change affects the product's safety claim; the integrator determines whether the application remains valid. For connected machinery, a functional-safety assessment should also account for cybersecurity risks and network architecture, but cybersecurity certification does not automatically establish functional-safety conformity.
The decision is therefore straightforward: a device maker supplies reusable, assumption-bound product evidence, while an integrator supplies the application-specific argument that the complete safety function adequately controls the identified risk.