---
title: Protective Measures as Risk Controls: Guards, Alarms, and Interlocks
description: Protective measures medical device risk controls: guards, alarms, interlocks, fail-safes. Tier 2 of ISO 14971 clause 7 and when NBs accept them vs require tier 1.
authors: Tibor Zechmeister, Felix Lenhard
category: Post-Market Surveillance & Vigilance
primary_keyword: protective measures medical device risk control
canonical_url: https://zechmeister-solutions.com/en/blog/protective-measures-guards-alarms-interlocks
source: zechmeister-solutions.com
license: All rights reserved. Content may be cited with attribution and a link to the canonical URL.
---

# Protective Measures as Risk Controls: Guards, Alarms, and Interlocks

*By Tibor Zechmeister (EU MDR Expert, Notified Body Lead Auditor) and Felix Lenhard.*

> **Protective measures are the second tier of the EN ISO 14971:2019+A11:2021 clause 7.1 risk control hierarchy. Guards, alarms, interlocks and automatic shutdowns leave the hazard in place but prevent it from causing harm. Notified body auditors accept protective measures when tier 1 inherent safety is genuinely not feasible, and reject them when they mask a tier 1 option the team never explored.**

**By Tibor Zechmeister and Felix Lenhard.**

## TL;DR
- Protective measures are tier 2 of the ISO 14971 clause 7.1 hierarchy: device-side or process-side controls that prevent a hazard from causing harm without eliminating the hazard itself.
- Typical examples: guards, interlocks, alarms, automatic shutdowns, fail-safe defaults, current limiters, and pressure-relief systems.
- MDR Annex I §4 permits tier 2 controls when tier 1 inherent safety is not feasible, but the risk file must document why tier 1 was rejected.
- The canonical example from Tibor's audit experience: a motor that automatically shuts down on overheat detection. The thermal hazard is still present, but the control catches it before it reaches the patient.
- A tier 2 control must be testable in verification. If the team cannot define a test case that exercises the control and confirms it activates, the control is not adequate evidence.
- Reliance on alarms and warnings that require user response is weaker than interlocks that act without user intervention. NBs treat them differently.

## Why tier 2 matters (Hook)

Not every hazard can be eliminated. A surgical laser needs a laser. An infusion pump needs a fluid path that can, under fault conditions, deliver too much. An X-ray system needs ionising radiation. For these devices, tier 1 inherent safety is genuinely limited, and tier 2 protective measures become the primary risk control.

In Tibor's audit experience, the two failure modes around tier 2 are equally common. The first is over-reliance on tier 2 where a tier 1 option existed but was never considered. The second is under-specification of tier 2 controls that are claimed but not engineered: an interlock that is named in the risk file but has no test case, no verification record, and no evidence that it actually does what the file says it does.

Felix has coached founders through both failures. The fix for the first is to re-run the tier 1 question before accepting a tier 2 control. The fix for the second is to treat every tier 2 control as a design requirement with a verification test case attached, not as a sentence in a risk table.

## What tier 2 protective measures are (Surface)

**EN ISO 14971:2019+A11:2021 clause 7.1** defines the second risk control option as "protective measures in the medical device itself or in the manufacturing process". The standard's intent is that the device, or the process that produces it, prevents harm without requiring the user to notice anything or take any action.

**MDR Annex I §4** is the legal basis. Once tier 1 has been exhausted, manufacturers must still reduce residual risk as far as possible, and tier 2 is the mechanism.

### Categories of tier 2 controls

Tibor's audit taxonomy for tier 2 controls maps onto five broad categories.

**Interlocks.** An interlock prevents an unsafe state from being reached. A surgical laser that will not fire unless the access door is closed. An infusion pump that will not start a delivery unless the upstream occlusion sensor confirms a valid fluid path. An imaging scanner that will not expose a patient unless the bed position is within the safe range. Interlocks are the strongest tier 2 controls because they act automatically and do not rely on user perception.

**Automatic emergency shutdowns.** This is Tibor's Q8 canonical example: a motor that automatically shuts down when an overheat sensor crosses a threshold. The fault condition still exists inside the device, but it cannot propagate to the patient because the device removes itself from the scenario. Similar examples: a heating element that cuts power on thermal runaway, a pressure vessel that opens a relief valve above a set point, a software fault handler that puts the device into a safe state on unhandled exception.

**Guards and physical barriers.** A guard prevents mechanical contact with a hazard. Finger guards on moving parts, sharps shields on injection devices, optical filters that block non-therapeutic wavelengths from reaching the patient. Guards are passive: they work without power, software, or user action.

