E26/E27 网络韧性合规白皮书

三层合规架构：从 IMO 到船级社，再到旗国执行

要理解 E26/E27 的约束力，必须先厘清它所处的监管架构。这套架构共有三层，自上而下逐层加密，各层之间既分工明确又相互依托。

第一层是国际海事组织（IMO）的基础要求。2017 年 6 月，IMO 第 98 届海事安全委员会（MSC 98）通过了 MSC.428(98) 决议，明确要求将网络风险纳入安全管理体系（SMS）——这是《国际船舶安全营运和防止污染管理规则》（ISM Code）的一部分。该决议并非技术规范，而是一项管理原则性要求：经营人须在安全管理体系中识别、评估并管控网络风险。截止时点为 2021 年 1 月 1 日之后首次符合条件的公司符合性文件（DoC）年度审核——自此，任何 ISM 审核都须验证 SMS 中已包含网络风险管理内容。这一要求面向全球所有适用 ISM 的现役船舶，范围极广，但缺乏可操作的技术基线：它告诉经营人要做什么，却没有说怎么做。

第二层是船级社联合会（IACS）的统一技术要求。正因为 IMO 没有提供技术细节，业界迫切需要一套可验证、可审核的技术标准。IACS 于 2022 年 4 月发布了 UR E26（整船网络韧性）和 UR E27（船载系统与设备网络韧性）。然而这两个原始版本在计划于 2024 年 1 月 1 日生效之前就被正式撤回，由修订版 Rev.1 取而代之——E27 Rev.1 于 2023 年 9 月发布，E26 Rev.1 于 2023 年 11 月发布，统一于 2024 年 7 月 1 日强制生效。这一"撤回重发"事件在 IACS 历史上并不常见，折射出业界在原版本技术规定上的强烈反馈，以及 IACS 为提升规则可执行性所作的重大修订努力。E26/E27 将 IMO 的原则性要求转化为具体的技术能力清单、文件提交程序和审核见证机制，形成了可供船级社逐项核查的合规依据。

第三层是旗国政府与港口国监督（PSC）的落地执法。IACS 的统一要求通过各成员船级社的具体规则落地，获得船级社认可的船舶同时满足了旗国对于新造船的技术标准要求，PSC 则在世界各地的港口对船舶实施检查。不符合 E26/E27 要求的适用新造船，在理论上将无法获得或维持船级证书，进而无法取得贸易资质——这是比罚款更具实质威慑力的后果。需要特别说明的是：E26/E27 仅适用于 2024 年 7 月 1 日及以后签订建造合同的新造船；在此之前建造的现役船舶仍仅受 IMO MSC.428/ISM 体系约束，二者形成了一个"双轨合规"格局，对于管理混龄船队的船东而言，需要分别评估不同船舶的合规状态。

E26 管整船、E27 管船载系统与设备——一条船的 E26 合规，建立在船上各 CBS 分别满足 E27 之上。两者对 2024 年 7 月 1 日及以后签订建造合同的新造船强制适用。

它是怎么一步步变强制的

从 IMO 把网络风险写进安全管理体系，到 IACS 出台技术统一要求，中间还有一次「撤回重发」：2022 年 4 月的原版本计划 2024 年 1 月生效，但在生效前被撤回，由 Rev.1（E27 2023 年 9 月、E26 2023 年 11 月）取代，统一改为 2024 年 7 月 1 日生效。

撤回重发：一次罕见的规则修订事件

2022 年 4 月原版 E26/E27 发布后，来自设备制造商、船厂和船东的行业反馈揭示了若干可执行性问题：技术能力要求的界定方式、文件提交的范围与格式，以及 FAT 见证机制的操作边界，都需要更清晰的规定。IACS 在原版本生效前就将其正式撤回（IACS 官网将其标注为「UR E26 New — Withdrawn」），经过系统性修订后，于 2023 年 9 月（E27 Rev.1）和 2023 年 11 月（E26 Rev.1）分别发布修订版，并将统一生效日期推迟至 2024 年 7 月 1 日，给行业额外提供了约六个月的准备窗口。

