UL 2900 Series
Standard for Software Cybersecurity for Network-Connectable Products
Overview
Scope
The UL 2900 series is a family of cybersecurity standards published by Underwriters Laboratories (UL) for network-connectable products. The series includes: UL 2900-1 (General Requirements) — the base standard covering software cybersecurity requirements applicable to all network-connectable products; UL 2900-2-1 (Healthcare and Wellness Systems) — the healthcare-specific extension adding requirements for medical devices, health IT, and wellness products; UL 2900-3 (Security Risk Assessment) — additional guidance on cybersecurity risk assessment methodology. UL 2900-2-1 is FDA-recognized and provides a testing-centric complement to the process-oriented standards (SW96/IEC 81001-5-1).
Why It Matters
UL 2900-2-1 is unique in the medical device cybersecurity landscape because it is a testable standard — while SW96 and IEC 81001-5-1 define processes, UL 2900 defines test cases. FDA recognition of UL 2900-2-1 means that third-party testing and certification to this standard provides strong evidence for your premarket submission's cybersecurity testing section. For device manufacturers, UL 2900 certification: (1) provides independent, third-party validation of your device's security posture, (2) satisfies specific eSTAR cybersecurity testing evidence requirements, (3) differentiates your product in competitive procurements where hospitals value independent security certifications, and (4) demonstrates to FDA that structured security testing was performed by a qualified laboratory.
Key Concepts
- Testing-centric standard — defines what to test, not just what processes to follow
- FDA-recognized consensus standard (UL 2900-2-1) for healthcare cybersecurity
- Static analysis: source/binary code analysis for known vulnerability patterns (CWE)
- Fuzz testing: automated input mutation testing on all external interfaces
- Known vulnerability scanning: SBOM-based CVE analysis against NVD
- Malware testing: analysis for known malicious code signatures and behaviors
- Structured penetration testing: methodology-driven security assessment
- Software weakness analysis: CWE-based code quality evaluation
- Product security certification: third-party lab testing and UL Mark issuance
- Complements process standards (SW96, IEC 81001-5-1) with testing evidence
🔧 Insight coming soon... Here's what we know: regulatory compliance and international standards conformance aren't obstacles—they're the foundation that lets us build devices people can trust with their health and their lives. The real opportunity? When we collaborate across disciplines—sharing knowledge about laser and light-based technologies, software validation, risk management, and clinical evidence—we accelerate everyone's ability to bring better solutions to patients who need them. This section will feature practical insights on implementing this standard effectively. Because faster submissions, better safety protocols, and stronger clinical outcomes aren't competing goals—they reinforce each other when we get the fundamentals right. Together, we can navigate these requirements and focus on what matters: developing medical devices that make a real difference.
— ER | medev.ai
Building better devices, together.
Testing Categories
Fuzz Testing (UL 2900-1 § 6)
Automated testing of all external interfaces (network protocols, USB, BLE, serial, file parsers) with malformed, random, and boundary-value inputs. The goal is to discover crashes, hangs, memory leaks, and unexpected behaviors that could indicate exploitable vulnerabilities. UL 2900 specifies minimum fuzz iterations and coverage metrics. All detected crashes must be triaged for security impact (potential buffer overflow, use-after-free, null pointer dereference) and classified using CWE taxonomy.
Static Analysis and Source/Binary Code Review (UL 2900-1 § 7)
Analysis of source code (if available) or binary code for known vulnerability patterns, insecure coding practices, and software weaknesses. Results are classified using CWE (Common Weakness Enumeration). Critical and High findings must be remediated or risk-accepted with justification. Tools used include SAST (Static Application Security Testing) scanners configured for CWE coverage relevant to the device's language and platform.
Known Vulnerability Analysis (UL 2900-1 § 8)
Analysis of all software components against known vulnerability databases (NVD, CVE). This is effectively SBOM-based vulnerability scanning. All identified CVEs must be: scored using CVSS, evaluated for applicability (is the vulnerable function called?), classified as mitigated, risk-accepted, or patched. Any CVE with CVSS ≥ 7.0 that is applicable and unmitigated typically fails this requirement.
Malware Testing (UL 2900-1 § 9)
All software distributed with the product is scanned for known malware, trojans, backdoors, and unauthorized code. This verifies the integrity of the software build and distribution chain. Particularly relevant for devices with embedded operating systems (Linux distributions, RTOS packages) where supply chain compromise is a rising threat.
Structured Penetration Testing (UL 2900-1 § 10)
Methodology-driven penetration testing covering: authentication bypass attempts, authorization escalation, data exfiltration scenarios, session management attacks, cryptographic implementation assessment, and network service exploitation. Testing follows a structured methodology (not ad-hoc) and all findings are documented with reproducible steps, CVSS scores, and remediation recommendations.
Healthcare-Specific Requirements (UL 2900-2-1)
Additional requirements for healthcare products: patient data protection assessment (alignment with HIPAA and privacy requirements), safety-critical function analysis (evaluation of cybersecurity impact on clinical safety), interoperability security (HL7, FHIR, DICOM interface testing), and healthcare-specific threat scenarios (clinical workflow disruption, therapy modification, diagnostic data integrity attacks).
Evaluating UL 2900 for Your Regulatory Strategy
Determine if UL 2900 Certification Adds Value
UL 2900 certification is not required for FDA submission — it is one way to demonstrate cybersecurity testing adequacy. Evaluate: (1) Does your target market (hospital systems, IDNs) value UL 2900 certification? (2) Is your device Class II or III where independent testing strengthens the submission? (3) Do you have the budget for laboratory testing ($20K–$100K+ depending on device complexity)? (4) Are you willing to remediate all Critical/High findings before certification?
Conduct Self-Assessment Testing First
Before engaging a UL-accredited lab, conduct internal testing aligned with UL 2900 test categories: run SAST scans, execute fuzz testing on all interfaces, perform SBOM vulnerability analysis, and conduct internal penetration testing. This identifies and remediates issues before the costly lab engagement. Use results to estimate the lab testing timeline and cost.
Engage a UL-Authorized Laboratory
UL 2900 testing must be performed by a UL-authorized laboratory for certification. Submit your device for testing, provide necessary documentation (architecture diagrams, SBOM, source code access if required), and support the testing process. The lab will issue a findings report, and after remediation of critical findings, issue the UL Mark certification.
Reference Certification in FDA Submissions
Include UL 2900-2-1 certification in your premarket submission's cybersecurity testing section. Reference: "Cybersecurity testing was performed in accordance with UL 2900-2-1, an FDA-recognized consensus standard, by [Lab Name] (UL-authorized laboratory). Certification was issued on [date]." This provides strong evidence of independent security validation.
Common Challenges & Solutions
High cost of UL 2900 laboratory testing
Lab fees range from $20K to $100K+ depending on device complexity, number of interfaces, and code size. For smaller companies, consider: (1) conducting internal testing aligned with UL 2900 categories and documenting results for your FDA submission without formal certification, (2) phasing testing — start with known vulnerability analysis and fuzz testing (most impactful), add penetration testing later, (3) negotiating the scope to focus on the highest-risk interfaces.
Fuzz testing discovers many crashes — remediation backlog
Fuzz testing commonly discovers dozens of crash scenarios. Triage rapidly: classify each crash using CWE, score severity, and focus remediation on exploitable vulnerabilities (buffer overflows, format string bugs, use-after-free). Non-security crashes (null pointer dereferences in non-reachable code paths) can be risk-accepted with documentation.
Known vulnerability analysis flags CVEs in third-party components
SBOM-based vulnerability analysis often reveals CVEs in open-source components. For each CVE: (1) determine if the vulnerable function is actually called by your product, (2) if not applicable, document the inapplicability rationale, (3) if applicable, patch/update the component or implement a compensating control, (4) risk-accept with justification only as a last resort for Low/Medium CVEs.
Related Standards
ANSI/AAMI SW96:2023
Medical device security — Security risk management
SW96 provides the risk management process; UL 2900 provides the testing methodology. Together they form a comprehensive security assessment
IEC 81001-5-1:2021
Health software security — Activities in the product life cycle
IEC 81001-5-1 defines security lifecycle activities; UL 2900 testing satisfies the verification and validation security testing requirements
ISO 14971:2019
Application of risk management to medical devices
UL 2900 testing results feed into the risk management process — identified vulnerabilities are inputs to the cybersecurity risk assessment
IEC 62304:2006/A1:2015
Medical device software — Software life cycle processes
UL 2900 static analysis and testing aligns with IEC 62304 software verification requirements
Resources
Official Resources
Implementation Tools
Copyright Notice: UL 2900 Series is copyrighted by IEC. This page provides implementation guidance and educational content only. The standard itself must be purchased from the official IEC website.