一些可能相关的技术因素：

1. 性能 - 对您的应用程序（如果有的话）来说很重要：加密/解密/密钥生成/签名，对称，非对称，EC，......
2. 规模：
   • 它支持的键数量是否有限制，这个限制可能是个问题吗？
   • 当您的应用程序要求更高（大小、速度、地理分布......）时，添加另一个 HSM 是多么容易
3. 冗余 - 当一个 HSM 发生故障时，它对您的操作有多大影响，在不中断服务的情况下更换它的难易程度等
4. 备份 - 自动化和恢复有多容易？您是否需要独立保护备份的机密性和/或完整性，或者产品是否确保了这一点？您最终处于不可恢复地丢失数据的位置的可能性有多大（需要丢失/忘记多少因素，HSM 死亡等）。
5. API 支持：
   • MS CAPI/ CNG（易于在 Windows 环境中编程）；
   • JCA（易于使用 Java 开发。支持什么版本？）；
   • PKCS#11（和最新版本？广泛支持跨应用程序，尽管它带有已知的安全问题）；
   • 供应商专有（如果您知道自己在做什么，可能是最灵活/最强大/最安全的，但会增加转移到另一个供应商的成本），虽然 C 可能是给定的，但它是否具有您首选的绑定语？
   • 相关说明：是否有与您的应用程序（例如 DBMS、操作系统服务）集成的指南？
6. 操作系统/硬件支持
7. 管理选项 - 有哪些 GUI / 命令行工具可用于执行管理任务 - 即任何您不经常做而不想自动化的事情（密钥生成？；身份验证因素管理？）。您的管理员是否需要亲自到场才能调试设备或在调试后执行其他任务？
8. 可编程性 - 您的大部分开发可能会在其中一个 API 的另一端进行，但有时能够编写在设备上运行的应用程序以获得更大的灵活性或速度是有用的（请参阅Thomas 的回答）
9. 物理安全 - 您的解决方案需要对直接物理攻击有多大的抵抗力（不仅要考虑 HSM，还要考虑整个解决方案）？如果出于某种原因你决定就显得尤为重要（你HSM暴露，但你的客户都没有，还是按键的披露是远远不仅仅是能够更糟使用的键不可告人的目的-裁判DigiNotar？），那么你可能想寻找主动篡改检测和响应，而不仅仅是被动防篡改和证据。
10. 逻辑安全模型 - 网络上的恶意实体会滥用您的 HSM 吗？主机 PC 上的恶意进程？
11. 算法 - HSM 是否支持您要使用的加密（原语、操作模式和参数，例如曲线、密钥大小）？
12. 身份验证选项 - 密码；法定人数；n 因子；智能卡；一次性密码；...在允许使用密钥进行操作之前，您可能至少应该寻找可能需要令牌+密码身份验证用户的可配置仲裁大小的东西。
13. 策略选项 - 您可能希望能够定义策略，例如控制是否： 可以从 HSM 导出密钥（封装或未加密）；密钥只能用于签名/加密/解密/...；签名需要身份验证，但不需要验证；等等。
14. 审计能力——包括类似 HSM 的操作（生成密钥，用密钥 Y 签名）和处理崩溃（参考 g3k 的评论）。将日志集成到Splunk之类的东西中有多容易（健全的日志格式、syslog/snmp/其他网络可访问的 - 或至少是非专有的 - 输出）？
15. 构成因素：
    • 网络 附加（用于更大规模的部署，特别是在多个应用程序/服务器/客户端需要使用密钥的情况下）；
    • 台式机（供个人使用；性能、可用​​性和可扩展性不是一个大问题，但成本是，如果您的解决方案需要很多人需要直接访问 HSM，则特别好）；
    • PCI (-express)（比网络连接更便宜；更多的努力涉及使多个应用程序可用）；
    • USB 令牌（服务器升级简单；便宜又慢（而且容易被盗！））；
    • PC 卡（根据台式机，但适合笔记本电脑用户）。 （PC卡现在已经死了）

一些非技术因素：

1. 认证 - 您是否需要任何/是否想要任何认证，因为它们让您对产品的安全性充满信心？出于监管原因而 忽略您的需求：
   • FIPS 140-2 提供了有用的确认，即 NIST 批准的算法有效并且具有运行时已知答案测试（检查安全策略以查看他们已获得批准的算法），但不要在其中投入太多库存，否则会显示产品是安全的；我对 3 级硬件安全性的经验法则意味着只有几分钟访问该设备的人将很难破坏它。FIPS 140-2 3 级是 HSM 的事实上的基线认证 - 如果没有，请小心（尽管这并不是说您需要以符合 FIPS 的方式使用它）。
   • 通用标准评估在它们提供的保证方面是灵活的：阅读安全目标！目前还没有像样的 HSM 保护配置文件，因此至少在了解评估提供的内容之前，您必须阅读安全问题定义（威胁和假设）。
   • 如果您从事相关行业，PCI-HSM 将很有用