这一过程有两个关键含义：第一，任何引用原 2022 年版本的合同或技术规格书，均需核查其法律效力——原版本已无约束力，唯有 Rev.1 有效；第二，原定生效日 2024 年 1 月 1 日对应的版本已从未实际生效，这意味着 2024 年初建造合同的技术标准参照须以船级社具体实践为准。与此同时，据 DNV 报告，在 2024 年 7 月强制日期到来之前，已有约 200 艘船舶自愿申请了 DNV「Cyber Secure」船级符号（涵盖各等级），显示出市场已充分预热，早期采纳者在强制合规框架落地前便已积累了实践经验。

两条送审路径

送审是按具体船舶做的，最终拿到「系统证书」（System certificate）。设备有没有型式认可，决定走哪条路：

型式认可路径与逐船送审路径：一个战略选择

上图中的「路径 A / 路径 B」是业内常见的简化表达，并非 IACS 官方术语。官方机制的准确表述是：设备商可通过获得型式认可证书（Type Approval Certificate，TAC）来预先证明 CBS 满足 E27 要求，也可在每艘具体船舶的计划审批环节按逐船方式提交完整文件。两条路径最终都导向同一个结果——系统证书（System certificate），区别在于为到达那个结果所需承担的前期投入与每船边际成本的不同分配。

对于设备制造商而言，这是整个 E27 合规体系中最具策略意义的决策点。型式认可路径要求供应商在初始阶段完成一次完整的全流程验证：向船级社提交包含所有 41 项安全能力合规映射的完整文件包、接受工厂审核，并由船级社审查员见证一次 Cyber FAT。一旦获得 TAC，在 TAC 有效期（据 ABS 的记录约为 5 年，但各船级社实践有所不同，须以相关船级社规定为准）内，每艘后续订单船舶只需提交简化文件，无需再次安排 FAT 见证。对于在多个船厂有批量订单、产品结构相对标准化的供应商——例如推进控制系统、综合导航系统、船舶自动化平台——型式认可路径的经济性随订单数量的增加而快速改善。

逐船送审路径（即无型式认可）不要求任何前期认证投入，每艘船单独提交完整文件，但每次交付都需要船级社审查员亲临工厂或船厂现场见证 Cyber FAT。这对于专为某个项目定制、几乎不存在重复交付场景的 CBS（例如特定工程船的专有操控系统）是合理选择。然而，对于有多船订单的制造商，这条路径隐含着一个实践风险：审查员排班的可用性，而非技术文件准备本身，往往成为决定交付节点的关键因素。船级社具备合格网络审查员的资源是有限的，特别是在行业整体进入强制合规阶段后，FAT 日历压力会进一步加大。选择逐船路径的供应商若无法提前数月确认审查员档期，可能面临交付延误风险——这一成本往往被低估。

此外，型式认可并非一劳永逸：即使持有有效 TAC，供应商仍须为每艘船单独提交若干逐船文件，包括 CBS 资产清单、拓扑图和测试报告。型式认可豁免的是设计审查和现场 FAT 见证，而非全部文件义务。同时需要关注版本漂移问题：若产品在取得 TAC 之后发生固件或软件版本更新，新版本是否仍在 TAC 覆盖范围之内，各船级社处理政策不尽相同，须事先与船级社确认，以避免交付时出现合规认定争议。

要交哪 10 类文件

1. CBS 资产清单
2. 拓扑图
3. 安全能力说明
4. 安全能力测试程序
5. 安全配置指南
6. 安全开发生命周期（SDLC）文件
7. CBS 维护与验证计划
8. 支撑船东事件响应与恢复的信息
9. 变更管理计划
10. 测试报告

文件清单背后的逻辑：每一类文件为何存在

