On this page
Key Takeaways
- IEC 60601 contains no cybersecurity requirements; a 60601 test report is not cybersecurity evidence for the FDA.
- IEC 60601-1-2 covers electromagnetic immunity, not attack resilience. EMC testing does not substitute for penetration testing or fuzzing.
- 60601-1 essential performance and basic safety are the correct source for harm severity in a SW96 security risk analysis.
- 60601-1-8 alarm requirements constrain security design: a control that can suppress or delay an alarm creates a safety hazard.
- The binding cybersecurity obligations for a cyber device come from FD&C Act Section 524B and the February 3, 2026 final premarket guidance.
IEC 60601 is the international family of standards for basic safety and essential performance of medical electrical equipment. It contains no cybersecurity requirements. Conformity to IEC 60601-1 or the 60601-1-2 electromagnetic compatibility collateral does not address, and will not satisfy, the cybersecurity expectations in FDA Section 524B or the February 3, 2026 final premarket cybersecurity guidance. The real connection runs the other direction: the essential performance and basic safety characteristics you define under 60601-1 are the inputs you use to score patient-harm severity in a security risk analysis performed to ANSI/AAMI SW96:2023.
This confusion is common and understandable. IEC 60601 is often the most familiar standard in an electrical or systems engineering group, it is the standard the test lab talks about, and 60601-1-2 does deal with a device being disturbed by something outside itself. From a distance that looks adjacent to security. It is not, and treating a 60601 report as part of a cybersecurity package is a reliable way to draw a deficiency.
Why this matters
Section 524B of the FD&C Act requires a manufacturer of a cyber device to submit a cybersecurity plan, a software bill of materials, evidence of reasonable assurance that the device and related systems are cybersecure, and processes for postmarket monitoring and patching. None of those four obligations is discharged by a 60601 report, and the FDA reviewer assessing the cybersecurity section of your submission is not the reviewer looking at electrical safety.
The practical cost of the confusion is schedule. Teams that assume 60601 covers "the safety testing" discover late that the cybersecurity artifacts, threat model, security risk analysis, penetration test report, SBOM, and postmarket plan, were never scoped or budgeted. That discovery usually happens after the design freeze, when the architectural changes a threat model would have surfaced are the most expensive to make.
What each part of IEC 60601 actually covers
| Standard | Scope | Cybersecurity content |
|---|---|---|
| IEC 60601-1 | General requirements for basic safety and essential performance | None. Establishes essential performance and hazardous-situation concepts |
| IEC 60601-1-2 | Electromagnetic disturbances (EMC/EMI immunity and emissions) | None. Unintentional interference only, not adversarial input |
| IEC 60601-1-6 | Usability engineering (applies IEC 62366-1) | None directly. Relevant to authentication and alarm usability trade-offs |
| IEC 60601-1-8 | Alarm systems | None. Constrains security design because alarms must not be suppressed |
| IEC 60601-1-10 | Physiologic closed-loop controllers | None. Raises harm severity for integrity attacks on control loops |
| IEC 60601-1-11 | Home healthcare environment | None. Changes the threat environment assumptions you should document |
| IEC 60601-1-12 | Emergency medical services environment | None. Same, for EMS use |
| IEC 60601-2-xx | Particular standards per device type (infusion, ECG, ventilators, and others) | None. Defines device-specific essential performance you inherit as harm criteria |
No part of the IEC 60601 family imposes a cybersecurity control, a threat modeling obligation, an SBOM obligation, or a vulnerability management obligation. If a program plan lists 60601 conformity as cybersecurity evidence, that is a gap, not a control.
EMC immunity is not attack resilience
IEC 60601-1-2 is the sub-part most often mistaken for a security standard, because it tests how the device behaves when something external disturbs it. The difference is intent and reachability.
| Dimension | 60601-1-2 EMC immunity | Cybersecurity resilience testing |
|---|---|---|
| Source of disturbance | Unintentional, environmental | Intentional, adversarial |
| Model of the source | Statistical field strengths and waveforms | A capable attacker with goals and persistence |
| Interfaces exercised | Radiated and conducted physical paths | Network, wireless protocol, USB, serial, API, update channel, physical debug |
| Test method | Standardized immunity levels in a chamber | Threat-model-driven penetration testing, fuzzing, protocol abuse |
| Pass criterion | Essential performance maintained at defined levels | No exploitable path to loss of confidentiality, integrity, availability, or safety |
| Adapts over time | No, fixed test levels | Yes, as the vulnerability and threat landscape changes |
An RF immunity pass tells you nothing about whether an unauthenticated Bluetooth pairing flow lets an attacker change a therapy setting. Those are separate failure modes with separate evidence.
The one real link: essential performance to harm severity
This is where 60601 genuinely belongs in a cybersecurity program, and it is the part most teams skip.
ANSI/AAMI SW96:2023 requires security risk management that expresses risk in terms of patient harm, not just information-security impact. ISO 14971 supplies the harm framework. The problem for most security teams is that they have no principled source for what constitutes harm on this specific device. IEC 60601-1 and its particular 60601-2-xx standards already answer that: they define the device's essential performance, the clinical function whose loss or degradation creates unacceptable risk, and the basic safety characteristics that must hold.
So the mapping runs like this:
- Take the essential performance statement and basic safety characteristics established under 60601-1 and the applicable 60601-2-xx particular standard.
- For each, ask what a loss of confidentiality, integrity, or availability would do to it. This is the CIA-to-harm bridge that pure information-security frameworks like ISO 27001 do not provide.
- Use the resulting clinical consequence to assign a severity level on your ISO 14971 severity scale, so the security risk analysis and the safety risk analysis use one scale, not two.
- Feed that severity into SW96 security risk scoring, where exploitability replaces probability of occurrence, since a deliberate attack is not a random failure.
- Carry the same harm statements into your threat model, so STRIDE findings terminate in a clinical consequence rather than a generic "loss of integrity."
Worked example: an infusion pump
| Essential performance (from 60601-2-24) | Security property lost | Attack that causes it | Clinical harm | ISO 14971 severity |
|---|---|---|---|---|
| Delivery accuracy within stated tolerance | Integrity | Unauthenticated drug library or rate write over the network | Over-infusion or under-infusion of a high-alert medication | Critical |
| Continued delivery without unintended interruption | Availability | Ransomware or resource exhaustion on the pump controller | Therapy interruption, deterioration during infusion | Serious |
| Alarm annunciation on occlusion or air-in-line (with 60601-1-8) | Integrity, availability | Alarm suppression or log flooding that delays annunciation | Undetected occlusion or air embolism | Critical |
| Correct association of pump to patient and order | Integrity | Spoofed EHR or interoperability message | Wrong drug or dose to the wrong patient | Critical |
| Protection of stored patient and therapy data | Confidentiality | Unencrypted storage or debug interface read | Privacy harm, limited direct physical harm | Minor to serious |
Notice the last row. It is the only one where a classic information-security lens gets the severity roughly right. Every other row is severe because of a 60601-derived clinical function, not because of the data involved. That is precisely why an ISO 27001 or NIST-only security program tends to under-rate medical device risk, and why reviewers push back on security risk analyses whose severity column reads like an IT risk register.
Where 60601 sub-parts constrain security design
The relationship also runs in the opposite direction. Several 60601 requirements limit what your security controls are allowed to do.
- 60601-1-8 alarms. A security control cannot suppress, delay, or mask an alarm. Rate limiting, lockout after failed authentication, or a security event flood that starves the alarm subsystem all create a safety hazard. Any lockout design needs an explicit analysis showing alarm annunciation is preserved.
- 60601-1-6 usability. Authentication at the point of care has to survive gloved hands, urgency, and shared clinical workstations. A password policy that makes clinicians share credentials has degraded both usability and security. Emergency access, sometimes called break-glass, must be designed, logged, and justified rather than left as an undocumented bypass.
- 60601-1-10 closed-loop control. When the device closes a physiologic control loop, an integrity attack on a sensor input or a control parameter is a direct patient-harm path. Severity assignments for those parameters should be at the top of your scale by default.
- 60601-1-11 and -1-12 environments. Home and EMS use change your threat model assumptions. You cannot assume a managed hospital network, physical access control, or timely patching. Document the environment assumption explicitly, because a threat model that silently assumes a hospital VLAN will not hold for a home-use device.
- Single fault condition thinking. 60601-1 reasons about safety under a single fault. Security does not get that luxury; an attacker chains faults deliberately. Do not let a "single fault condition is handled" argument stand in for a security control.
The exception: IEC TR 60601-4-5
There is one document in the 60601 numbering space that does address security, and it is worth knowing about precisely so you can explain why it does not change the answer above. IEC TR 60601-4-5 is a technical report on safety-related technical security specifications for medical electrical equipment. It maps security capability and security level concepts drawn from the IEC 62443 industrial family onto medical electrical equipment, and it discusses how a security failure can degrade essential performance.
Three things to keep straight:
| Point | Detail |
|---|---|
| It is a technical report, not a standard | A TR is informative. It states no conformity requirements and produces no pass or fail test report |
| It is not an FDA recognized consensus standard for cybersecurity | Declaring conformity to it does not satisfy any part of Section 524B, and reviewers will still expect SW96, 81001-5-1, and 62304 evidence |
| Its useful contribution is vocabulary | The security level and security capability framing helps engineering teams reason about how much protection a given interface needs, and it reinforces the essential-performance-to-harm link this guide describes |
Use it as background reading for an engineering group that already lives inside the 60601 world and needs a bridge into security thinking. Do not cite it in a submission as your security risk management method. That role belongs to ANSI/AAMI SW96:2023.
The standards that actually carry the cybersecurity requirements
| Instrument | Status | What it obligates |
|---|---|---|
| FD&C Act Section 524B | Binding US law | Cybersecurity plan, SBOM, reasonable assurance of security, postmarket monitoring and patching for cyber devices |
| FDA final premarket cybersecurity guidance (February 3, 2026) | Nonbinding, but how reviewers measure you | Secure Product Development Framework, threat model, security risk analysis, testing evidence, labeling, submission documentation |
| ANSI/AAMI SW96:2023 | Recognized consensus standard | Security risk management across the device lifecycle, expressed in patient-harm terms |
| IEC 81001-5-1 | Recognized consensus standard | Security activities inside the health software lifecycle |
| IEC 62304 | Recognized consensus standard | Software lifecycle processes that security activities attach to |
| ISO 14971 | Recognized consensus standard | Risk management framework and severity scale that security risk feeds into |
| AAMI TIR57 | Technical information report | Earlier security risk management guidance, largely superseded by SW96 for new work |
| IEC 60601 family | Recognized consensus standards | Electrical safety, EMC, alarms, usability, essential performance. No cybersecurity requirements |
| IEC TR 60601-4-5 | Technical report, informative | Security level and capability vocabulary for medical electrical equipment. No conformity requirements, not submission evidence |
If you want the full picture of how these fit together, see the MedTech cybersecurity standards decoder and the FDA cybersecurity guidance pillar. To see which of them apply to your specific device, the standards mapper takes a device type and use case and returns the applicable chain with the deliverables each standard requires.
What to tell your team when the question comes up
A short version that holds up in a design review:
IEC 60601 tells us the device will not shock, burn, overheat, or fail its essential performance under normal use, fault conditions, and electromagnetic disturbance. It says nothing about an adversary. Cybersecurity comes from Section 524B and the February 2026 guidance, implemented through SW96, 81001-5-1, and 62304. The one place they meet is harm definition: we reuse the essential performance from 60601 to decide how bad a security failure would be for the patient.
How Blue Goat approaches this
We start a security risk analysis by pulling the device's essential performance and basic safety statements straight out of the 60601-1 and 60601-2-xx work your engineering team has already done, rather than inventing a parallel harm taxonomy. That gives one severity scale shared by the safety file and the security file, which is what reviewers expect to see and what avoids the contradiction of a hazard rated critical in ISO 14971 and moderate in the security risk analysis. From there we build the threat model, run testing against the interfaces the model identifies, and check the resulting controls back against 60601-1-8 and 60601-1-6 so that a security mechanism does not introduce a safety or usability hazard. Where a client arrives believing 60601 conformity covered cybersecurity, the first deliverable is usually a gap map showing exactly which Section 524B obligations have no evidence behind them yet.
FAQ
CTA
If your program lists 60601 conformity where cybersecurity evidence should be, we can map your Section 524B obligations against what you actually have and show you the gaps before a reviewer does. Talk to a MedTech cybersecurity expert.
