Inherent safety by design means eliminating a hazard at the source rather than managing it after the fact. EN ISO 14971:2019+A11:2021 clause 7.1 places it first in the risk control hierarchy, and MDR Annex I §4 requires it where technically feasible. An inherently safe design is the only control that cannot fail in use, because the hazard is no longer there.

By Tibor Zechmeister and Felix Lenhard.

TL;DR

  • Inherent safety by design is tier 1 of the three-step risk control hierarchy defined in EN ISO 14971:2019+A11:2021 clause 7.1.
  • The principle is simple: remove the hazard instead of mitigating it. Choose a non-hazardous voltage instead of adding an enclosure around a hazardous one. Choose a biocompatible material instead of coating a problematic one.
  • MDR Annex I §2 and §4 require manufacturers to apply safety principles to the design and manufacture of the device, considering the generally acknowledged state of the art.
  • Inherent safety only works if risk management starts during concept design, not after design freeze. Post-hoc risk files cannot deliver tier 1 controls.
  • The audit test for a tier 1 claim is simple: the reviewer asks what would happen if the tier 2 or tier 3 control were removed. If the answer is "nothing, the hazard is no longer present", the control is genuinely inherent.

Why tier 1 matters more than everything else (Hook)

Felix remembers a conversation with a hardware founder who was six weeks away from a notified body stage 1 audit. The risk file had been put together in a rush by an intern using a template from a consultancy that specialised in export paperwork. Every risk control in the file was a warning in the instructions for use. The founder wanted to know how to "upgrade" the controls to pass the audit.

The honest answer was that you cannot upgrade tier 3 warnings into tier 1 controls. Tier 1 is a design decision, not a documentation decision. If the design is frozen, the tier 1 option has already closed. You can add interlocks (tier 2), you can rewrite the IFU (tier 3), but you cannot retroactively engineer a hazard out of a device that has already been built to contain it.

That conversation is the reason this post exists. Inherent safety is not a section of the risk file. It is a stance you take during concept design. The teams that do it well never have to scramble. The teams that skip it spend the last month before the audit writing rejection paragraphs for tier 1 options they never seriously considered.

What "inherent safety" actually means (Surface)

EN ISO 14971:2019+A11:2021 clause 7.1 lists inherent safety by design and manufacture as the first of three risk control options. The standard's intent is explicit: the preferred way to reduce risk is to eliminate the hazard or to reduce its probability of occurrence by making a different design choice. Not by adding a safeguard on top of the design. By changing the design.

MDR Annex I §2 requires that manufacturers apply the generally acknowledged state of the art to their design and manufacturing solutions. This matters for tier 1 because "generally acknowledged state of the art" is a moving target. A component choice that was defensible five years ago may now be below state of the art because a safer alternative has become widely available. Inherent safety is benchmarked against what is possible today, not what was possible when the project started.

MDR Annex I §4 then requires that risks be reduced as far as possible without adverse impact on the benefit-risk ratio. The "as far as possible" language is stronger than the ALARP framing that ISO 14971 alone would permit. Tier 1 controls are often the only way to meet the MDR bar, because tier 2 and tier 3 controls always leave the hazard in place and manage around it.

What tier 1 looks like in practice

In Tibor's Q8 follow-up interview, the canonical example was electrical. If a dangerous voltage is not needed for the intended function, do not use it. The device operates at a lower voltage. The shock hazard is gone. There is no enclosure to inspect, no warning to read, no interlock to validate. The hazard is simply not present in the device.

Other examples Tibor has seen in audit work:

  • Choosing a single-use consumable over a reusable one to eliminate the cross-contamination hazard that would otherwise require validated reprocessing (tier 2/3 controls).
  • Selecting a material from the outset that has an established biological evaluation under EN ISO 10993-1:2025, rather than coating a cheaper material and then managing the leachables risk.
  • Moving patient data processing off the device so the device never stores identifiable data, eliminating an entire category of cybersecurity and GDPR hazards.
  • Using a mechanical stop at the end of an actuator's travel so the software cannot drive the actuator past its safe range, regardless of software faults.
  • Choosing a wavelength of light source that cannot damage the retina at any intensity the device can produce, so the ocular safety analysis becomes trivial.

Each of these is a design input decision. None of them is a mitigation. Each of them makes the hazard structurally impossible rather than conditionally unlikely.

What tier 1 is not

Tier 1 is not a low-probability tier 2 control. A fuse that blows at 2 amps is a protective measure, not inherent safety. The hazardous current still exists inside the device. The fuse manages it.

Tier 1 is not a good warning. A very clearly worded IFU is still tier 3. The user can still misread it, skip it, or never see it.

Tier 1 is not "we tested it and nothing happened". Absence of observed harm in a small verification sample is not elimination of the hazard.

The audit test is the one Tibor uses in review. For any control claimed as tier 1, remove every other control mentally and ask: is the hazard still present? If yes, the control is not inherent. If no, it is.

A worked example (Test)

A respiratory monitoring startup designed a pulse oximeter probe for home use. Early prototypes used a red LED at a wavelength and intensity that, under single-fault conditions, could theoretically exceed the photobiological safety limit for prolonged skin exposure.

The first risk file draft, written after the hardware was already prototyped, controlled the hazard with three entries. A tier 2 software timer limited continuous measurement to five minutes. A tier 2 current-limiting resistor bounded the maximum LED drive current. A tier 3 IFU warning told users not to fix the probe to the same finger for extended periods. All three controls were real, but all three left the hazard in place.