**Alarms and alerts.** An alarm tells the user something has gone wrong. Alarms are weaker than interlocks because they rely on the user to notice, interpret, and act. EN 60601-1:2006+A1+A12+A2+A13:2024 and its collateral standards treat alarms as regulated safety functions with specific requirements for audibility, prioritisation and latency. When an alarm is claimed as tier 2, the risk file must reference the alarm standard compliance evidence.

**Fail-safe defaults.** If the device enters an unknown or fault state, it defaults to a state that cannot cause harm. A ventilator that drops to bag-mask-equivalent on controller failure. Software that, on unhandled exception, halts rather than continues. Fail-safe defaults convert "unknown state" into "known safe state".

### When tier 2 is the right tier

Tier 2 is the right tier when the hazard cannot be engineered out of the device. If the device must use a hazardous voltage to achieve its intended function, tier 1 elimination is impossible. Tier 2 controls, correctly engineered and verified, can reduce the risk of that voltage reaching the patient to an acceptable residual level. MDR Annex I §14 covers electrical safety specifically and expects tier 2 controls on electrical hazards that cannot be avoided.

Tier 2 is also the right tier when the hazard comes from software faults. Tier 1 in software is limited, because software behaviour is largely determined after design freeze. Tier 2 software controls, structured per EN 62304:2006+A1:2015, include watchdog timers, range checks on inputs, bounded output, safe-state exception handlers and redundant computation for safety-critical calculations.

### When the auditor pushes back

The pushback pattern Tibor sees most often is: the risk file claims a tier 2 control, but the control is actually an alarm that depends on user response, and the summative usability evaluation under EN 62366-1:2015+A1:2020 shows users frequently dismiss the alarm without understanding it. That is a tier 2 control on paper but a tier 3 control in practice, and the residual risk is higher than the risk file claims.

The other pushback pattern is: the tier 1 rejection reason is "not feasible", but the feasibility claim is not supported by any technical analysis. When this happens, the NB will ask for the analysis. If it does not exist, the team will need to generate it during the audit or accept a nonconformity.

## A worked example (Test)

Consider an electromechanical physiotherapy device that applies controlled compression to a limb. Under fault conditions, the compression cuff could over-pressurise and cause tissue ischemia.

**Tier 1 question.** Can the hazard be eliminated? The team asks whether a mechanical pressure-limiting design could make over-pressurisation physically impossible. The answer is partial: a mechanical relief valve set at the upper therapeutic range caps the peak pressure regardless of software or controller behaviour. The team adopts it. The tier 1 control is not a full elimination because the therapeutic pressure and the harm pressure overlap, but the extreme over-pressurisation case is physically bounded.

**Tier 2 layer.** The remaining residual risk is that a pressure in the upper therapeutic range, applied for too long, can still cause ischemia. The team adds three tier 2 controls.

First, an automatic shutoff interlock: a pressure sensor monitors cuff pressure on a 10 ms cycle, and if pressure exceeds the therapeutic ceiling for more than 500 ms, the pump is stopped and the cuff is vented. This is an interlock. It does not require user action. It has a test case in verification: inject an over-pressure condition, confirm the system vents within the specified latency, document the evidence.

Second, a treatment time interlock: the device will not run a compression cycle longer than the maximum therapeutic duration in the IFU, regardless of what the user selects. This is a fail-safe default. Test case: attempt to set a longer duration, confirm the device refuses.

Third, an alarm: if the pressure sensor becomes inconsistent (failure mode), the device raises a high-priority alarm and enters a safe state. This is an alarm plus a fail-safe default. Test case: simulate sensor failure, confirm the alarm activates at the required audibility and the device enters safe state.

**Tier 3 residual.** The IFU states that the user should observe the patient for signs of discomfort and stop the session if discomfort is reported. This is a tier 3 control and is explicitly residual to the three tier 2 controls above. The risk file does not rely on it as the primary control.

When the notified body reviews this file, they see a tier 1 mechanical limit, three engineered tier 2 controls with verification evidence, and a tier 3 IFU note as backup. The tier hierarchy has been applied. The residual risk claim is defensible.

Contrast with the first-draft version of the same risk file: a single entry reading "user will stop the session if the patient reports discomfort". Same hazard, same device, dramatically different audit outcome.

## The Subtract to Ship playbook (Ship)

Felix's playbook for tier 2 in startup risk files has five steps.

**Step 1. Always re-run tier 1 before accepting a tier 2 control.** The tier 1 rejection needs to be on paper. If the rejection reason is "not considered", the team has not done the work. Go back to the tier 1 question.

**Step 2. Specify tier 2 controls as design requirements, not risk-file sentences.** An interlock that lives only in the risk file will not get verified. An interlock that lives in the design input document will get a test case, a verification record, and an engineering owner. The risk file entry and the design input must cross-reference each other.

