UL 2900 Guide: What It Tests and How to Prepare

Buyers, hospitals and regulators increasingly ask connected product makers for independent evidence that their software has been tested for known vulnerabilities, weaknesses and malware, and UL 2900 is one of the few testable standards built for exactly that. The UL 2900 series sets requirements for software cybersecurity in network-connectable products: how the developer manages security risk, which security controls the product design should contain, and how the product is tested. This guide explains the parts of the series, what an evaluation looks at, how it relates to FDA expectations and to IEC 62443, and how a product team can prepare. It is written for product security leads, medical device and building systems manufacturers, and the procurement and clinical engineering teams who receive UL 2900 claims from suppliers. The standards themselves are sold by UL Standards and Engagement; this guide draws only on public catalogue pages, regulator records and published summaries, so confirm detailed clauses against the edition you buy.

Key takeaways

UL 2900 is a test standard for product software. Part 1 covers developer risk management, security risk controls in architecture and design, and test methods for vulnerabilities, software weaknesses and malware. It excludes functional testing and hardware requirements.
The series has a general part and sector parts. UL 2900-1 is general; UL 2900-2-1 covers healthcare and wellness systems; UL 2900-2-2 (industrial control systems) and UL 2900-2-3 (security and life safety signalling) were published as Outlines of Investigation, and UL Solutions now certifies to UL 2900-2-3.
Editions matter. The ANSI catalogue lists ANSI/UL 2900-1-2026, published 29 June 2026, while the FDA recognised consensus standards database still lists the 2017 first editions of 2900-1 and 2900-2-1. State the edition in every claim and contract.
Evidence beats a certificate alone. Ask suppliers for the scope, edition, level (where the sector part defines levels), software version tested and date, not just a logo.
Preparation is mostly documentation and pipeline discipline. A product team that already runs threat modelling, software composition analysis, static analysis, fuzzing and penetration testing on each release will find an evaluation far smoother than one that tests once for the certificate.

What UL 2900 is and who uses it

UL 2900 is a family of standards titled Software Cybersecurity for Network-Connectable Products. The UL catalogue describes Part 1 as applying to network-connectable products that need to be evaluated and tested for vulnerabilities, software weaknesses and malware, with requirements in three areas: the software developer's risk management process (including vendors and other supply chain members), methods for evaluating and testing the product, and security risk controls in the product's architecture and design. It states plainly that the standard does not verify that the product works as designed and contains no hardware requirements.

That scope makes UL 2900 different from process standards such as IEC 62443-4-1 or the NIST SSDF. Those ask "does the manufacturer run a secure development lifecycle?" UL 2900 asks "does this build of the product, tested by a third party, show known vulnerabilities, exploitable weaknesses or malware, and does its design contain the expected risk controls?" Many manufacturers hold both kinds of evidence. See the IEC 62443-4-1 and 4-2 Secure Product Development Guide for the process side.

Manufacturers: medical device makers (driven by FDA premarket expectations), building security and fire alarm vendors, and IoT makers who want a recognised third-party test result for buyers.
Buyers and asset owners: hospitals, integrators and facilities teams use UL 2900 results as one input to procurement risk review.
Test labs: UL Solutions certifies to the series through its Cybersecurity Assurance Program (CAP), and other labs, such as Intertek, publicly offer gap analysis and full evaluation against ANSI/UL 2900.

The parts of the series and their status

Status is the area where claims most often go stale. The table records what the public sources showed when checked in November 2026.

Part	Scope	Status shown in public sources (checked November 2026)
UL 2900-1	General requirements for software cybersecurity of network-connectable products	First edition published 5 July 2017; the UL catalogue marks Edition 1 superseded and Edition 2 active, ANSI and SCC approved 14 April 2023 (ANSI/CAN/UL 2900-1). ANSI lists ANSI/UL 2900-1-2026, published 29 June 2026, based on the CAN/UL edition with inclusive language changes. FDA recognition 13-96 (first edition 2017, extent complete, entered 21 August 2017).
UL 2900-2-1	Particular requirements for network-connectable components of healthcare and wellness systems: medical devices, in vitro diagnostic devices, health IT and wellness devices	FDA recognition 13-104 (first edition 2017, extent complete, entered 7 June 2018).
UL 2900-2-2	Industrial control system components such as PLCs, SCADA servers and HMIs	Published as an Outline of Investigation (2016); public summaries describe it as not developed into a published standard. Most industrial buyers use IEC 62443-4-2 instead.
UL 2900-2-3	Security and life safety signalling systems: fire alarm, intrusion detection, alarm receiving, access control, emergency communications, video surveillance (cameras, DVRs, NVRs)	UL Solutions offers certification and issues a UL certificate to qualifying products; it describes the standard as ANSI approved.

Two practical consequences follow. First, a medical device file that cites "UL 2900-2-1" should say which edition, because the FDA database entry records the 2017 edition. Second, a building systems certificate should state its UL 2900-2-3 level, because the levels cover very different depths of testing (see below).