Tibor's review comment on the early draft was straightforward: the team had never asked the tier 1 question. The tier 1 question was whether the red LED had to be this specific LED at this specific intensity, or whether a different LED at a lower intensity would still deliver adequate SpO2 accuracy.

The team ran a feasibility study over two weeks. A next-generation LED with higher optical efficiency produced the same signal-to-noise ratio at roughly 55% of the drive current. At the lower current, the photobiological analysis showed no plausible fault condition under which the exposure limit could be reached, even with continuous measurement over hours. The tier 1 change eliminated the hazard. The tier 2 software timer and current-limiting resistor remained in the design as belt-and-braces backups, but they were no longer the primary control. The tier 3 IFU warning was removed because there was nothing specific to warn about.

The risk file now recorded the tier 1 change as the primary control, with the reasoning chain documented: the original LED was rejected because a state-of-the-art alternative was available that eliminated the hazard at a modest BOM cost increase. The audit trail was clean. The design input was revised. The verification plan picked up the new LED specification.

Total time cost: roughly three weeks of engineering, including the re-run of the electrical and optical verification tests. Net effect on certification readiness: the hardest hazard in the file became the easiest.

The Subtract to Ship playbook (Ship)

The Subtract to Ship move that delivers tier 1 controls is deceptively simple: ask what would have to be true for the hazard to not exist, and then see if that condition can be met by a design choice you have not yet locked.

Step 1. Run a hazard workshop before the bill of materials is frozen. EN ISO 14971:2019+A11:2021 calls for risk management throughout the lifecycle, but the lifecycle stage where tier 1 is still available is concept design. If you are past that stage, the tier 1 window is closing on every component you lock.

Step 2. For every hazard, ask the elimination question first. "What would have to be different about the device for this hazard to not be present at all?" Write the answer down even if it sounds impractical. Impracticality is a rejection reason, and rejection reasons belong in the risk file. Refusal to ask the question is not a rejection reason.

Step 3. Benchmark against state of the art. MDR Annex I §2 ties inherent safety to generally acknowledged state of the art. The component catalogue from three years ago is not a valid benchmark. Check whether a newer component, a newer material, or a newer architecture has made the tier 1 option feasible where it was not feasible before.

Step 4. Protect the tier 1 decision in design inputs. Once a tier 1 control is adopted, it needs to live in the design input documents, not just the risk file. Otherwise a later engineering change can silently undo the control and nobody will notice until the post-market signal shows up.

Step 5. Keep tier 1 on the review agenda during design changes. Every engineering change order should ask whether the change reintroduces a hazard that a tier 1 control had eliminated. This is where risk files quietly decay: a cost-reduction programme swaps a component, and the inherent safety claim based on the original component is no longer valid, but the risk file still says tier 1.

Step 6. Document the tier 1 rejection reasons for hazards where elimination was not possible. Not every hazard can be eliminated. For those that cannot, the rejection must be explicit and technical. "Not feasible due to intended use constraints" is a defensible phrase if it is backed by specifics. "Not considered" is not.

Reality Check

  1. For your highest-severity hazards, was a tier 1 option ever seriously considered? If the risk file shows no tier 1 discussion, the hierarchy was not applied.
  2. When was the risk file first created in relation to design freeze? If after freeze, tier 1 options are structurally limited.
  3. Pick one of your tier 3 IFU warnings. Could a design change have eliminated the need for it? If yes, and the change is still feasible, you have a Subtract to Ship opportunity.
  4. Is your state-of-the-art benchmark up to date? When was the last time you checked whether newer components, materials or architectures made a previously rejected tier 1 option viable?
  5. Does every design change order in your QMS trigger a risk management review? If not, tier 1 controls will decay over time without anyone noticing.
  6. Can you name one hazard in your current device that is present at all, or one that has been genuinely eliminated? If the list of "eliminated" hazards is empty, the hierarchy is probably being skipped.

Frequently Asked Questions

What is the difference between inherent safety by design and protective measures? Inherent safety removes the hazard from the device. Protective measures leave the hazard in place but prevent it from causing harm. A lower voltage is inherent safety. An insulated enclosure around a dangerous voltage is a protective measure.

Can software changes deliver inherent safety? Usually no. Software can implement tier 2 protective measures (interlocks, limits, fail-safes), but software cannot remove a hardware hazard. A software limit on motor current does not eliminate the thermal hazard of the motor itself. It manages it.

Does inherent safety cost more? Sometimes yes, sometimes no. A newer component may be more expensive but eliminate a hazard that would otherwise require expensive verification, validation and post-market monitoring. The total lifetime cost of a tier 1 control is often lower than the total lifetime cost of the tier 2 and tier 3 controls it replaces.

How do notified bodies verify a tier 1 claim? They look at the design input, the risk file rationale, the verification record, and the design change history. The question they answer is whether the hazard is genuinely absent from the device or merely managed by something in the control column.

Can a legacy device add tier 1 controls after initial CE marking? It can, but any change significant enough to eliminate a previously-controlled hazard is a significant change under MDR Article 120 and requires notified body engagement. Retrofitting tier 1 is possible, not free.

What if the tier 1 option conflicts with the intended use? Then the rejection reason is recorded in the risk file and the team moves to tier 2. What is not permitted is skipping the tier 1 question because the team assumed it would conflict.

Sources

  1. Regulation (EU) 2017/745 on medical devices, consolidated text. Annex I §2, §4, §10, §14.
  2. EN ISO 14971:2019+A11:2021, Medical devices, Application of risk management to medical devices, clause 7.1 (risk control options).
  3. EN ISO 10993-1:2025, Biological evaluation of medical devices, Part 1 (material selection reference).