欧洲主权云的固件证明层，在公共部门工作负载上线前，证明 Intel ME 和 AMD PSP 风险已被控制。

1. 主权云项目已经要认证数百项控制，所以一旦公共买方追问 OS 之下到底是什么，缺失的处理器这一层就会立刻变成显眼缺口。
2. 隐藏管理引擎拥有自己的网络路径，意味着只做软件层证明，根本没法诚实回答敏感工作负载的主权问题。
3. PLATINUM 的 Serial-over-LAN 案例，把管理引擎暴露从抽象的架构缺陷，变成了采购团队必须正面回答的真实外传路径。
4. RISAA 2024 让主权问题不只是技术问题，也成了法律问题，因为即便云托管在欧洲，芯片供应商仍可能成为看不见的合规依赖。

催化因素。 欧洲主权云框架正在加速落地，而管理引擎被滥用的公开案例，加上芯片供应商面临的法律强制风险，已经让这块硬件盲点在下一轮采购里很难再被忽视。

做一套固件主权平台，发现主权云机柜里主板、BMC 和处理器管理引擎的真实状态，再把这些状态翻成买方看得懂的合规证据。产品会检查 ME 或 PSP 是开启、被中和、被隔离、已打补丁，还是仍暴露高风险远程管理能力，然后把结果映射到具体加固动作和补偿性控制上。它会持续生成绑定具体服务器 SKU 与工作负载隔离域的审计材料、投标附件和续期证据包，而不是一次性的实验室报告。往后走，这个平台会变成一套控制平面：哪些机柜能承载主权工作负载，哪些需要整改，哪些该直接排除在敏感合同之外，都由它来判。

差异化。 通用固件盘点工具和机密计算产品，并不会产出可直接用于采购的管理引擎状态证据；一次性的咨询项目，也没法在在线运行的集群上形成持续控制。这家初创公司从一开始就围绕这次聚类点出的主权盲点来设计：ME 和 PSP 状态、危险功能压制，以及政府云环境里工作负载与机柜的准入判定。它真正能积累成资产的，是跨厂商服务器画像、加固检查项、控制映射和审计证据库，把底层固件状态直接连到真实的主权云采购决策上。

待完成任务

flowchart LR
  Buyer[Sovereign cloud operator] --> Pain[Processor blind spot blocks trust proof]
  Pain --> Product[Firmware sovereignty attestation]
  Product --> Outcome[Bid-ready hardware trust evidence]

高管要点

• 欧洲已经以十亿欧元级别为主权云基础设施出资，本地运营商也在打包可信云产品；这让硬件信任证据缺口从“听起来合理”变成了“商业上站得住” [2][13][15][17][18]。
• 最强切口不是再造一个主权云，而是在现有软件栈认证之下补上一层证据，把管理引擎状态翻成采购级证明 [1][7][8][10][20][21]。
• 现有厂商已经证明主权控制和证明有真实需求，但抓到的产品大多聚焦云原生度量、VM 完整性或广义固件风险发现，而不是面向混合机柜、跨厂商的 Intel ME 和 AMD PSP 证据 [5][7][8][9][10][11][12][23][24]。
• 法国和德国是最好的滩头市场，因为 SecNumCloud 类资质和主权公共部门叙事已经清晰可见，给了新厂商明确的买方、伙伴和审计节点 [15][16][17][18]。

市场定义

这个市场处在主权云保障、固件安全和采购证据软件的交叉点上。产品不是通用云工具，也不是 EASM；它是一层控制平面，负责盘点处理器管理引擎状态，把发现映射到主权云要求，再产出买方和审计员在投标与续期里能直接使用的证据 [1][2][5][7][9][14][18][20]。

用户与买方

主要用户，是欧洲主权云运营商或国防相关集成商内部、管理混合 x86 集群的平台安全与保障团队。真正拍预算的，通常是 CISO、首席架构师或资质项目负责人；他们要向公共买方、审计员或部委安全评审方为硬件信任主张负责 [14][16][17][18]。

购买触发点

• 主权云投标、资质里程碑或续期开始索要虚拟机监控器以下的信任边界证据，而现有 BIOS 或 OEM 文档太静态，过不了审。 [1][14][18]
• NIS2 及相关主权承诺把公共部门和关键基础设施买方的网络治理审查抬高了，隐藏的硬件依赖也因此上升为董事会层面问题。 [4][6][16]
• 超大云和本地主权云产品不断抬高买方对“可证明控制”的预期，让 OEM 那种“相信我们”的表述在栈的其他层面可量化证明面前显得更弱。 [5][8][9][17]

支付意愿

只要资质或公共部门收入真会受影响，付费意愿就应该是真实存在的。这个机会靠的不是单纯的安全工具预算，而是投标延误、人工取证和跨集群定制咨询的成本；这些客户本来就已经愿意为主权云投入，并为专业控制买单。 [2][14][15][17][18][23]

品类动态

增长信号 2021-2023 年欧盟企业云采用渗透率年化增幅约 5%

验证信号