**Step 3. Prefer interlocks over alarms.** Interlocks act automatically. Alarms rely on user response. An interlock-based tier 2 control is structurally stronger and audits better. When an alarm is unavoidable, the alarm must comply with the relevant collateral standard under EN 60601-1 and the compliance evidence must be in the file.

**Step 4. Build verification test cases for every tier 2 control.** The rule: if you cannot write the test case, the control is not real. A credible test case specifies the fault condition to be injected, the expected control response, the measurable acceptance criterion, and the verification record identifier.

**Step 5. Include tier 2 controls in the post-market surveillance plan.** Tier 2 controls can degrade over time. A sensor drifts. A firmware update weakens an interlock. A calibration cycle is missed. The PMS plan under MDR Article 83-86 should include specific signals that would indicate a tier 2 control is no longer performing as designed.

## Reality Check

1. For each tier 2 control in your risk file, is there a corresponding design input requirement? If the control lives only in the risk file, it is probably not engineered.
2. For each tier 2 control, is there a verification test case with a specific fault injection? If not, the control is not verified.
3. How many of your tier 2 controls are alarms that require user response, and how many are interlocks that act automatically? A ratio skewed toward alarms is a red flag for NB review.
4. Have you documented a tier 1 rejection reason for every hazard where tier 2 is claimed as the primary control? "Not feasible" without technical backing is not a rejection reason.
5. Does your PMS plan include signals for tier 2 control degradation? A control that silently fails is worse than no control at all.
6. When was the last time the risk file was updated in response to a design change that affected a tier 2 control? Design changes quietly invalidate tier 2 controls more often than teams realise.

## Frequently Asked Questions

**When does a notified body accept a tier 2 control instead of demanding a tier 1 redesign?**
When the risk file documents a credible technical reason why tier 1 is not feasible, the tier 2 control is engineered into the device with verification evidence, and the residual risk after the tier 2 control is acceptable under the MDR "as far as possible" standard. All three conditions have to be met.

**Is an alarm a valid tier 2 control?**
An alarm is a valid tier 2 control if it meets the applicable alarm standard under EN 60601-1, if the summative usability evaluation shows users can perceive and respond to it, and if the risk file treats it as weaker than an interlock. Alarms alone are rarely enough for high-severity hazards.

**What is the difference between an interlock and a fail-safe default?**
An interlock prevents an unsafe action from being taken in the first place. A fail-safe default converts an unknown or error state into a known safe state. Both are tier 2, and both are stronger than alarms.

**How does tier 2 interact with IEC 62304 software safety classification?**
Software tier 2 controls are software items that implement risk control. Their software safety class under EN 62304:2006+A1:2015 is determined by the severity of the hazard they control. A class C software item controlling a potentially life-threatening hazard needs the full rigour of the class C lifecycle.

**Can the same tier 2 control cover multiple hazards?**
Yes. A well-engineered interlock or fail-safe default often controls several related hazards. The risk file should cross-reference each hazard to the control, not duplicate the control entry.

**What is the most common tier 2 audit finding?**
Tibor's most common finding is a tier 2 control claimed in the risk file with no corresponding verification test case. The control is named, but there is no evidence it has ever been tested under the fault condition it is supposed to catch.

## Related reading
- [The three-step risk control approach](/blog/mdr-risk-control-three-step-iso-14971) is the anchor post on the full ISO 14971 clause 7 hierarchy.
- [Inherent safety by design](/blog/inherent-safety-by-design) explains why tier 1 must always be considered before accepting a tier 2 control.
- [Mechanical safety under EN 60601-1](/blog/mechanical-safety-iec-60601-1-mdr) covers guards and mechanical protective measures in detail.
- [Electrical hazard protection under EN 60601-1](/blog/electrical-hazard-protection-iec-60601-1) covers electrical interlocks and current-limiting as tier 2 controls.
- [Software safety classification under IEC 62304](/blog/software-safety-classification-iec-62304) explains how software tier 2 controls inherit the safety class of the hazard they mitigate.

## Sources
1. Regulation (EU) 2017/745 on medical devices, consolidated text. Annex I §4, §14, §17, §22.
2. EN ISO 14971:2019+A11:2021, Medical devices, Application of risk management to medical devices, clause 7.1 (risk control options).
3. EN 60601-1:2006+A1+A12+A2+A13:2024, Medical electrical equipment, Part 1: General requirements for basic safety and essential performance.
4. EN 62304:2006+A1:2015, Medical device software, Software life cycle processes.

---

*This post is part of the [Post-Market Surveillance & Vigilance](https://zechmeister-solutions.com/en/blog/category/pms-vigilance) cluster in the [Subtract to Ship: MDR Blog](https://zechmeister-solutions.com/en/blog). For EU MDR certification consulting, see [zechmeister-solutions.com](https://zechmeister-solutions.com).*