What an evaluation examines

Public summaries of Part 1 (for example the structure published by the evaluation lab jtsec) describe five blocks of requirements. They are summarised here in our own words; the clause detail belongs to the purchased standard.

Area	What the evaluator looks for	Evidence the manufacturer prepares
Product documentation	Design and security documentation, sensitive data handling, the list of libraries and executable code, guidance on secure configuration, updates, operating environment, authentication and supported protocols	Architecture and data flow diagrams, sensitive data inventory, component list (an SBOM is the natural format), secure configuration and hardening guide for customers
Risk controls in design	Access control and authentication (session timeouts, configurable password rules, lockout or delay after repeated failures, role-based access where supported), integrity and authenticity of remote communication, confidentiality of sensitive data with validated cryptography, verified software updates with rollback, security event logging, secure erasure at decommissioning	Control descriptions mapped to threats, crypto module and algorithm list, update signing design, log event catalogue, decommissioning procedure (summaries cite NIST SP 800-88 for media sanitisation)
Developer risk management	Identification of functions and sensitive data, a threat list with assessment, controls, and a traceability matrix from threat to control to test; summaries mention CAPEC or DREAD for threat classification and CWE identifiers for weaknesses	Threat model, risk register, traceability matrix, accepted-risk rationale signed off by the product owner
Vulnerability and malware testing	Known vulnerability testing including third-party code (checked against the NVD), malware scanning suited to the operating system, fuzz testing of external interfaces with timely recovery, structured penetration testing covering control bypass, denial of service and privilege escalation	Software composition analysis report, malware scan report, fuzzing harnesses and results, internal penetration test report and fixes
Software weaknesses	Static analysis of source and of binary and bytecode files, with no remaining weaknesses beyond those accepted in the risk analysis	SAST and binary analysis results, triage records, justification for each accepted finding

The 2023 revision summary on the UL catalogue lists changes touching product documentation, sensitive data documentation, structured penetration testing, software composition analysis, static source code analysis and static binary and bytecode analysis. If your preparation material was written against the 2017 text, recheck those areas first.

UL 2900-2-3 levels

UL Solutions' public material on security and life safety signalling systems describes three levels, which are useful vocabulary for buyers even outside that sector:

Level 1: foundational, black-box style testing without source code; described as the recommended minimum.
Level 2: Level 1 plus source code testing; recommended as the lowest level for products that send, receive or process sensitive data.
Level 3: Levels 1 and 2 plus review of the vendor's processes, management and business practices across the product lifecycle.

The same material lists the test activities as malformed input testing, known vulnerability detection, code and binary analysis, risk control analysis, structured penetration testing and security risk controls assessment.

UL 2900 and medical devices

Medical devices are where UL 2900 is most often cited. The FDA recognised UL 2900-1 (recognition 13-96) and UL 2900-2-1 (recognition 13-104) as consensus standards. Recognition means a manufacturer can declare conformity to support a premarket submission; it does not replace the content FDA expects in the submission.

That content is set out in the FDA final guidance Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, current version dated February 2026, which supersedes the June 2025 version and covers section 524B of the FD&C Act for cyber devices. A UL 2900-2-1 test report is strong evidence for the testing part of a submission, but manufacturers still need the threat model, security architecture views, SBOM and postmarket vulnerability management plan the guidance describes. See the FDA Medical Device Cybersecurity Guide and, for European obligations, the EU MDR Cybersecurity and MDCG 2019-16 Guide.

For hospital buyers, a UL 2900-2-1 result pairs well with the manufacturer's MDS2 form and SBOM. Ask for all three together; the MDS2 and Medical Device SBOM Guide for Hospitals covers how to review them.

How UL 2900 compares with other product security schemes

Choose the evidence that matches the buyer and the market, not the one that is easiest to obtain.

Scheme	What it assesses	When it is the better fit
UL 2900-1 / 2900-2-x	A specific product build: design controls, known vulnerabilities, weaknesses, malware, fuzzing and penetration test results, plus developer risk management	Medical devices for the US market, building security and life safety products, buyers who want a product-level test result
IEC 62443-4-1 and 4-2	4-1: the supplier's secure development process; 4-2: component technical capabilities against security levels	Industrial automation and OT components, asset owners who specify security levels per zone
NIST IR 8259 series and the US Cyber Trust Mark	Baseline device capabilities and manufacturer activities for consumer IoT	Consumer IoT sold in the US, federal procurement of IoT
EU Cyber Resilience Act and harmonised standards	Legal essential requirements for products with digital elements placed on the EU market	Any product sold in the EU; UL 2900 evidence can support but does not replace CRA conformity

The IoT Product Security Standards Compared guide covers the wider landscape, and the EU Cyber Resilience Act Guide covers the EU law.