• 欧洲运营商已经在直接向公共买方营销数据主权和可信云定位。
• 超大云已经把主权打包成一整套控制，反过来证明市场确实需要更细颗粒度的信任保障。
• 围绕远程证明、DRTM 和管理引擎缓解的开源社区仍很活跃，说明运营商痛点并没有消失。
• 商业固件安全厂商还在持续投入研究和公告，说明这一类目既有预算，也有紧迫度。

监管与技术约束

• 抓到的公开框架里，还没有哪套把 Intel ME 或 AMD PSP 状态标准化成一个明确命名的主权云控制项，所以产品在卖的时候也得顺手教育市场。
• 固件证据质量高度依赖服务器 SKU、BIOS 暴露和主板实现，这会把覆盖和支持风险直接带到每个硬件家族上。
• 混合集群需要统一的证据语义，哪怕 Intel、AMD 和老平台的整改手段并不一样。
• 输出必须同时让采购和审计相关方买单，而不只是安全工程师觉得有道理，这让包装的重要性不亚于检测本身。

竞争格局更多是相邻，而不是正面撞车。超大云把主权控制和证明打包进自家云里；BINARLY 在卖固件和供应链可见性；开源项目提供证明原语；公共部门云运营商则把信任叙事塞进更广的主权产品里。真正稀薄的一层，是专门围绕 Intel ME 和 AMD PSP 状态、服务现有主权机柜的跨厂商采购证据层 [5][7][8][9][10][12][23][24][26][28]。

为什么现有厂商不会默认胜出

• 超大云厂商主权套件. Microsoft 和 Google 能在自己控制的环境里提供强主权控制与证明，但抓到的材料仍然围绕云原生度量和它们自己掌控的平台边界，而不是要向外部审计员证明管理引擎状态的混合本地或托管 x86 集群。
• 固件安全平台. BINARLY 是最接近的商业替代，因为它已经在卖固件与供应链风险可见性；但公开材料里还看不到面向欧盟主权云采购流程、绑定投标与续期动作的 ME/PSP 专项证据包。
• 开源证明栈. Keylime、TrenchBoot 和 me_cleaner 说明技术原语和运营商兴趣都已存在，但这些更像工程团队的搭建件，而不是带控制映射、证据包并支持混合遗留集群的审计员导向产品。
• 标准与基础设施组织. NIST 和 OCP 给了市场描述固件弹性和硬件安全的语言，但它们是框架和社区，不是把底层状态直接翻成主权采购决策的运营产品。

Firmware Sovereignty Attestation 应该先从证据层切入，服务对象是法国和德国正在用现有 x86 集群准备 SecNumCloud 类资质、公共部门投标或国防相关续期的主权云运营商。真正紧迫的痛点，不是泛泛地发现固件风险，而是没法向买方或审计员说明：承载敏感工作负载的具体机柜上，Intel ME 和 AMD PSP 到底能做什么、不能做什么。首个产品应只支持一个很窄的服务器矩阵，验证管理引擎状态和 Serial-over-LAN 之类高风险功能是否暴露，并产出绑定工作负载准入和整改步骤的机柜级证据包。GTM 应从付费的资质就绪试点开始，直接卖给平台保障负责人，并与认可实验室或认证顾问联合交付；一旦这些证据在真实投标、续期或安全评审里被接受，再转成年度覆盖。研究显示，法国和德国这一初始切口对应的建模 TAM 为 $24.0M、SAM 为 $6.0M、3 年 SOM 为 $1.8M，所以它更像一个高价值的合规基础设施切口，而不是 Day 1 就能铺开的软件大类。这里的刻意取舍，是卖采购证据和机柜准入决策，而不是一整套固件安全平台，因为 BINARLY、OEM 文档、开源证明栈和超大云控制已经覆盖了相邻场景。最大的反证风险在于，资质审核方也许会认为 OEM 证明、网络分段或硬件刷新已经够用；那公司就会被困在利基型服务生意里，而不是形成可复制的软件增长。当前输入里还有两个关键空白没补上：没有公开证据显示到底有多少在跑的 RFP 会明确索要虚拟机监控器以下的证明，也还没有证实目标服务器 SKU 的遥测覆盖率。

问题

• 主权云运营商可以把软件、驻留和运维控制都认证清楚，但依然拿不出采购级证据，说明承载敏感工作负载的机柜上 Intel ME 或 AMD PSP 到底处于什么状态。
• 现有替代方案——例如 OEM 白皮书、BIOS 或 TPM 证明、隔离网络以及精品咨询——给到的更多是静态保证，而不是审计员或部委买方能复用的持续性机柜级证明。
• 一旦投标、续期或安全评审追问虚拟机监控器之下是什么，平台保障团队就很难迅速说清哪些服务器可用、哪些需要整改、哪些该被排除。

解决方案

• 从一套窄支持矩阵里的 Intel 和 AMD 服务器家族采集机柜级遥测，对 ME 或 PSP 状态做分类，并标出高风险远程管理功能和不支持的硬件状态。
• 把这些发现映射到主权云控制语言里，产出买方、审计员和认证顾问都能审阅的证据包、例外记录和工作负载准入结论。
• 再叠加整改流程和合作实验室验证，让运营商不必整批换掉服务器，也能把机柜从不支持或高风险状态推进到可投标状态。

