If you size safety functions for a living, ISO 13849-1 is the document you reach for most. It is the standard that turns a risk assessment into a number you can engineer to: a Performance Level, built from the architecture category, the channel MTTFD, the diagnostic coverage and the common-cause failure score. The 3rd edition from 2015 has been the working reference for the better part of a decade. The 4th edition — ISO 13849-1:2023 — was published in April 2023, and it is the version your auditor will increasingly expect to see cited.
The good news first: this is not a teardown. The categories are the same. PL a through PL e are the same. MTTFD, DC and CCF still combine in the same way to give a PL, and the designated architectures you already know are still there. A well-built 2015 calculation does not suddenly become wrong. What the 4th edition does is tighten the wording, fill in the gaps the 2015 text left to interpretation, and give software the attention it now deserves. The honest summary: same model, sharper rules, more evidence expected.
What actually changed in the 4th edition
Rather than quote clause numbers, it is more useful to talk about the areas where the revision lands, because that is where your re-verification effort should go. At a concept level, the 4th edition strengthens these themes:
- Safety-related software. The clearest expansion. Both the application software you write for a safety controller (SRASW) and the embedded-software (SRESW) aspects of components get fuller, more explicit treatment, with a software lifecycle expected to match the target PL.
- MTTFD, DC and CCF guidance. Clearer direction on how to derive and combine the reliability inputs, how to handle the data you rely on, and how the common-cause failure measures are scored and justified.
- Fault exclusion. Tighter expectations on when a fault may be excluded and how that exclusion must be justified and recorded. Unjustified or undocumented fault exclusions are a recurring audit weakness, and the revision does not make them easier to wave through.
- Safety lifecycle and validation. A fuller, more lifecycle-oriented treatment — specification through verification and validation — aligning the design process more closely with how functional safety is handled elsewhere.
- Clarifications throughout. Many smaller edits that remove ambiguity from the 2015 text. Individually minor; together they raise the bar on what counts as a defensible calculation.
Notice what is not on that list: no overturned PL table, no retired categories, no new mathematics that invalidates the SISTEMA libraries you already use. That is why “re-verify” is the right verb, not “rebuild”.
Why the timing matters: the 2027 Regulation
A revised standard would be worth a quiet read at any time. What makes ISO 13849-1:2023 worth acting on now is the regulatory clock. The EU is moving from Machinery Directive 2006/42/EC to Regulation (EU) 2023/1230, which becomes mandatory for machinery placed on the EU market from 20 January 2027. As part of that move, the list of harmonised standards that confer presumption of conformity is being re-published to reference the Regulation rather than the Directive.
ISO 13849-1 is one of the cornerstone standards in that list. So two things matter together in your technical file: the edition of the standard you designed to, and its harmonisation status under the framework you are claiming conformity to. The defensible position is to design to the current published edition and to confirm the current Official Journal harmonised list for your machine type, rather than carrying forward a citation you wrote three years ago. We keep a running view of this in our companion piece on the Machinery Regulation harmonised standards list for 2026.
The safety function is a chain, not a device
A point worth restating, because it is where PL calculations most often go wrong. ISO 13849-1 rates a complete safety function — the sensor that detects the hazard, the logic that processes it, and the actuator that removes the hazard — not any single box. Your input subsystem might be a safety light curtain; your logic a safety relay or safety controller; your output the contactors that drop the motor. The PL you can claim is governed by the whole chain.
This is why presence-sensing device choice feeds directly into the SRP/CS calculation. If your function must reach PL e, every subsystem in the chain has to be capable of supporting PL e. A Type 4 electro-sensitive protective equipment (ESPE) light curtain rated to PL e, built to IEC 61496-1 and -2 with dual OSSD outputs, gives you a high-integrity input you can carry into the calculation with confidence. Drop in a lower-rated sensor and the whole function is capped at that lower level, no matter how good the logic and output stages are. (For when PL e is actually required, rather than merely nice to have, see our note on when Type 4 / PL e / SIL 3 is mandatory.)
The 4th edition does not change ESPE device requirements — those live in IEC 61496 — nor the safety-distance rules in ISO 13855. What it asks is that you bring the device’s published safety characteristics correctly into the SRP/CS calculation, and that the logic between sensor and actuator carries proper software evidence where software is involved.
What to revisit: a practical checklist
None of the following requires a redesign. It is disciplined verification, function by function. Before your next audit, for each safety function:
- Confirm the required PL. Check it against a current risk assessment, not one that predates the latest machine configuration. If the required PL moved, everything downstream has to follow.
- Re-check MTTFD per channel. Validate the component reliability data and the mission time you assumed. Stale B10D figures or an over-optimistic mission time quietly erode a result.
- Verify diagnostic coverage. Make sure the DC you claimed is actually delivered by real diagnostics in the implementation — not a value copied from a template.
- Re-score CCF. Confirm the common-cause failure measures you scored are the ones genuinely implemented on the machine.
- Audit every fault exclusion. Each one must be justified and documented to the 4th-edition expectations. This is the single most common place a calculation falls down in review.
- Gather software evidence. Where the function includes safety-related software, assemble the lifecycle evidence — specification, design, verification and validation, configuration management — appropriate to the PL.
- Update the citation. Confirm the edition and harmonisation status you reference in the technical file are current for the framework you are claiming conformity to.
The bottom line for machine builders
ISO 13849-1:2023 is the kind of revision that rewards quiet diligence. The model you know still works, so most of your existing PL results will survive a careful re-verification intact. The exposure is not in the numbers — it is in the justification: thin software evidence, fault exclusions taken on trust, reliability data that has aged, and citations that point at the wrong edition. Tidy those now, while the 2027 deadline is still ahead of you, and the standards transition becomes a paperwork exercise rather than a scramble in front of an auditor.