Small manufacturers: start with a gap analysis against Part 1 and the relevant sector part before committing to a full evaluation; fix documentation gaps first, as they are cheap.
Large portfolios: standardise the evidence pipeline (SBOM, SCA, SAST, fuzzing, penetration testing per release) so any product line can enter evaluation without a special project.
Industrial vendors: where customers specify IEC 62443, UL 2900-2-2 is rarely the right target; use 62443-4-2 and keep UL 2900 for markets that ask for it.

How to prepare for an evaluation

Define the target of evaluation: product model, software and firmware version, interfaces in scope, operating environment and the exact standard edition and part (and level, for 2900-2-3). Freeze the build you will submit.
Buy and read the standard: the edition the lab will test against, plus any sector part. Public summaries help orientation but are not a substitute.
Run a gap analysis: internally or with a lab. Map each requirement to an owner and an artefact. Most early gaps are missing documentation, unowned third-party components and accepted risks without written rationale.
Build the threat model and traceability matrix: functions, sensitive data, threats (classified with CAPEC or a similar scheme), controls and the test that verifies each control. See the Threat Modelling Guide.
Clean the component list: produce an SBOM for the frozen build, run software composition analysis against the NVD and vendor advisories, and patch or justify every known vulnerability. For firmware without source, use binary analysis; see the Binary Software Composition Analysis Guide.
Close weaknesses: run static analysis on source and binaries, triage by CWE, and document every finding you accept and why.
Test the interfaces: fuzz every external interface and check the product recovers cleanly; run your own structured penetration test before the lab does. See the Fuzzing Guide and the IoT and Hardware Penetration Testing Guide.
Verify the design controls: update signing and rollback, session timeouts, account lockout or delay, role separation, logging to non-volatile storage, crypto inventory and secure erase.
Submit and remediate: expect findings. Fix, retest and keep the remediation record; it is reusable evidence for regulators and customers.
Maintain: decide which changes trigger re-evaluation (new interfaces, major component upgrades, crypto changes) and keep running the same tests on every release so the certificate reflects the product customers actually run.

Rollback and re-test: if a fix for an evaluation finding breaks a clinical or safety function, revert to the last validated build, record the finding as an accepted risk with compensating controls, and agree a re-test date with the lab rather than shipping an untested change.

Where identity fits

Several UL 2900 design controls are identity controls: authentication of users and services, role-based access, protection of credentials and keys, and authenticity of remote communication. Connected products also carry machine identities: device certificates, service accounts for maintenance, API keys for cloud back ends and update signing keys. Hard-coded or shared credentials in firmware are a common evaluation finding and a common route to fleet-wide compromise. Give each device a unique identity, keep signing keys in hardware-backed storage and document key rotation. See the IoT Device Identity with TPM and DICE Guide and the IoT Device Certificates vs Pre-Shared Keys guide.

Measuring readiness and ongoing assurance

Known vulnerabilities open in the release build: count by severity at release; target zero unjustified findings.
Traceability coverage: percentage of threats with a mapped control and a passing test.
Static analysis backlog: open weaknesses by CWE class, and the share with a documented acceptance.
Fuzzing coverage: percentage of external interfaces with an automated fuzz harness run per release.
Time to remediate evaluation findings: median days from lab report to verified fix.
Certificate currency: share of shipping software versions covered by a current evaluation.

Framework mapping

UL 2900 area	NIST SP 800-53 Rev 5	NIST CSF 2.0
Developer risk management and threat analysis	RA-3 Risk Assessment; SA-15 Development Process, Standards, and Tools	PR.PS-06
Vulnerability, malware, fuzz and penetration testing	SA-11 Developer Testing and Evaluation	ID.RA-01
Component list and third-party code	CM-8 System Component Inventory; SR-4 Provenance	GV.SC-05
Verified updates and integrity	SI-7 Software, Firmware, and Information Integrity	PR.PS-06

Common failure patterns

Citing the standard without an edition: "UL 2900 compliant" with no part, edition, level, version or date tells a buyer almost nothing.
Treating the certificate as permanent: new components and new CVEs arrive after evaluation; without per-release testing the result ages quickly.
Undocumented accepted risks: weaknesses left open without written rationale fail the "accepted in the risk analysis" test.
Testing a different build: evaluating a lab build while shipping a later firmware with new libraries.
Using UL 2900 as the whole regulatory answer: it supports, but does not replace, FDA premarket content or EU CRA conformity.
Shared or default credentials in firmware: they surface in penetration testing and undermine the access control requirements.

Practitioner checklist

Record the exact part, edition, level and software version for every UL 2900 claim.
Buy the current edition and run a gap analysis before booking a full evaluation.
Maintain a threat model with a threat to control to test traceability matrix.
Produce an SBOM per release and clear or justify every known vulnerability.
Run static source and binary analysis, and document every accepted finding.
Fuzz all external interfaces and run a structured penetration test before submission.
Verify signed updates with rollback, lockout or delay on failed logins, logging and secure erase.
Define re-evaluation triggers and keep the same tests running on every release.
As a buyer, request the test report scope, MDS2 (for medical devices) and SBOM alongside the certificate.