上述 10 类文件并非随意罗列，它们共同构成了一条从设计到运营的证据链，每一类都指向特定生命周期阶段的监管目的。理解其背后逻辑，有助于供应商、船厂和设计院在早期阶段就以终为始地规划文件体系，而非在送审截止前临时拼凑。

「CBS 资产清单」（第 1 项）是整个合规结构的基础——它确立了每台 CBS 的身份信息：硬件型号、软件版本、固件版本、网络接口和所在舱区。没有准确的资产清单，后续的漏洞管理、补丁记录和事件响应都无从下手。这份文件对应 NIST 网络安全框架（CSF）的「识别」（Identify）功能，也是船东在运营阶段维护 CBS 补丁状态的操作基础。

「拓扑图」（第 2 项）展示各 CBS 之间、CBS 与船舶网络分区（Zone）之间的互联关系，包括所有数据流向和接口类型。对于船厂（系统集成商）而言，这份图纸与 E26 要求的「区域和管道图」（Zones and Conduit Diagram）相互印证，共同证明网络分段设计已在船级层面落实。对于设备商而言，拓扑图的关键价值在于：它将决定该 CBS 是否存在「与不受信任网络的接口」——若存在，则须额外满足 E27 中的 11 项附加安全能力（叠加于基础 30 项之上），合规范围因此显著扩大。

「安全能力说明」（第 3 项）和「安全能力测试程序」（第 4 项）是 E27 技术要求的核心证明文件。前者须将 30 项（或 41 项）安全能力逐条映射到产品的具体实现机制；后者须说明如何验证每项能力是否在实际系统上正确实现。这两份文件构成 Cyber FAT 的验证基础，无论走型式认可路径还是逐船路径，其实质内容都不可缺少——区别仅在于前者在 TAC 阶段一次性完成，后者须为每艘船重复提交。

「安全配置指南」（第 5 项）面向的是船员和船岸维护人员：它规定了 CBS 在运营中应如何保持经过审批的安全配置状态，包括密码策略、端口管理、访问权限分级等。这份文件是船级证书年度验证可查的内容之一——船东须证明在运营过程中维持了经批准的配置，而非在设计阶段合规、交付后放任漂移。

「安全开发生命周期（SDLC）文件」（第 6 项）是 E27 向供应链上游延伸的标志性要求。E27 明确要求设备商建立对标 IEC 62443-4-1 的安全开发生命周期，这意味着网络安全不仅是产品测试阶段的事项，而是贯穿需求分析、设计、编码、测试、发布和漏洞响应全过程的体系性能力。这对许多工业控制系统供应商来说是新的挑战，特别是那些此前遵循纯功能安全开发流程、尚未将信息安全集成到产品研发体系中的企业。

「CBS 维护与验证计划」（第 7 项）和「支撑船东事件响应与恢复的信息」（第 8 项）均面向交付后的运营阶段：前者规定了如何在运营中定期验证 CBS 的安全性能不发生退化；后者则为船东提供在发生网络事件时所需的技术信息——包括日志格式、备份恢复接口、紧急降级操作程序等。这两项文件体现了 E27 的一个根本立场：设备商对其产品的网络安全责任不止于交付节点，而是延伸到运营全周期。

「变更管理计划」（第 9 项）规定了在 CBS 发生配置变更、软件更新或硬件替换时，应遵循怎样的程序来确保变更不破坏已审批的安全状态，并及时通知船级社。这是对「版本漂移」风险的程序性管控手段。「测试报告」（第 10 项）则是对全部安全能力测试的结果性汇总，作为 Cyber FAT 见证的最终证据留存。

从整体来看，这 10 类文件形成了一条严密的证据链：E27 文件（第 1–10 项，由设备商提供）是船厂 E26 整船合规论证的前提条件。设备商若延误提交 E27 文件包，将直接阻塞船厂向船级社的 E26 送审进度，进而影响整艘船的交付节点。这一依赖关系使得 E27 合规绝非仅仅是设备商的内部事项，而是牵动整个项目供应链时序的关键节点。

