签名启动映像的整个想法是防止用定制的或恶意的东西替换启动映像。然而，整个过程似乎依赖于一个单点故障：图像签名的验证。引导加载程序将需要验证签名图像是否已由私钥签名，这需要将公钥存储在某个地方。
也许它存储在非易失性存储芯片（例如 ROM 芯片）中。也许它存储在内置存储设备中的超级机密扇区中。（还有什么其他选择？）
ROM 芯片（真正只读）难道不是唯一的方法——除非将新芯片焊接到位——以确保引导过程不能被改变吗？如果是这样，为什么移动设备不关心使用这些芯片保持对启动映像的强大控制？是有一些技术原因还是更多的成本/收益原因？
假设设备制造商希望在发现错误时保持一定的灵活性来改变启动过程，他们如何（尝试）保护这个读/写启动代码和/或一组公钥？
对于受信任的引导（或经过身份验证的引导或安全引导，或者您想怎么称呼它），您需要一个受完整性保护的信任根。它不需要是“超级机密”扇区，它需要是“超级屏蔽”扇区。ROM 符合要求。
实际上，设备制造商喜欢在 ROM 中放置尽可能少的代码，因为他们不希望在设备发货前几个月停止更新代码。因此，该代码通常只是初始化一些核心设备（例如，使 MMU 成型），从存储介质加载前几个扇区，根据存储在 ROM 中的公钥验证它们的加密签名，然后将执行转移到该代码. 如果签名不匹配，ROM 代码可能允许用户上传备用启动映像（通常通过 USB）。
第一个非 ROM 引导代码通常比 ROM 代码复杂得多：它通常需要知道如何管理内存、访问各种存储设备、可能读取文件系统、至少具有基本的用户界面等等。因此，在实践中，所有这些代码错误，以及（或在启动链中的后期）是 iPhone 越狱的方式。一些制造商，例如苹果，确实非常关心控制启动映像；这并不意味着他们在一个坚定的社区中取得了成功。
此外，即使已签名的引导映像已保存，操作系统本身也过于复杂，无法承受很长时间的攻击。签署整个操作系统是不切实际的，因为除了最基本的手机和 PDA 之外的所有用户都希望能够安装他们自己的应用程序（操作系统往往有根漏洞）。操作系统通常可以做它想做的几乎所有事情，除了如果它天真地覆盖启动映像，设备将无法启动。如果您想运行不同的操作系统，您可以使用原始操作系统作为启动真实操作系统的起点。
速度是另一个因素：验证 100kB 引导加载程序的真实性在现代智能手机上只是一个小问题，但验证多 GB 操作系统的真实性或完整性太慢，无法立即完成。增量验证还会减慢磁盘读取速度，并且需要目前尚未广泛使用的文件系统支持。