Software in Medical Devices, by MD101 Consulting

Unlike other guides and standards, e.g. AAMI TIR 57 or ISO 27005 or FDA guidances, this standard doesn't contain requirements on a cybersecurity risk management process. It is more a set of requirements on cyber security measures to document, implement and verify.
However, the section 12 of the standard requires to establish a security risk management process, with some specific requirements, like the use of classification schemes. E.g. CAPEC or CWRAF

Thus, UL 2900-1 cannot be used alone, and you should rely on other standards or guidances to establish a security risk management process, before implementing UL 2900-1 requirements.

Comparison with 60601 standard?

Can we dare a comparison with 60601-1 standard?
IEC 60601-1 Ed3 contains a (huge) set of technical requirements, with a link to safety risk management process. UL 2900-1 contains a set of technical requirements with a link to security risk management process.
Like IEC 60601-1, evidences of compliance to requirements UL 2900-1 will be found in the device design and device verification plans and reports of the Design History File (FDA) or Technical File (CE mark) of the device.
Like IEC 60601-1, UL 2900-1 is made for certification of products by accredited laboratories, as of today by UL only.

Link with 62304 standard

IEC 62304 defines requirements on software lifecycle processes: development, maintenance, configuration management, and risk management.
UL 2900-1 defines requirements on product. Thus, UL 2900-1 will affect your software development and maintenance plans, as well as software requirement analysis, test plans and test reports required by IEC 62304.
In a few words: IEC 62304 is a process standard, UL 2900-1 is a product standard.
Remark: this is also true for IEC 82304-1

Product documentation

The standard begins with requirements on product documentation. A rough half of the documentation items listed in the standard are already required by regulations or other standards, like IEC 62304.
The second half is specific to UL 2900-1, and is the output of the other requirements found in the standard.
This product documentation will be reviewed by UL for evaluation and certification. If you want to get a certificate.

Technical requirements

The rest of the standard is composed of a set of technical requirements grouped by different topics:

• Risk controls applicable to software design,
• Access controls, user authentication,
• Use of cryptographically secure mechanisms,
• Remote communication integrity and authenticity,
• Confidentiality of sensitive data,
• Product management in post-market: security updates, decommissioning
• Validation of tools and processes from a security standpoint,
• Vulnerabilities exploits and software weaknesses,

The standards ends with requirements on testing strategies, code reviews, static and dynamic analysis, addressing the above topics.
Some requirements are very specific, like:

• Minimum length of passwords shall be at least 6 characters,
• The number of test cases in malformed input testing shall be 1 million cases or 8 hours.

The testing strategies that have to be implemented cover all levels of software architecture: source code, unitary level, and GUI/architectural level.
It demonstrates that being compliant to UL 2900-1 has a strong impact both on design phases and design verification phases (If by any chance you had a doubt :-).

Conclusion

UL 2900-1 is a set of prescriptive requirements applicable to the design, design verification and post-market phases of a medical device. It requires the implementation of a security risk management process, to ensure the compliance to its requirements.
No security risk management process is documented in UL 2900-1. You have to go to AAMI TRI 57 and, more general, to ISO 27005, to find state-of-the-art security risk management processes.