E27 安全能力

41E27 安全能力30 + 11

E26 整船要求

17E26 整船要求

NIST 对齐功能

5NIST 对齐功能

CBS 类别（E22）

3CBS 类别（E22）

利益相关方全景图：谁负责哪一层

E26/E27 的一个关键特征是其清晰的角色分层——不同参与方承担不同层级的合规责任，责任边界在技术要求文本中有明确对应。了解这一分层，对于各方在项目前期识别自身义务、配置内部资源至关重要。

设备制造商（OEM/供应商）是 E27 合规的责任主体。他们须证明其每台 CBS 满足 E27 规定的全部适用安全能力，无论该设备是否连接不受信任网络（是则适用 41 项，否则适用 30 项）。供应商还须建立对标 IEC 62443-4-1 的安全开发生命周期，并生成完整的 E27 文件包交付给船厂。在型式认可路径下，供应商须预先投入完成 TAC 认证；在逐船路径下，须为每艘船安排并配合 FAT 见证。设备商若将 E27 合规视为「纸面工作」而非产品能力建设，在实际审查中往往难以通过——船级社审查员会针对文件所声明的能力进行测试验证。

船厂（系统集成商）是 E26 合规的责任主体。依据 E26 的定位，船厂是将各供应商 CBS 集成为一艘网络韧性船舶的「系统集成商」，负责确保网络分段设计、区域与管道架构、整船资产清单和船级送审文件的完整性。船厂对供应商 E27 文件包的依赖是双向的：一方面须在采购阶段明确要求供应商提供 E27 合规文件；另一方面须在设计阶段确定区域划分（Zone definition），因为区域决策影响哪些 CBS 将接入不受信任网络，进而影响供应商须满足 30 项还是 41 项安全能力。这意味着 E26/E27 的合规工作必须从船舶概念设计阶段即启动。

设计院（船舶设计方/船级图纸设计机构）在区域架构和管道设计方面承担早期关键作用。「区域与管道图」是 E26 设计阶段最核心的文件，而其设计决策需要在采购启动之前完成：一旦确定某个功能域与业务网络或互联网存在接口，对应的 CBS 即须满足额外 11 项 E27 能力，这将直接影响产品选型和供应商资质要求。设计院若在后期（例如详细设计阶段）才启动网络分段设计，可能面临重新选型或要求供应商补充合规的代价。

船东（营运人）是 E26 合规在运营阶段的责任主体。船东须维持「船舶网络安全与韧性方案」，包括：持续管理 CBS 补丁状态（供应商须在合理时限内发布安全补丁，船东须在运营中跟踪落实）；维护访问控制和携带式设备管理程序；保存并定期更新 CBS 软件物料清单（SBOM）及 CVE 记录；在发生网络事件时按计划响应。这些内容在船级年度验证时均属可查项，船东须证明书面方案已在实际运营中落实而非束之高阁。

船级社是整个体系的验证和见证方：审查文件、颁发型式认可证书、见证 Cyber FAT（逐船路径）、发放带有网络符号的船级证书，并在年度检验中持续验证合规状态。各船级社的具体实施细则存在差异，所有涉及程序性安排（FAT 日期确认、文件格式要求、TAC 版本变更处理等）的问题，均应以具体船级社的最新规定为准。

典型认证案例：率先落地的项目

强制生效日期前后，已有多个项目率先完成了 E26/E27 体系下的船级认证，为业界提供了宝贵的实践参考。

挪威船级社（DNV）方面，由三星重工建造的 TEN（Tsakos Energy Navigation）三艘 DP2 梭式油轮系列，据 Riviera 报道（2025 年），成为首批获得 DNV「Cyber Secure（Essential）」船级符号的梭式油轮新造船系列，同时满足 IACS E26/E27 及 IEC 62443-3-3 的要求，其中两艘于 2025 年第二季度交付，一艘计划于 2026 年第二季度交付。该系列项目展示了大型油轮领域早期采纳 E26/E27 合规路径的可行性。