为什么我们会赢

• 这个切口比泛化的固件安全更窄，但更值钱：它把底层处理器状态直接连到买方已经愿意付费的结果上，也就是投标准备度和可信工作负载准入。
• 跨厂商的服务器画像数据、证据模板和被接受的例外处理模式，会随着每次部署越积越多；相比之下，云原生现有厂商或服务公司很难在混合主权集群里把这些东西拼齐。
• 首个客户、定价基础和销售渠道都围绕同一个触发点展开：主权云资质或续期要在收入落袋之前，先拿到被接受的证据。

里程碑

flowchart LR
  Wedge[SecNumCloud-style bid or renewal deadline] --> MVP[ME or PSP evidence and rack eligibility MVP]
  MVP --> Proof[Accepted evidence pack and first production expansion]
  Proof --> Expansion[More racks plus adjacent defense and sovereign enclaves]

创始团队

实验路线图

风险评估

必须成立的条件

• 前 10 个合格目标账户里，至少 5 个要明确承认：虚拟机监控器以下的硬件信任问题足以阻断、拖延或显著复杂化主权云投标或续期。
• 前 3 个试点里，产品必须能在不做定制逆向的前提下，对至少 70% 的在范围服务器给出足以进入客户评审的高可信度分类。
• 12 个月内，至少 1 家认可实验室、认证顾问或灯塔客户，必须在真实资质或审计流程里把这套证据包当成有意义的输入。
• 超过一半的试点客户，必须在证据被用于真实评审后，转成年度生产覆盖。
• 早期客户对持续证据覆盖的偏好，必须明显强于一次性咨询或硬件刷新，强到足以支撑六位数年度 ACV。

待尽调问题

• 现在有哪些法国或德国主权云 RFP，已经在要求硬件根信任或虚拟机监控器以下的证据，而不是泛泛的固件保证？
• 哪些目标服务器 SKU 暴露出足够遥测，能区分管理引擎是被禁用、被隔离，还是只是打过补丁？
• 当管理引擎无法彻底关闭时，SecNumCloud 类审查方、公共买家或国防客户到底会接受什么证据材料？
• 买方有多大概率会改选硬件刷新、网络隔离或第三方实验室报告，而不是持续的软件证据？
• 认可实验室和资质顾问能不能变成可复制渠道，还是每次部署最后都会回到定制服务？

模型合理性

• 收入引擎. 基准收入来自 3 个付费试点转生产，并在 Y3 把生产账户做到 4 个、单客户 ACV 约 $450K。
• 必须跑对的事. 至少要有 1 家实验室或顾问足够快地帮公司验证一种证据格式，把销售周期守在 6 个月附近，因为这是对收入最敏感的变量。
• 模型会在哪断. 如果第 4 个账户滑到 Y4、同时毛利率掉向 68%，下行情景下现金低点会压到约 $0.4M，并迫使公司更早融资。
• 下一轮融资证明. 只要公司证明自己有 3 个生产客户、1 条可复制伙伴渠道，并能以更好的 burn efficiency 跑出约 $1.35M-$1.8M 的退出 ARR，就足以支撑 seed 融资。

情景

敏感性

flowchart LR
  Trigger[Qualification deadline] --> Pilot[Paid pilot]
  Pilot --> Conversion[Annual coverage]
  Conversion --> Expansion[More attested servers]
  Expansion --> Revenue[Subscription revenue]
  Revenue --> GrossProfit[75% gross profit]
  GrossProfit --> Opex[Hiring plus partner delivery]
  Opex --> Cash[Ending cash]

警示项: Rule of 40 仍明显低于成熟软件基准，因为市场狭窄，生产部署也还需要较重的客户侧工作。 · 基准情形假设约 15 家滩头运营商里有 4 家会在 3 年内转化或扩张，所以只要 1 个灯塔账户卡住，都会明显拖累 Y3 结果。 · 毛利和现金都高度依赖那条窄支持矩阵能覆盖至少 70% 的目标服务器；如果遥测缺口迫使公司走定制服务，COGS 和 opex 都会很快恶化。

• 技术覆盖缺口. 初创公司未必能在买家现有使用的每一种服务器 SKU 上，都可靠地中和或测量 ME 和 PSP 行为。 缓解措施: 先只支持一小批常见主权云平台，并对已识别、已加固和不支持的硬件状态给出清晰证据分层。
• 审计接受度风险. 政府买方可能不愿用新厂商的硬件证据，来替代现有 OEM 或实验室报告。 缓解措施: 尽早和认可实验室、认证顾问合作，让产品输出成为既有审查流程的输入，而不是孤立的一套新主张。
• 现有厂商的功能跟进. 一旦这个缺口在商业上被看见，服务器 OEM 或大型安全厂商可能迅速补上相近的固件状态能力。 缓解措施: 在跨厂商控制映射、采购工作流集成和证据库上更快堆规模，这些能力现有厂商很难在混合集群里短期拼起来。