公告披露准备工作进展
Axiomtek于2026年7月20日发布网络安全准备进展，介绍其围绕欧盟《网络韧性法案》推进的开发与生命周期管理工作。公告提到已取得IEC 62443-4-1成熟度二级认证，并计划进一步推进产品层面的安全要求。PG关注其从开发流程延伸到持续维护的方向。
厂商还介绍了漏洞处理、固件组件追踪和逐步扩大软件物料清单覆盖的工作，并提到计划寻求首个IEC 62443-4-2 SL2产品认证。后续进展将取决于具体产品的设计、验证与生命周期管理落实情况，项目评审仍需对应型号和版本检查相关资料。
流程认证与产品证据分开理解
安全开发流程说明企业如何组织相关工作，产品层面的验证则需要对应具体型号、版本和配置。采购人员阅读认证材料时，应确认文件覆盖范围及适用对象，而不是只在供应商名称后记录一个认证标识，便默认所有设备都具有相同结论。
同一硬件型号在不同固件和软件组合下，也可能存在不同的维护要求。交付资料若能说明经过验证的版本、已知限制和更新路径，集成团队就更容易判断这些材料能否支持自己的项目，而不必在交付后重新追问基础信息。
组件清单需要随变更更新
软件物料清单的实际作用，在于帮助团队知道设备包含哪些组件及版本。清单若只在首次交付时生成，后续补丁和模块替换没有同步记录，维护人员仍可能无法判断新披露的问题是否影响现场设备，因此更新机制与清单本身同样重要。
项目可以把设备资产、固件版本和组件记录关联起来，建立从问题通报到影响确认的查询路径。记录形式不必一开始就复杂，但要保证负责人明确、信息可追溯，并能识别哪些设备仍处于待确认状态，避免遗漏长期在线却少有人检查的终端。
漏洞处理要有明确的责任交接
发现潜在问题后，厂商、系统集成商和最终使用方分别掌握不同信息。厂商可能负责固件修复，集成商负责验证应用兼容，使用方则安排现场更新。若缺少预先约定的联系人和状态记录，技术补丁准备完成后，现场仍可能长期没有落实。
有效的流程应包含接收、确认、影响评估、缓解措施和关闭记录。对无法立即更新的设备，也要说明临时处理方式和复核期限。把每一步需要的材料列清楚，可以减少跨团队往返确认，让维护工作能够被持续跟踪，而不是停留在邮件提醒。
安全更新必须考虑业务连续
工业设备更新不能只验证安装是否成功，还要检查驱动、通信协议和应用配置是否保持预期行为。小规模验证、分批执行和失败恢复应共同设计，尤其需要确认断电或网络中断发生在升级过程中时，设备能否回到可维护状态。
安全功能默认设置也需要与使用条件协调。账号初始化、远程访问和启动保护若缺乏清晰文档，现场可能为了方便而关闭相关机制。交付培训应解释操作步骤和限制，让维护人员能够在保持必要保护的情况下完成日常工作。
评审从宣传材料走向证据链
采购评审可要求提供与具体产品对应的版本记录、更新政策和问题通报渠道，并通过演练检查信息是否能够送达负责人员。对法规或合同要求的解释，应由项目相关专业团队结合适用范围确认，不能只凭一份企业公告作出最终判断。
PG认为，这份进展公告的价值在于展示持续管理方向。对工业计算用户而言，更值得关注的是供应链信息、更新能力和现场责任是否衔接。把流程要求转化为可查阅、可执行的维护证据，才能让安全工作贯穿设备整个使用周期。