UL 2900-1 (software cybersecurity for network-connectable products), explained

UL 2900-1, "Standard for Software Cybersecurity for Network-Connectable Products, Part 1: General Requirements," is a certification standard from UL Standards & Engagement (formerly Underwriters Laboratories) that sets baseline software-security testing and risk-management requirements for any network-connected product. First published and ANSI-adopted in July 2017, the current active edition is Edition 2 (ANSI/CAN/UL 2900-1), published 13 December 2023, with a further edition (ANSI/UL 2900-1-2026) published 29 June 2026 per its listing standards body. UL 2900-1 is a commercial standard — sold by UL and ANSI rather than published in full for free — so this guide draws on the publicly available scope statement and structure, cross-checked across UL's own product listing and an independent professional-association summary, rather than the purchased requirement text itself; treat specific sub-requirement wording as to be confirmed against a purchased copy before using it for a conformance claim.

What the scope statement actually commits to

UL's own product page and the CS2AI (Control System Cyber Security Association) standard summary both quote the identical scope line: "This standard applies to network-connectable products that shall be evaluated and tested for vulnerabilities, software weaknesses and malware." The standard then breaks its substantive requirements into three areas:

Area	What it covers
Risk management process	Requirements on the software developer (vendor or other supply-chain member) to run a documented risk-management process for the product
Evaluation and testing methods	The methods by which a product "shall be evaluated and tested for the presence of vulnerabilities, software weaknesses and malware"
Security risk controls	Requirements on the presence of security risk controls in the product's architecture and design

Two explicit exclusions

UL 2900-1 draws its own boundary carefully. Per its scope section: "This standard does not contain requirements regarding functional testing of a product" — meaning it has no requirement to verify the product does what it's supposed to do, only that it resists vulnerabilities, weaknesses and malware — and "This standard does not contain requirements regarding the hardware contained in a product," meaning it is a software-only standard. A vendor relying on UL 2900-1 alone still needs separate functional and hardware-safety assurance; UL 2900-1 fills the software-cybersecurity gap specifically.

Part of a four-part series, underneath one certification program

UL 2900-1 is the general, sector-agnostic Part 1. Three sector-specific parts build on it rather than duplicating it:

• UL 2900-2-1 — Particular Requirements for Network Connectable Components of Healthcare and Wellness Systems (published September 2017)
• UL 2900-2-2 — industrial control system components (PLCs, SCADA, RTUs and similar)
• UL 2900-2-3 — electronic physical security and life-safety signalling systems (access control, surveillance cameras, DVR/NVR, alarm receiving and emergency-communication systems)

All four sit underneath the UL Cybersecurity Assurance Program (UL CAP), UL's certification program for network-connectable products and systems. Per secondary summaries of UL's own program description, UL CAP testing includes "static binary analysis for software weaknesses identified by Common Weakness Enumerations (CWE), open source software and third-party libraries, as well as structured penetration testing based on flaws identified in other tests," and the program additionally verifies that a certified vendor "maintains reasonably mature processes for the development and maintenance of the software" — so that a future patch or new version doesn't quietly regress below the certified protection level. UL CAP traces back to an April 2016 program launch developed in collaboration with the US Department of Homeland Security, aimed at giving buyers of IoT and other connected products independent confidence that a product meets a tested security baseline.

FDA recognition: a documented pathway, not a mandate

UL 2900-1's clearest regulatory foothold is in US medical device premarket review. Independent secondary reporting (SoftwareCPR's contemporaneous summary and UL's own announcements) places UL 2900-1 Edition 1 (2017) on FDA's list of recognized consensus standards around 21 August 2017, under FDA Recognition List Number 047, under the FDA Modernization Act of 1997's standards-recognition authority; the healthcare-specific companion UL 2900-2-1 followed with its own FDA recognition around June 2018. This guide was unable to directly render FDA's own accessdata.fda.gov database record or the underlying Federal Register notice PDF during this fetch — both are primary, free, public sources, so verify the exact current Recognition Number directly against FDA's live database before citing it in a regulatory submission. What recognition means in practice: a device maker can cite conformance to a recognized standard as part of a premarket cybersecurity submission instead of having to justify a bespoke test methodology from scratch. It does not make UL 2900 certification itself mandatory — outside specific regulator or customer-contract requirements, pursuing UL CAP certification against UL 2900-1 remains voluntary.

A workable starting point

1. Treat UL 2900-1 as the software-only floor. It has no hardware or functional-testing requirements — pair it with whatever hardware-safety and functional-verification standards already apply to the product.
2. Pick the matching sector-specific part if one exists. A medical, industrial-control, or physical-security product should be evaluated against UL 2900-2-1, -2-2 or -2-3 respectively, on top of the Part 1 general requirements — not Part 1 alone.
3. Decide whether UL CAP certification is worth pursuing, separately from the standard itself: certification adds independent, repeatable evidence (CWE-based static analysis plus structured penetration testing) and an ongoing-maintenance assurance that a self-assessment against the written requirements does not provide on its own.
4. If targeting FDA premarket submission, confirm the live Recognition Number first. This guide's recognition-date and list-number details come from secondary reporting, not a directly rendered FDA database record — don't cite a specific recognition number in a regulatory filing without checking FDA's own search tool.
5. Budget for a purchased copy before implementation. Like most ANSI/UL standards, the actual clause-by-clause requirement text is commercial; the scope statement quoted here is enough to scope a program, not to build a test plan against.

SoftWSP's device and firmware security assessments can map a connected product's vulnerability testing, risk-management documentation and security architecture against UL 2900-1-style requirements alongside NIST, ETSI and IEC 62443 baselines: see Device & Firmware Security.

This guide summarises UL 2900-1's publicly available scope statement and structure (UL's own product listing, a professional-association standard summary, and independent secondary reporting on its FDA recognition); it is not a substitute for the full purchased standard or FDA's own recognized-standards database, and does not constitute compliance or legal advice.