2. 除了认证之外，供应商在安全方面的表现如何？拥有 CC EAL4 证书是一个很好的起点，但请记住 Win2k 也拥有这些证书……他们是否会在供应链完整性、安全软件开发生命周期、ISO2700x 或类似The Open Group 的可信赖技术提供商框架之类的方面发出令人信服的声音？
3. 您喜欢供应商的披露政策吗？
4. 支持（选项、声誉，以您的语言提供）
5. 服务——如果你有一个复杂的需求，让供应商参与你的配置/编程可能是有利的。
6. 文档：
   • 高级文档 - HSM 是复杂的通用产品，可能需要一些复杂的管理；良好的文档对于让您围绕它们开发安全且可行的流程很重要（有关更多讨论，请参见Thomas 的回答）。
   • API 文档 - 良好的覆盖范围，最好包括常见（和复杂）任务的良好示例
7. 成本（单位 + 维护）
8. 交货时间
9. 供应商补丁政策/频率（+支持和简化固件升级）
10. 设计和/或制造国家 - 您可能是特别（不）信任某些国家的政府或公司
11. 供应商稳定性 - 只要您将要使用该产品，他们是否会一直支持该产品？
12. 供应商的产品路线图是什么，它对您有什么价值吗？您是否可以通过固件升级访问未来的版本？
13. 你在RSA上摆脱了他们，这真是太好了

可能还有更多。

SANS 研究所有一篇很好的介绍性论文，描述了为什么您可能需要 HSM、它（应该）具有的积极属性以及一些缺点。

似乎 HSM 供应商同意此列表的大部分内容，并制作了他们自己的（未署名的）版本。

HSM 不会避免复杂性；相反，它会给整个系统增加相当多的复杂性。

HSM 最擅长的是密钥存储：密钥在 HSM 中并且永远不会从其中取出。但是，您仍然需要担心密钥的生命周期。使用存储在文件或操作系统内部的“软件”密钥，备份是一个漏洞（您不希望密钥的许多副本随处可见）。使用 HSM，可以避免此漏洞，但备份成为一个令人头疼的问题：丢失密钥也是一个重大风险，尤其是对于加密（如果丢失加密密钥，则丢失数据）。所以这是 HSM 的第一个项目：备份过程. 我有一些使用 Thales (nCipher) HSM 的经验，它是这样操作的：密钥实际上存储为加密文件（可以像任何文件一样保存），并且该密钥的解密密钥可以用法定人数重建管理员智能卡（在新 HSM 中）。

HSM 很少进行批量对称加密。实际上，使用 HSM 进行对称加密没有多大意义：您使用加密是因为数据是机密的。从逻辑上讲，如果需要保密使得对称密钥不能离开 HSM，那么数据本身也不应该离开它。此外，对称加密意味着加密和解密都使用相同的密钥：如果该密钥在 HSM 中，则加密和解密都必须通过它。

HSM 更适合与混合加密一起使用：HSM 存储和使用非对称加密系统的私钥；当要加密数据时，谁拥有数据，谁就生成一个随机对称密钥K ，用K加密数据，用HSM存储的私钥对应的公钥加密K。从这个意义上说，HSM 作为（超大、定价过高的）智能卡运行。

当然，还有另一个极端，您可以在 HSM 中安装整个应用程序。这需要一个可编程的HSM，这是一个完全不同的上下文。Thales HSM 允许将其作为一个选项（称为“CodeSafe”和“SEE”），他们不会免费提供这些......并且不要期望在其中运行传统代码。HSM 具有加密加速器，但它们在其他方面是相当有限的嵌入式系统（最多认为 60 MHz ARM CPU：HSM 屏蔽与散热不符）。您可以在 HSM 中安装相对复杂的代码（允许这样做），但这是一项特定的编程工作。此外，一些 HSM 根本不允许这样做。

尽管 HSM 很昂贵，但 HSM 中最大的成本是操作：它们需要大量的安装、配置、操作、恢复和停用过程。你会需要人。我的主要标准是：程序。一个好的 HSM 会附带一份详细的使用手册，其中描述了应该如何做。重要的不是硬件，而是你如何使用它。

出于监管目的，可能需要认证，例如 EAL 4+ 或 FIPS 140-2 Level 3。你很少选择是否需要它；这是预期使用上下文的要求。获得这样的认证是一个非常漫长和昂贵的过程，所以你不会自己去做。另一方面，您可能希望扩大购物范围：如果 HSM 主要是大型智能卡，则可以使用智能卡代替 HSM。一张20 欧元的智能卡可以是 FIPS 140-2 3 级；它每秒只计算一次 RSA-2048 解密而不是 500，但这对您来说可能就足够了。