1. 定义收购决策
董事会应定义目标改进的客户决策。机器身份公司可能会发现非人类帐户、发布工作负载凭证、代理机密、授权 API 调用、管理云角色、安全部署管道、管理证书、监控服务到服务活动或控制 AI 代理工具。这些活动解决相关风险，同时产生不同的证据、经济和整合义务。
收购论文应指出预期的价值来源：专有政策技术、企业分销、受监管的客户访问、可扩展的信任服务、身份遥测、稀缺工程能力或整合平台。每个来源都需要可重复的测试。发现声明需要人口证据。保单声明需要被拒绝和允许的操作测试。分配索赔需要签订合同采用、保留和收集。
董事会应将收购与合作、许可、少数股权投资和内部发展进行比较。当价值需要对凭证颁发、策略引擎、客户集成和敏感遥测进行协调控制时，所有权可能很重要。当互操作性或通道访问提供大部分好处时，商业安排可能更合适。
证据时机应该决定术语。预签名测试可以在受控环境中重现协议支持、凭证轮换和策略决策。客户特定的覆盖范围和集成经济性可能需要关闭后访问。基本考虑应遵循签署时提供的证据；或有价值应遵循经过验证的里程碑。
拟议的链将已识别的机器参与者与授权的操作、客户结果和收集的现金连接起来。
2. 定义价值单位
建议的价值单位是在客户工作流程中以完全成本交付的经过验证和授权的机器操作。操作可以检索数据、调用 API、部署代码、轮换密钥、批准自动化步骤或委派任务。该记录应标识参与者、工作负载、环境、请求的资源、策略、凭证、决策、响应和责任所有者。
完整成本包括发现、证明、证书颁发、加密操作、策略评估、遥测、存储、第三方许可证、支持、集成、安全操作、事件响应、合规性和营运资金。平台可以报告软件利润，而实施团队可以手动协调身份或客户保留并行工具。获取模型应包括产生所承诺的控制权所需的每项活动。
身份计数是一个不完整的分母。一个已发现的服务帐户如果仍不受管理，可能不会创造任何价值。短暂的证书仍然可能赋予过多的权力。策略决策在技术上可能是正确的，但客户工作流程却忽略了它。因此，买家应衡量经过验证的行动、有效的保单覆盖范围、防止未经授权的行动、调查时间和客户运营成本。
3. 绘制机器身份边界
外围包括云工作负载、容器、虚拟机、无服务器功能、API、服务帐户、证书、设备、CI/CD 作业、机器人、机器人自动化和 AI 代理。每个参与者都有不同的创建事件、所有者、运行时、凭证、特权模式和终止信号。单个库存编号可以掩盖这些差异。
尽职调查团队应该将每个产品模块映射到它可以发现、识别和管理的参与者。应跨云提供商、编排系统、操作系统、开发平台和遗留环境测试覆盖范围。不受支持的人群应该保持可见。
目标应区分身份和凭证。身份代表一个参与者及其属性。凭证证明在规定条件下拥有或控制。多个凭证可能代表一种身份，而一个共享秘密可能会掩盖多个参与者。整合应该减少歧义，而不是将其转移到中央金库中。
| 演员 | 典型凭证 | 所需证据 | 收购警告 |
|---|---|---|---|
| 工作量 | 短期证书或令牌 | 经过证明的运行时和所有者 | 作为工作负载身份呈现的静态凭证 |
| API客户端 | 令牌、密钥或证书 | 客户端、范围和资源绑定 | 具有弱属性的共享密钥 |
| CI/CD 工作 | 联合代币 | 存储库、工作流程和运行上下文 | 可重复使用的部署秘密 |
| 服务帐号 | 平台令牌或秘密 | 所有者、用途和有效期 | 具有持久权限的休眠帐户 |
| AI代理 | 委托代币和策略 | 主体、工具、任务和审批 | 没有行动层面审计的广泛权力 |
| RPA 机器人 | 申请账户 | 流程、操作员和目标系统 | 自动化重复使用的人类凭证 |
每个参与者都需要独特的生命周期和证据模型。
4. 建立身份-行动账本
分类账应该连接发现源、参与者、所有者、工作负载证明、信任域、凭证、策略、资源、操作、决策、异常、客户结果和财务记录。它应该保留允许和拒绝的操作。目的是将产品能力追踪到客户价值。
负面证据属于分类账。孤立的身份、失败的轮换、过时的策略、策略绕过、不可用的遥测和手动覆盖揭示了真正的控制边界。一个仅包含成功示范的数据室无法确定人口覆盖范围。
财务部门应将客户群体与部署的身份、受监管的行动、实施工作、支持成本、更新、扩展和收集联系起来。这使买方能够测试更深入的保单使用是否可以提高保留率和贡献，或者是否创造无价服务工作。
5. 测试发现覆盖范围和所有权
发现应该从独立定义的群体开始。买方应协调云目录、编排平台、证书存储、机密系统、API网关、代码存储库、部署系统和网络遥测。然后应该将目标自己的库存与该人群进行比较。
覆盖范围必须按环境和参与者类型报告。高聚合百分比可以掩盖生产集群或特权部署帐户中较弱的覆盖范围。误报也很重要，因为无法使用的库存会增加补救工作并削弱客户信任。
所有权证据应确定负责的团队、批准的目的、数据访问和终止触发器。机器身份通常比创建它们的应用程序或员工更长久。当所有权变得不清楚时，产品应支持重新证明和升级。
人口建设需要精心呵护。云控制平面、应用程序日志和源存储库在不同时间观察资产的不同部分。买方应定义一个测量窗口，删除重复的稳定标识符并保留每个发现的来源。短暂的工作负载可能只会短暂出现，而休眠的特权帐户可能不会产生流量。完全依赖于活动的发现引擎可能会错过危险的非活动凭据；仅目录引擎可以报告不再到达资源的身份。
买方应进行种子测试。可以在具有已知所有者、特权、凭证形式和生命周期的代表性平台上创建经批准的测试身份。然后，尽职调查团队可以衡量检测、分类、所有权分配和补救措施。种子身份应包括不明确和对抗性的情况，例如复制名称、共享标签和误导性元数据。结果应该在没有卖家干预的情况下重现。
补救措施的证据不应只是一张罚单。记录应显示身份是否被禁用、重新调整范围、轮换、分配或接受为例外；应用程序是否继续运行；以及这种变化是否持续存在。重新出现的身份可能表明自动重新创建、不完整的基础设施即代码更改或断开的源系统。持久的补救措施比大量已结束的调查结果更有价值。
覆盖范围声明也需要时间测试。一次性扫描可以产生有吸引力的基线，同时错过日常创建和删除。买方应衡量从身份创建到发现、所有者通知、保单附加和解决的时间。尾部延迟可以揭示平均值掩盖的覆盖差距。这种操作节奏会影响客户利益、支持负载和更新。
值是方法演示的管理假设。
6. 测试身份发布和证明
仅当有证据将正在运行的工作负载连接到批准的环境和所有者后，才应发布工作负载身份。 SPIFFE 定义工作负载身份和可验证的身份文件；其工作负载 API 提供身份，无需应用程序直接处理身份验证机密。[4][9]
买方应检查节点、工作负载和流程证明。测试应尝试从未经授权的节点、更改的图像、复制的配置和相邻的工作负载获取身份。系统应记录所使用的证据、签发人、有效期和撤销路径。
证明依赖关系属于评估模型。云元数据、编排控制、硬件根、证书颁发机构和第三方服务可能会造成集中或可移植性风险。目标应显示回退、迁移和事件程序。
7. 认证与授权分离
身份验证确定哪个参与者提供凭证。授权确定该参与者在当前条件下是否可以对特定资源执行特定操作。对每个工作负载进行身份验证的平台仍然可能允许过多或意外的活动。
策略深度应通过资源、操作、数据和上下文控制从网络或角色级访问来衡量。有用的上下文可以包括工作负载状态、环境、时间、风险、数据分类、请求的工具和人工批准。产品应该解释哪些属性是权威的以及如何解决冲突。
买方应该在变化的环境和失败的情况下测试政策决策。当策略服务、属性源或审计系统不可用时，它应该检查默认行为。通过宽容回退实现的可用性可以将操作弹性转化为安全暴露。
| 等级 | 控制范围 | 证据 | 价值限制 |
|---|---|---|---|
| 1 | 仅限库存 | 发现演员 | 没有强制执行 |
| 2 | 凭证控制 | 发行和轮换 | 权力可能仍然广泛 |
| 3 | 资源访问 | 允许或拒绝记录 | 有限的行动背景 |
| 4 | 行动和数据 | 方法、对象和范围 | 集成复杂度 |
| 5 | 上下文委托 | 任务、风险和批准 | 治理和延迟负担 |
估值应遵循有效的控制和证据，而不是政策计数。
8. 测量凭证半衰期
短期凭证会缩短复制凭证的有用期限。 Kubernetes 建议使用有约束力、有时间限制的服务帐户令牌，并建议不要使用长期存在的令牌机密。 OAuth 所有权证明机制可以将令牌绑定到客户端证书或密钥。[6][10][11]
买方应测量中位数和尾部有效期、轮换成功、紧急撤销和剩余静态秘密。它应该测试应用程序是否安全地刷新凭据以及撤销是否到达分布式执行点。
凭证期限应反映操作恢复情况。如果中断导致团队安装持久的紧急机密，那么极短的有效期几乎没有什么好处。相关措施是发行、妥协、轮换、撤销和异常处理后的有效暴露。
曲线说明了不同有效性和撤销设计下的相对暴露；价值观是管理假设。
9. 测试跨信任域的联合
联合允许在一个信任域中建立的身份在另一个信任域中根据策略被接受。 SPIFFE 联盟交换信任捆绑并将其绑定到信任域。 OAuth 令牌交换支持获取不同服务或安全域的令牌。[5][7]
买方应测试信任建立、捆绑分发、发行者限制、受众绑定、声明映射和撤销。跨域访问应该需要明确的策略。悄然扩大信任的配置变化可能会造成系统性风险。
商业价值取决于互操作性。客户运营多个云、集群、软件供应商和收购的资产。专有联盟会增加转换成本，同时限制采用。标准支持可以扩大分布；实施质量、治理和客户工作流程仍然决定着差异化。
10.评估API身份和代币交换
API 访问应绑定客户端、令牌、受众、范围、资源和操作。 OAuth 标准支持服务器元数据、受保护资源元数据、令牌内省、撤销和令牌交换。相互 TLS 和 DPoP 可以通过证明拥有绑定密钥来减少不记名令牌重放。[7][10][11][12][13][14]
尽职调查团队应该针对非预期资源重放令牌，改变受众和范围，测试过期和撤销的令牌，并检查内省或元数据不可用时的行为。日志应该允许客户重建决策。
API-单独的密钥管理不应被视为全面的机器身份。买方应确定产品如何在不中断生产系统的情况下将客户从共享密钥转移到可归因的、有时间限制的和受策略约束的访问。
11. 治理AI-代理身份和授权
AI 代理可以选择工具并排序操作以响应数据。 NIST 2026 年关于软件和 AI 代理身份的概念文件询问代理应如何识别、授权、审计并与人类权威联系起来。[15] 收购论文应将代理人身份视为企业控制的延伸，并具有额外的授权和不可预测的风险。
每个代理操作都应连接到所属组织、批准的代理版本、发起主体、任务、允许的工具、资源范围、时间窗口和升级规则。随着工作在代理人之间的传递，授权的范围应该缩小。接收服务不应假设代理可以行使其人类赞助商所拥有的所有特权。
提示内容不应成为未经验证的权威来源。应根据经过身份验证的上下文在模型外部评估策略。后果严重的行动可能需要确定性检查、双重控制或人工批准。审计跟踪应保留输入、工具调用、政策决策和结果，同时尊重隐私和数据最小化要求。
代理身份也会改变会话持续时间的含义。传统服务可以重复执行狭窄的功能，而代理可以在一系列规划、检索、生成和执行步骤中保持活动状态。买方应测试是否在每个敏感步骤、任务发生变化以及代理收到新数据时重新评估权限。会话开始时的单一批准不应默默地授权不相关的后续交易。授权记录应显示可用的最大权限、实际使用的权限以及每次提升的原因。
模型和工具版本属于身份记录。为一种工具界面或模型行为批准的策略在更新后可能不再适用。发布治理应该连接已部署的模型、提示包、工具架构、策略包和评估结果。目标应演示回滚、退役和剩余访问测试。这些控制允许买家将实验性代理包装器与支持规范采用的企业控制平面区分开来。
| 测试 | 预期控制 | 证据 |
|---|---|---|
| 工具替代 | 未经批准的工具被拒绝 | 政策决策与预警 |
| 范围扩展 | 更广泛的资源被拒绝 | 受众和范围记录 |
| 代理移交 | 权威缩小 | 委托链 |
| 及时注射 | 指令无法授予特权 | 外部政策结果 |
| 高价值行动 | 需要批准 | 审批人和交易记录 |
| 经纪人退休 | 凭证和访问端 | 撤销和剩余访问测试 |
每个测试都将权限与可追踪的业务任务联系起来。
12. 测试可观察性和不可否认性
产品应生成足以回答谁的行为、以何种身份、以何种权限、针对何种资源以及产生何种结果的记录。日志应包括策略和凭证版本，以便稍后审查可以重现决策。
完整性和访问控制很重要，因为机器身份遥测可能会暴露架构和秘密。买方应检查收集间隙、时钟同步、保留、导出、签名、客户所有权和事件保存。精美的仪表板无法弥补源证据的缺失。
运营指标应包括策略延迟、拒绝操作率、异常期限、凭证故障、孤立身份和调查时间。措施应根据客户群体和环境进行细分。
13.审查密钥、机密和证书管理
NIST 密钥管理指南涉及政策、程序、规划和加密密钥管理系统。[16][17] 机器身份平台应该定义每个凭证类别的生成、存储、分发、轮换、撤销、备份、恢复和销毁。
买方应映射保管权和管理员访问权限。它应该检查硬件安全模块的使用、证书颁发机构的层次结构、紧急访问、出口管制和职责分离。客户管理和供应商管理的模型创建了不同的负债和毛利率概况。
秘密迁移是一个主要的集成风险。获取保管库或证书产品不会自动创建统一身份。该计划应保持服务连续性，同时减少重复的凭证存储和特权。
14. 评估产品架构和依赖性
该架构应将控制平面、数据平面和证据平面分开。策略管理可以是核心，而执行则与工作负载密切相关。如果缓存的策略和故障模式受到控制，这种设计可以减少延迟并在控制平面中断期间维持操作。
买方应清点开源组件、云服务、协议库、证书颁发机构、数据库和可观察性依赖项。许可权利、维护状态和更换成本属于勤勉。
可扩展性测试应反映峰值身份验证和策略流量、租户隔离、证书轮换事件和事件条件。平均请求量可以掩盖广泛到期或紧急撤销期间的操作故障。
控制平面应维护权威的配置、批准和策略历史记录。分布式执行点应该接收签名的、版本化的策略并公开其应用状态。证据平面应记录足够的信息来协调决策，而不存储不必要的秘密或客户数据。买家应在网络分区、更新延迟、回滚等情况发生时测试一致性。
多租户架构需要显式隔离策略、身份命名空间、信任捆绑、遥测和管理员访问。测试应尝试跨租户引用、标识符冲突、策略导入和支持访问误用。客户控制的加密或专用部署选项可以改善受监管的市场准入，同时增加成本和发布复杂性。这些经济学应该通过群体可见。
数据驻留会影响架构和交易价值。身份遥测可能会揭示服务名称、路线、权限和操作模式。买方应按管辖范围映射收集、处理、支持访问、备份和灾难恢复。合同承诺应与实际路由和子处理者相匹配。任何计划的区域系统整合都应在协同作用得到认可之前进行成本计算和审查。
收购团队应该检查开发人员的经验，因为采用取决于集成质量。软件开发套件、命令行工具、策略测试、本地开发、迁移帮助程序和错误消息可以决定价值实现时间。文档应区分安全默认值和可选控件。需要大量定制工程的产品可能仍然可以为有价值的客户服务，但其贡献和可扩展性应该相应地建模。
发布工程是控制的一部分。协议库、策略评估、证书处理和代理的更改可能会影响每个客户。目标应显示代码审查、依赖性监控、签名构建、分阶段部署、兼容性测试和紧急回滚。 NIST 的安全软件开发框架为检查这些实践提供了有用的参考。[36]
该设计将发现、信任、策略、执行和证据分开，同时保留客户控制点。
15. 测试安全性和抗滥用性
目标本身就是特权基础设施。妥协可以发布可信凭证、改变政策或压制证据。买方应执行与风险相称的架构审查、代码审查、渗透测试、构建管道审查和特权访问分析。
威胁场景应包括发行者泄露、签名密钥被盗、恶意管理员、租户逃逸、策略篡改、元数据欺骗、令牌重放、依赖关系泄露和拒绝服务。每个场景都需要预防、检测、遏制和恢复证据。
卖方的事件历史记录应在票务、安全监控、客户通知、保险公司和监管机构之间进行协调。没有报告事件并不等于没有妥协。
16. Diligence 客户群体及分布
企业发行可以成为累积价值的主要来源。买方应按行业、环境、参与者群体、部署的模块、策略深度、合同期限、实施模型、支持负担、续订和收款对客户进行细分。
签署的合同应与部署证据保持一致。货架和有限试点不应获得与强制生产政策相同的估值。使用情况应显示相关环境中持续的受监管行为。
渠道合作伙伴关系需要来源渠道、转化、经济性和客户控制的证据。云市场列表或技术集成可以支持分发；它本身并不建立客户需求。
买方应重建从签署订单到发现、第一凭证、第一执行政策、生产覆盖范围和稳态使用的实施漏斗。即使合同收入看起来很强劲，这些阶段之间的延误也会消耗现金并增加客户流失率。群组分析应报告首次控制的时间、目标覆盖的时间、实施时间以及启动后仍然存在的例外情况。
扩展应分为价格、身份数量、附加环境和更深入的策略采用。数量增长可以反映基础设施的增长，而无需提高安全价值。更深入的采用可能会增加转换成本和客户成果，但可能需要更多的工程和支持。因此，净留存率应与贡献和政策深度一起解读。
分销权和客户同意会影响汇总集成。合同可能会限制控制权变更后的数据传输、分包、托管或分配变更。客户遥测还可以包含敏感的架构信息。在假设身份和策略可以转移到通用平台之前，法律、产品和商业团队应确定同意、本地化职责和客户控制的加密。
| 队列 | 部署证据 | 经济测试 | 主要风险 |
|---|---|---|---|
| 监管企业 | 生产政策和出口审核 | 保留经常性捐款 | 实施周期长 |
| 云原生扩展 | 工作量和API覆盖范围 | 扩展和支持效率 | 供应商整合 |
| 基础设施运营商 | 弹性执法 | 合同期限和收款 | 经营责任 |
| AI-代理采用者 | 行动级授权 | 有偿生产使用 | 治理不成熟 |
| 渠道主导型客户 | 合作伙伴提供的部署 | 净收入和控制 | 对中介的依赖 |
应根据采用率、贡献和持久性对群组进行评估。
17. 重建完整的交付经济学
收入应通过发票和银行收据与合同进行核对。买方应将订阅、消费、实施、托管服务和第三方传递分开。报告的年度经常性收入应排除非经常性和无支持的金额。
成本应包括云处理、证书和密钥服务、遥测存储、支持、客户工程、策略设计、事件响应和合作伙伴共享。客户贡献应在维持有效控制所需的支持之后计算。
当大客户付款缓慢而目标公司为基础设施和实施提供资金时，营运资金很重要。收购模型应将增长、部署、计费、收款和现金联系起来。
买方应根据源记录重建毛利率，而不是仅仅依赖财务报表分类。分配给客户配置、定期策略维护或事件支持的工程劳动力可能属于研发，同时充当服务成本。合作伙伴积分和承诺的云折扣可以暂时提高报告的利润率。正常化应该保留实现当前承诺所需的成本。
单位经济学应该利用客户群和活动驱动因素。有用的分母包括生产环境、受监管的操作、执行点、遥测量和支持时间。当身份的活动和后果差异很大时，每个身份的成本可能会产生误导。团队应该确定哪个驱动因素可以解释边际基础设施和人力。
定价应根据客户价值和成本波动进行测试。按身份定价很简单，但可能会阻碍全面发现。按操作定价可以与使用情况保持一致，但会让客户面临不确定的账单。企业订阅可以支持广泛采用，同时将批量风险转移给供应商。应分析合同的最低承诺、超额、指数化、服务信用、终止权和收购后价格变化的限制。
保留分析应区分徽标保留、经常性收入保留和保留贡献。客户可以扩大报告的收入，同时支持和基础设施成本上升得更快。估值案例应使用最能将持续客户价值与现金联系起来的衡量标准。收款、争议和积分应与同一队列记录进行核对。
销售效率需要全周期的视角。受监管的客户可能需要安全审查、概念验证、采购、法律谈判和分阶段部署。买方应衡量现金获取成本、销售周期持续时间、实施能力以及从初始支出到收集捐款的回报。管道应根据完整的客户证据而不是卖方阶段标签来加权。
18. 建立一个假设的收购案例
假设目标为 USD 18.0 million 经常性收入、USD 3.0 million 实施收入和 USD 1.0 million 其他收入。管理层估计 USD 12.2 million 在直接交付和支持后保留了经常性捐款。最大的 10 位客户占经常性收入的 44%。这些数字是假设的。
证据审查将保留的经常性贡献的 USD 7.0 million 归因于使用生产策略实施的客户，将 USD 3.2 million 归因于使用凭证和发现模块的客户，并将 USD 2.0 million 归因于试点或有限部署。买方为每一层分配不同的置信度和集成要求。
管理层确定了潜在年度交叉销售贡献的 USD 2.4 million 和重复成本的 USD 1.6 million。在客户接受和实施证据存在之前，基本评估不包括这两者。或有对价可以承认已实现的交叉销售，而无需在签署时利用未经证实的计划。
| 层 | 保留贡献 | 证据状态 | 估值处理 |
|---|---|---|---|
| 生产政策客户 | 7.0 | 部署和更新 | 基本情况需保留 |
| 凭证和发现客户 | 3.2 | 有限政策部署 | 移民调整后的 |
| 试点和有限部署 | 2.0 | 不完全采用 | 或有或期权价值 |
| 潜在的交叉销售 | 2.4 | 管理计划 | 排除在基本价格之外 |
| 重复成本机会 | 1.6 | 整合估计 | 交货后认可 |
所有金额均为管理层假设，单位为 USD 百万。
19.强调运营模式
压力测试应该结合技术和商业事件。相关案例包括凭证服务中断、发行人泄露、云平台变更、客户流失、部署速度减慢、支持成本更高和交叉销售延迟。相关事件值得特别关注，因为安全事件可能会增加成本，同时减少更新。
买方应该对流动性和收益进行建模。紧急轮换、客户补救、法证工作和保险免赔额可能需要现金才能恢复收入。在这些条件下，契约和收益指标应该仍然可行。
应力设计应从因果关系开始。发行人的妥协可能会引发紧急证书更换、客户停机、服务积分、调查成本、延迟销售和客户流失。将每个效应视为独立的可能会低估组合事件。该模型应具体说明时间安排、现金支付、保险赔偿假设和管理层应对措施。保险应仅在保单条款和索赔分析支持的范围内予以认可。
平台依赖性压力应检查云身份服务、编排 API、证书生命周期以及浏览器或运行时信任存储的更改。目标应显示其适应速度、哪些客户需要手动干预以及是否仍支持旧版本。当第三方变更增加交付成本时，合同服务义务可以继续。
客户集中度压力应包括运营集中度。多个客户可能共享相同的云、渠道合作伙伴或实施架构，从而创建相关的曝光。因此，通过标志实现收入多元化可能会夸大弹性。买方应按客户、平台、地区、合作伙伴、发行机构和产品模块绘制集中度图。
管理层的应对措施应该是可行的且有顺序的。降低成本可以保护流动性，同时减缓修复和产品迁移。价格上涨可以支撑利润率，同时削弱续订能力。董事会应审查核心、不利和严重的案例，并明确触发流动性保存、客户沟通、额外的安全能力和契约参与。
压力包应说明哪些假设是合同假设、观察假设、管理层估计假设或仅限情景假设。应保留每项材料输入的来源、所有者和批准日期。结账后的结果应每月与原始案例进行比较，以便管理层能够确定差异是否源于客户行为、技术性能、集成执行或财务假设。这一原则还改善了或有考虑、减值审查和下一次收购的可用证据。
独立质疑应重点关注推动流动性、客户伤害和不可逆转的平台决策的假设，并将未解决的问题直接报告给交易委员会。
所有值均为管理假设，单位为 USD 百万。
20.重视证据层
估值应从由合同、部署和现金支持的保留经常性捐款开始。买方可以根据增长、保留、集中度、安全风险、交付经济性和资本需求应用所需的回报或倍数。总体市场倍数不应取代公司特定的证据。
该桥梁应将合同生产价值、依赖移民的价值、或有采用、整合协同效应和战略选择分开。每一层都应该有一个所有者、里程碑、成本和不利情况。这阻止了在卖方预测和买方协同案例中出现相同的收益。
IFRS 3、IAS 38 和 IFRS 13 下的购买价格分配可以将客户关系、技术、品牌和其他资产与商誉分开识别。 IAS 36 下的减值评估取决于适用的会计事实和建议。[18][19][20][21]
估值模型应该使证据的过期时间可见。客户贡献可能会在更新时减弱，技术证据可能会在平台更改后衰减，并且集成假设可能会在迁移开始时失败。每个材料层都应该有一个审查日期和一个负面反应。当标准、云平台或客户架构发生变化时，基于当前身份增长的静态终端价值可能会夸大耐久性。
战略选择价值应单独表述。已安装的策略引擎可能支持未来的代理治理，但买方应在附加价值之前确定附加产品、监管、销售和资本要求。期权可以证明交易路线或有限投资的合理性，同时保持在当前现金流支持的价格之外。
可比公司的证据应针对收入定义、服务内容、增长、保留、集中度、股票薪酬和现金消耗进行标准化。在不同利率、网络安全或资本市场条件下完成的交易需要进一步调整。估值委员会应保留从可观察的市场证据到公司特定结论的可追溯桥梁。
| 成分 | 证据基础 | 假设价值 百万美元 |
|---|---|---|
| 合同产量贡献 | 部署、更新和收集 | 72.0 |
| 依赖迁移的贡献 | 凭证和发现客户 | 18.0 |
| 收养选择 | 飞行员和代理用例 | 6.0 |
| 交付后成本协同 | 已验证的集成里程碑 | 8.0 |
| 安全和集中储备 | 下行调整 | -14.0 |
| 说明企业价值 | 证据层总和 | 90.0 |
金额和估值因素是方法论证的管理层假设。
数值是管理层假设，单位为 USD 百万，并不代表市场基准。
21.结构考虑和整合
基本对价应反映复制技术、可转让权利、合同捐款和现金。推迟或或有考虑可以解决客户迁移、策略采用、关键人员保留和安全修复等问题。衡量标准应该是客观的、可控的并且能够抵抗会计政策的变化。
陈述和保证应涉及知识产权、开源使用、安全事件、凭证保管、客户承诺、数据权利和合规性。如果已确定的风险在交割前无法得到解决，则根据法律建议，特定赔偿或托管可能是适当的。
整合应保持执法的连续性。在测试身份映射、策略等效性、回滚和客户批准之前，买方应避免强制迁移。产品合理化应该遵循证据，而不是假设的单一平台最终状态。
| 门 | 证据 | 交易响应 |
|---|---|---|
| 技术 | 复制身份和政策测试 | 支持基础值 |
| 权利 | 可转让的代码、数据和许可证 | 关闭条件或补救措施 |
| 顾客 | 留存产量贡献 | 延期考虑 |
| 安全 | 钥匙保管和事件审查 | 托管、赔偿或条件 |
| 迁移 | 策略对等和回滚 | 分阶段整合 |
| 协同作用 | 收取交叉销售和交付成本 | 实现后的或有价值 |
该结构将支付和迁移与可观察的证据联系起来。
22.执行180天计划
第 0 至 30 天应建立控制。买方应确认特权访问、发行者和密钥保管、事件响应、客户升级、身份清单和集成决策权。它应该冻结高风险的架构更改，直到保留证据。
第 31 到 60 天应该重现发现、发行、轮换、策略、联合和代理委托测试。财务部门应按群体调节收入、贡献和收款。法律和技术团队应确认权利和关键依赖性。
第 61 天到第 100 天应该定义产品和分销架构。团队应该映射等效的策略、信任域、遥测、客户合同和支持义务。试点迁移应包括回滚和客户接受。
第 101 天到第 180 天应该扩展经过验证的迁移、启动批准的交叉销售、消除重复的控制并根据签署的基线报告收益。董事会应每月收到一份涵盖安全、客户、经济、整合和现金的证据包。
23. 决定和结论
当平台能够识别参与者、绑定短期凭证、执行操作级权限、联合信任并保存客户运营内部的证据时，机器身份就会创造获取价值。库存量和协议索赔是起点。
成功的汇总需要明确的信任架构。在不协调发行人、政策、客户所有权和执行情况下组合产品可能会增加复杂性和系统性风险。整合应该通过复制等价和受控迁移来进行。
拟议的框架将技术控制与客户成果和保留贡献联系起来。它对经过验证的生产价值进行定价，将迁移和采用视为依赖证据的层，保护考虑并为管理层提供 180 天的执行顺序。
委员会的批准文件应包含一组简短的可审计条件：测试发现的人群；复制的证书和政策；客户捐款与现金核对；已确认的权利和依赖性；接受的安全例外；以及管理支付和集成的里程碑。这些条件将广泛的战略叙述转化为管理层可以监控的交易。
机器身份可能会跨越多个现有的安全预算，包括秘密、证书、云权限、API访问、开发人员安全和代理治理。当汇总减少重复控制并产生一致的证据链时，可以创造客户价值。当整合消除本地上下文、添加特权中央依赖或在证明等效性之前强制迁移时，它可能会破坏价值。提议的门顺序保留了客户操作，同时允许买方通过完整的证据获得平台结果。
管理层应在初始整合期后继续衡量收购。更新、政策深度、例外年龄、凭证曝光、事件响应、捐款和现金应按群体保持联系。这一持续记录支持产品决策、减值审查、额外收购和最终退出调查。
来源
- 美国国家标准技术研究院。零信任架构，SP 800-207. 2020. 阅读主要来源
- 美国国家标准技术研究院。用于云原生应用程序中的访问控制的零信任架构模型，SP 800-207A。 2023 年。 阅读主要来源
- 美国国家标准技术研究院。实施零信任架构，SP 1800-35. 2025. 阅读主要来源
- 斯皮夫。 SPIFFE 规格。 2026 年。 阅读主要来源
- 斯皮夫。 SPIFFE 联合会。 2026 年。 阅读主要来源
- 库伯内斯。服务帐户。 2026 年。 阅读主要来源
- 互联网工程任务组。 OAuth 2.0 令牌交换，RFC 8693. 2020. 阅读主要来源
- 美国国家标准技术研究院。基于微服务的应用系统的安全策略，SP 800-204. 2019. 阅读主要来源
- 斯皮夫。工作负载API。 2026 年。 阅读主要来源
- 互联网工程任务组。 OAuth 2.0 相互 TLS 客户端身份验证和证书绑定访问令牌，RFC 8705. 2020. 阅读主要来源
- 互联网工程任务组。 OAuth 2.0 演示所有权证明，RFC 9449. 2023. 阅读主要来源
- 互联网工程任务组。 OAuth 2.0 授权服务器元数据，RFC 8414. 2018. 阅读主要来源
- 互联网工程任务组。 OAuth 2.0 令牌自省，RFC 7662. 2015. 阅读主要来源
- 互联网工程任务组。 OAuth 2.0 令牌撤销，RFC 7009. 2013. 阅读主要来源
- NIST NCCoE。加速软件和 AI 代理身份和授权的采用。 2026 年。 阅读主要来源
- 美国国家标准技术研究院。密钥管理建议，SP 800-57 第 1 部分修订版 5. 2020. 阅读主要来源
- 美国国家标准技术研究院。加密密钥管理系统设计框架，SP 800-130. 2013. 阅读主要来源
- 国际财务报告准则基金会。 IFRS 3 企业合并。 2026 年。 阅读主要来源
- 国际财务报告准则基金会。 IAS 38 无形资产。 2026 年。 阅读主要来源
- 国际财务报告准则基金会。 IFRS 13 公允价值计量。 2026 年。 阅读主要来源
- 国际财务报告准则基金会。 IAS 36 资产减值。 2026 年。 阅读主要来源
- 美国国家标准技术研究院。使用服务网格架构构建安全的基于微服务的应用程序，SP 800-204A。 2020. 阅读主要来源
- 美国国家标准技术研究院。使用服务网格 SP 800-204C 为基于微服务的应用程序实施 DevSecOps。 2022 年。 阅读主要来源
- CISA。零信任成熟度模型版本 2.0. 2023. 阅读主要来源
- 互联网工程任务组。 JSON Web 令牌、RFC 7519. 2015. 阅读主要来源
- 互联网工程任务组。 OAuth 2.0 客户端身份验证和授权授予的 JSON Web 令牌配置文件，RFC 7523. 2015. 阅读主要来源
- 互联网工程任务组。 OAuth 2.0 安全性的最佳当前实践，RFC 9700. 2025. 阅读主要来源
- 互联网工程任务组。 OAuth 2.0 受保护的资源元数据，RFC 9728. 2025. 阅读主要来源
- 库伯内斯。管理服务帐户。 2026 年。 阅读主要来源
- 谷歌云。工作负载身份联合。 2026 年。 阅读主要来源
- 亚马逊网络服务。随时随地的 IAM 角色。 2026 年。 阅读主要来源
- 亚马逊网络服务。 EKS Pod 身份。 2026 年。 阅读主要来源
- 微软。工作负载身份联合。 2026 年。 阅读主要来源
- GitHub。 OpenID 连接。 2026 年。 阅读主要来源
- 桥公司保险库文档。 2026 年。 阅读主要来源
- 美国国家标准技术研究院。安全软件开发框架，SP 800-218. 2022. 阅读主要来源
- 美国国家标准技术研究院。网络安全框架 2.0. 2024. 阅读主要来源
- 美国国家标准技术研究院。数字身份指南，SP 800-63-4. 2025. 阅读主要来源
- OWASP。非人类身份顶部 10. 2025. 阅读主要来源
- 云原生计算基金会。 SPIFFE项目。 2026 年。 阅读主要来源
- 云原生计算基金会。尖顶项目。 2026 年。 阅读主要来源
- 米特雷。 ATT&CK 有效帐户。 2026 年。 阅读主要来源
- 米特雷。 ATT&CK 不安全凭证。 2026 年。 阅读主要来源
- 欧洲联盟。关于高通用网络安全水平措施的指令 (EU) 2022/2555。 2022 年。 阅读主要来源
- 欧洲联盟。 (EU) 2024/1689 法规制定了人工智能的统一规则。 2024 年。 阅读主要来源
- 美国证券交易委员会。网络安全风险管理、战略、治理和事件披露。 2023 年。 阅读主要来源
- 国际标准化组织。 ISO/IEC 27001 信息安全管理体系。 2022 年。 阅读主要来源
- 国际标准化组织。 ISO/IEC 27002 信息安全控制。 2022 年。 阅读主要来源
- 国际标准化组织。 ISO/IEC 42001 人工智能管理系统。 2023 年。 阅读主要来源
- 国际评估标准理事会。国际估值标准。 2025 年。 阅读主要来源
