On this page
Published:
Key Takeaways
- IEC 62443 is an industrial automation security series; medical device teams mostly use part 4-1 for development practices and part 4-2 for component technical requirements.
- Part 4-1 organizes secure development into eight practices; part 4-2 organizes technical requirements under seven foundational requirements.
- Security levels in part 4-2 describe capability against attacker types, not a regulatory pass mark.
- IEC 81001-5-1 is the health software lifecycle standard; IEC 62443 evidence can support it but is not a substitute for device risk and harm analysis.
- Check the FDA recognized consensus standards database for the current recognition status of each part before citing it.
What evidence does IEC 62443 call for on a medical device?
For a medical device, IEC 62443 evidence usually comes from two parts. IEC 62443-4-1 asks for proof of a secure development process across eight practices, and IEC 62443-4-2 asks for proof that a component meets technical requirements under seven foundational requirements. Use the tables below to connect each area to controlled records, an owner, and the question a reviewer will ask. Pair it with the IEC 81001-5-1 evidence table, which is the health software lifecycle standard.
This page is an evidence planning aid, not a clause-by-clause conformity checklist. Clause wording, requirement enhancements, and security level details are in the purchased standards.
What this table does and does not establish
- It shows the kinds of records that typically demonstrate each area.
- It does not claim conformity, certification, or FDA acceptance.
- It does not replace security risk assessment under ANSI/AAMI SW96 or the link to harm under ISO 14971.
- The manufacturer decides which parts apply, owns the records, and approves risk decisions.
Which IEC 62443 parts matter for devices
| Part | Scope | Typical device use |
|---|---|---|
| 62443-4-1 | Secure product development lifecycle requirements for product suppliers | Development process evidence, often alongside IEC 81001-5-1 |
| 62443-4-2 | Technical security requirements for components (embedded devices, host devices, network devices, and software applications) | Component capability evidence, such as authentication, logging, and integrity controls |
| 62443-3-3 | System security requirements and security levels | Systems made of several components, such as a device plus gateway and hospital integration |
| 62443-3-2 | Security risk assessment for system design, including zones and conduits | Segmenting a multi-component system and assigning target security levels |
| 62443-2-4 | Security program requirements for service providers | Integrators or service organizations supporting deployed systems |
IEC 62443-4-1 practice to evidence table
| Practice | Example controlled evidence | Owner and review question |
|---|---|---|
| 1. Security management (SM) | Security development plan, roles, competency records, process scope, and third-party component controls | Engineering / QA: Is the process defined, staffed, and applied to this product? |
| 2. Specification of security requirements (SR) | Product security context, threat model, security requirements, and requirement reviews | Product security: Are requirements derived from the intended environment and threats? |
| 3. Secure by design (SD) | Architecture, trust boundaries, defense in depth rationale, and design reviews | System engineering: Does the design show where each control sits and why? |
| 4. Secure implementation (SI) | Secure coding standard, code review records, static analysis results, and dependency inventory | Software engineering: Are coding rules applied and exceptions recorded? |
| 5. Security testing (SVV) | Requirement tests, threat mitigation tests, vulnerability scanning, fuzzing where relevant, penetration testing, and tester independence records | Product security: Does test evidence cover the released build and its limitations? |
| 6. Management of security-related issues (DM) | Intake process, triage records, severity assessment, disposition, and closure evidence | PSIRT: Can every reported issue be traced from receipt to closure? |
| 7. Security update management (SUM) | Update qualification, delivery integrity, timeliness commitments, and customer notification records | Maintenance engineering: Are updates tested, signed, and communicated? |
| 8. Security guidelines (SG) | Hardening guide, secure configuration, defense in depth expectations for the user, and decommissioning guidance | Labeling / product security: Do users get what they need to deploy and retire the product securely? |
Practice 5 is the testing practice. Blue Goat Cyber performs security and penetration testing for it; general software verification and validation remains with the manufacturer.
IEC 62443-4-2 foundational requirement to evidence table
| Foundational requirement | What it covers | Example device evidence |
|---|---|---|
| FR 1: Identification and authentication control (IAC) | Who or what can connect | Account model, credential storage design, authentication tests, and default credential removal |
| FR 2: Use control (UC) | What an authenticated user can do | Role and permission matrix, authorization tests, and session controls |
| FR 3: System integrity (SI) | Protection against unauthorized changes | Secure boot, code signing, update integrity checks, and tamper test results |
| FR 4: Data confidentiality (DC) | Protection of data in transit and at rest | Encryption design, key management, and protocol test results |
| FR 5: Restricted data flow (RDF) | Segmentation and limiting connections | Port and service inventory, interface restrictions, and network segmentation guidance |
| FR 6: Timely response to events (TRE) | Logging and audit | Security event list, log protection, and log export tests |
| FR 7: Resource availability (RA) | Resilience against denial of service | Rate limiting, resource exhaustion tests, and safe degraded behavior |
Security levels in plain terms
Part 4-2 describes capability security levels from SL 1 (protection against casual or coincidental violation) to SL 4 (protection against sophisticated attackers with extended resources). A target level comes from the system risk assessment. It is not an FDA pass mark, and claiming a level requires evidence for each applicable requirement and enhancement.
How IEC 62443 and IEC 81001-5-1 fit together
| Topic | IEC 62443-4-1 / 4-2 | IEC 81001-5-1 |
|---|---|---|
| Origin | Industrial automation and control systems | Health software and health IT systems |
| Lifecycle | Eight development practices | Development, maintenance, risk, configuration, and problem resolution processes aligned with IEC 62304 |
| Technical controls | Detailed in 4-2 by foundational requirement | Not specified as a component requirement catalog |
| Patient harm | Not addressed | Connects to ISO 14971 where security affects safety |
IEC 81001-5-1 draws on the structure of 62443-4-1, so one set of records can often serve both if each record states which requirement it supports. Assess each standard separately.
Worked example: one control traced across both standards
| Link | Example record | IEC 62443 reference | IEC 81001-5-1 connection |
|---|---|---|---|
| Threat | TM-07: a forged firmware image is installed through the service port | 4-1 SR, SD | Threat and architecture records |
| Requirement | SEC-31: the bootloader rejects unsigned images | 4-2 FR 3 | Security requirement |
| Design | DES-31: signature check with protected root key | 4-1 SD; 4-2 FR 3 | Architecture and design |
| Test | TEST-31: altered and unsigned images are rejected on the release build | 4-1 SVV | Security verification evidence |
| Issue | FIND-04: debug interface left enabled on production units | 4-1 DM | Problem resolution |
| Update and guidance | REL-12 closes the interface; hardening guide updated | 4-1 SUM, SG | Maintenance and release |
FDA context
The FDA's February 3, 2026 premarket cybersecurity guidance, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, does not require IEC 62443 conformance. Manufacturers may use recognized consensus standards to support a submission. Recognition status changes, so check the FDA recognized consensus standards database for each part and edition before citing it in an eSTAR.
Practical gap review
- List which parts and editions you intend to cite.
- For each 4-1 practice, name the procedure and the product record that shows it was followed.
- For each 4-2 foundational requirement, record whether it applies, the control, and the test.
- Confirm test evidence matches the release build.
- Link security findings to SW96 risk records and, where relevant, ISO 14971 hazards.
- Keep one evidence index that states which standard each record supports.
How Blue Goat Cyber helps
We build threat models, security risk assessments, and penetration test evidence that map to IEC 62443 and IEC 81001-5-1 for FDA premarket submissions. We do not certify conformity. See medical device threat modeling and penetration testing.
FAQ
Do medical devices need IEC 62443?
No law or FDA guidance requires it. Many manufacturers use 62443-4-1 and 4-2 because they give detailed development practices and technical requirements that support IEC 81001-5-1 and FDA submissions.
Is IEC 62443 the same as IEC 81001-5-1?
No. IEC 81001-5-1 is written for health software and connects to medical device risk management. IEC 62443 comes from industrial control systems. They share structure, and records can serve both.
What security level should a medical device target?
The target comes from your system risk assessment, the intended use environment, and the attackers you expect. No security level is mandated by the FDA.
Can one test report cover both standards?
Yes, if the report identifies the build, the requirements tested, the results, and the limitations, and your evidence index maps it to each standard.
Sources and primary references
- IEC 62443-4-1:2018, Security for industrial automation and control systems, Part 4-1: Secure product development lifecycle requirements.
- IEC 62443-4-2:2019, Part 4-2: Technical security requirements for IACS components.
- IEC 62443-3-3:2013 and IEC 62443-3-2:2020.
- IEC 81001-5-1:2021, Health software and health IT systems safety, effectiveness and security, Part 5-1: Security, activities in the product life cycle.
- FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, February 3, 2026.
- FDA, Recognized Consensus Standards database.
Sources & references
Primary sources cited in this article. Links open in a new tab.