劳氏船级社（LR）方面，2025 年 5 月，北极星公司（North Star）的两艘海上风电委任服务操作船（CSOV）——「Grampian Kestrel」和「Grampian Eagle」——由挪威 Vard Langsten 船厂依据 VARD 4 22 设计建造，成为全球首批按劳氏船级社落实 IACS UR E26/E27 的规则正式获批的离岸风电船舶，其动力定位和 Voith Schneider 推进系统均通过了评估（来源：LR 新闻发布，2025 年 5 月）。这一案例特别具有代表性，因为 CSOV 的 DP 系统和推进系统正是 E27 中「与不受信任网络有接口」的典型 CBS 场景——对应的 41 项安全能力合规是其通过审批的核心内容。

这两个案例的共同启示是：E26/E27 合规虽然要求供应商、船厂、设计院和船东在项目各阶段投入大量协调工作，但在现有技术条件和船级社评审能力下，合规路径已经可行，认证周期也在逐步成形。早期项目积累的经验——包括文件格式、FAT 见证的时间安排和 CBS 版本管理实践——将为后续项目提供参照。

合规落地的四大现实缺口

即使在强制日期之后，业界在实际落地过程中仍普遍存在若干结构性缺口，了解这些缺口有助于各方提前识别风险并针对性地补强。

第一个缺口是文件能力与产品能力的脱节。许多供应商的设备在功能上已具备相当的网络安全防护能力，但从未将这些能力以 E27 要求的格式系统化整理成证明文件。产品能力存在、证明文件缺失，是目前最常见的障碍。生成一份完整的 E27 合规映射表——将 41 项安全能力逐条对应到产品的具体实现——往往需要工程团队、软件团队和认证团队的联合介入，耗时远超预期。对于产品研发历史较长、原始文档积累不足的 OEM 而言，这项工作量尤为可观。

第二个缺口是版本漂移与软件物料清单（SBOM）的缺失。产品在取得型式认可后，几乎不可避免地会经历固件或软件版本的迭代。新版本是否仍在 TAC 覆盖范围之内、船东如何追踪并记录已部署 CBS 的版本状态、CVE（常见漏洞和暴露）记录是否完整——这些都是目前实践中普遍存在弱点的领域。SBOM 的生成在工业嵌入式系统领域尤其复杂，许多产品的组件清单在开发阶段从未被系统记录，事后追溯的成本和准确性均面临挑战。

第三个缺口是区域划分决策滞后。在一些项目中，网络分段设计在采购完成之后才被认真对待，导致部分已选型的 CBS 在进入详细设计阶段后才被判定为「接触不受信任网络」，突然面临额外 11 项安全能力的合规要求。这时再要求供应商补充能力或文件，不仅代价高昂，还可能引发交货期纠纷。正确做法是在采购招标阶段即明确区域架构方案，将 E27 能力要求（30 项或 41 项）写入采购技术规格书。

第四个缺口是专业审查员资源的瓶颈。船级社具备 E27 Cyber FAT 见证能力的审查员数量有限，尤其是在全球多个船厂同步推进新造船项目的情况下，审查员排班紧张是可预见的系统性风险。逐船路径的供应商若不能提前数月锁定审查员档期，可能面临「设备就位但审查员无法到场」的尴尬局面，进而导致船舶系泊等待，形成可量化的经济损失。这一风险是型式认可路径相较于逐船路径的隐性优势之一，在评估两条路径的成本效益时应当纳入计算。

上述四类缺口的根本成因有一个共同点：将 E26/E27 合规视为交付前的「收尾工作」而非项目全周期的嵌入式流程。合规工作从概念设计阶段启动，比从详细设计阶段启动，在边际成本上具有数量级的差异。

本白皮书是入门概览，方便转发给同行；正式合规要求与定级以船级社审查为准。