Regulation (EU) No 910/2014 建立了电子身份与信任服务框架,电子签名的核心规则主要位于 Articles 25–34 与 Annexes I–II。
eIDAS 对电子签名提出了哪些要求?
eIDAS 并不要求所有交易统一使用一种签名方式。Regulation (EU) No 910/2014 经 Regulation (EU) 2024/1183 修订后,继续为欧盟电子身份、电子签名与信任服务提供共同框架。Article 25 包含两层不同规则:电子签名不得仅因采用电子形式,或未达到合格电子签名(QES)要求,就被否定法律效力或证据可采性;只有 QES 在 eIDAS 下具有与手写签名等同的法律效力。高级电子签名(AES/AdES)则必须满足签署人唯一关联、能够识别签署人、签署数据由签署人以高度可信方式单独控制、签后修改可检测四项条件。并非所有文件都要求 QES,最高等级也不一定是每个流程的最佳选择。企业应先核对适用法律、成员国文件形式、见证或公证要求,再按照冒用、权限、争议和跨境依赖风险选择签名等级,最后保留能够长期验证的证书、状态、时间戳和审计证据。本指南提供通用合规与实施框架,不构成针对特定合同或成员国法律的意见。
当前分析不能只看 2014 年版法规摘要
很多旧文章仍把 2014 年框架、eIDAS 2.0 提案和现行规则混在一起。2026 年进行采购或流程设计时,应区分基础法规、EUDI 修订、实施条例和成员国规则。
Regulation (EU) 2024/1183 自 2024 年 5 月 20 日起适用,建立欧洲数字身份钱包框架,并扩展信任服务、远程 QSCD 管理及相关治理。
2025–2026 年实施条例进一步规定合格证书、签名验证、合格验证服务及公共服务场景的高级电子签名格式。
eIDAS 没有消除合同法、公证、房地产、劳动、公司登记、消费者保护和行业文件形式要求。
签名等级之外,还要证明签署意图、权限、文件版本、完整性、证书状态、送达和记录保存。
eIDAS 下三个实务签名等级
法规广义定义电子签名,再规定高级电子签名与合格电子签名的附加条件。“简单电子签名(SES)”是市场常用简称,通常指未达到 AES 或 QES 条件的电子签名,并非 Article 3 中单独定义的术语。
| 要求与证据 | 法律位置与适用场景 | |
|---|---|---|
| 电子签名 / 通常称 SES | 以电子形式存在、附着于或逻辑关联其他电子数据,并由签署人用于签署。证据通常包括意图、认证事件、文件关联、时间戳、审计记录与完整性控制。 | 受 Article 25(1) 的非歧视规则保护,但不自动满足所有合同和文件形式。适用于未要求更高形式、风险相对较低且证据足够的日常协议。 |
| 高级电子签名(AES/AdES) | 必须唯一关联签署人、能够识别签署人、使用签署人能够高度可信地单独控制的签名创建数据,并能检测签后数据的任何修改。 | 提供更强的身份、控制和完整性证据。企业应能够逐项说明签署时如何满足 Article 26,而不是只展示 MFA、证书或审计日志中的单一功能。 |
| 合格电子签名(QES) | 在 AES 基础上,由合格电子签名创建设备(QSCD)创建,并基于合格信任服务提供的合格电子签名证书;实际签名还需按 Article 32 验证。 | Article 25(2) 赋予其与手写签名等同的法律效力。适用于法律、公共程序、交易对手政策或风险决策明确要求最高 eIDAS 等级的场景。 |
Article 25 回答的是两个不同问题
把 Article 25 简化为“电子签名都具有法律约束力”会掩盖举证和文件形式差异。它既规定电子证据不得仅因形式被排斥,也赋予 QES 一项特殊的手写签名等效规则。
非歧视不等于自动可执行
电子签名不能仅因电子形式或非 QES 身份被拒绝,但仍可能需要证明签署人、意图、权限、最终文件、完整性和法定形式。
QES 具有明确的等效规则
QES 的手写签名等效地位不会修复当事人无行为能力、欺诈、违法条款、缺少见证、公证或登记等签名方法之外的缺陷。
AES 不是品牌标签
供应商应逐项解释 Article 26。邮件 OTP、MFA、防篡改 PDF、证书或审计轨迹都可能贡献证据,但任一功能都不能单独证明四项条件全部满足。
成员国形式仍然重要
遗嘱、担保、房地产文件、劳动终止、公司登记、受监管同意或公证行为等场景必须核对具体成员国法律。
从交易要求反向选择电子签名等级
先定义法律和证据结果,再选择产品功能。以下矩阵是企业初筛方法,不代替成员国法律意见。
| 决策问题 | 选择动作 | |
|---|---|---|
| 强制形式 | 法律、公共申报、交易对手政策或合同是否要求 QES、合格证书、见证、公证或其他形式? | 先满足强制形式;不要假设更强签名能够替代见证、公证、登记或规定文本。 |
| 身份风险 | 由错误人员签署会造成什么后果,冒用或共享凭据的概率多高? | 随着风险提高身份保证和签署人控制,但证件、生物特征等数据只收集到必要程度。 |
| 权限风险 | 签署人是否代表公司、监护人、授权代理或在额度内审批? | 身份与权限分开验证;强密码学签名本身不证明公司授权仍然有效。 |
| 完整性与争议 | 是否可能争议签署版本、签后修改或签署时间? | 提高文件绑定、时间戳、版本、证书验证和证据留存强度。 |
| 跨境依赖 | 多个成员国的法院、公共机构、审计人员或交易对手是否需要识别和验证? | 采用可互操作格式和当前验证路径;风险合理时 QES 提供最清晰的欧盟资格地位。 |
| 用户与生命周期成本 | 身份步骤、证书、设备或远程签名、支持和长期验证成本是多少? | 选择满足法律与风险的最低充分等级,避免过度摩擦导致绕过流程。 |
QES 结论依赖完整链条,而不是界面上的一个勾
签署应用负责组织体验,但 QES 地位由多个参与者、证书、设备和验证状态共同决定。
确认签署人身份
身份核验为证书签发提供依据,但身份核验本身不会产生 QES,也不等同签署行为。
签发合格证书
合格电子签名证书应满足 Annex I。记录签发者、证书标识、有效期、签署人身份或假名,以及状态查询位置。
使用 QSCD
签名必须通过符合 Annex II 和适用认证要求的 QSCD 创建。QSCD 可以采用本地或受合格管理的远程模式,但不能与证书混为一谈。
创建并绑定签名
应用向签署人呈现最终文件、取得明确动作,并把签名与被签数据绑定,使后续改动可以检测。
核对合格状态
在 EU/EEA Trusted Lists 中同时核对 provider、具体 service、状态及相关时间;只看到机构名称远远不够。
验证并保存
验证证书、服务、设备标识、文件完整性、签署人数据和签署时状态;长期记录还需考虑验证或合格保存。
验证实际签名,而不是只查供应商名称
Trusted List 是核对合格状态的重要官方来源,但 Trusted List 查询并不是对某份电子签名的完整验证。依赖方需要把验证结果关联到实际文件和签署时状态。
确认签名覆盖预期最终文件,并保留原始签署对象。
核对支持签名的证书在签署时属于满足 Annex I 的合格证书。
确认该证书由相关合格服务签发,且签署时有效、未过期或撤销。
核对签名验证数据与收到的数据一致,文件完整性未受破坏。
确认签署人数据正确展示,使用假名时有清楚标记。
确认签名由 QSCD 创建,且签署时满足 Article 26 条件。
检查时间戳、验证策略、证书链、撤销状态和警告,而不是只看绿色图标。
导出并保存包含验证时间、软件或策略、结果及依据的验证报告。
记录需长期证明时,规划长期验证或合格电子保存。
文件迁移、归档转换或证据系统变化后重新验证。
最新实施条例把验证要求转化为更具体的操作层
eIDAS 修订后的实施权正在形成具体标准、格式和验证流程。以下规则让 2026 年采购不应再停留在“支持 SES/AES/QES”的三行比较。
Commission Implementing Regulation (EU) 2025/1945
涉及 QES、合格电子印章以及基于合格证书的高级签名和印章验证。应核对系统使用的验证策略、标准、结果和不确定状态处理。
Commission Implementing Regulation (EU) 2025/1943
涉及合格电子签名和印章证书的参考标准。证书采购与验证应核对当前标准,而不是接受没有日期的“eIDAS compliant certificate”宣传。
Commission Implementing Regulation (EU) 2025/1942
涉及合格验证服务。普通 PDF 阅读器、签署应用和 qualified validation service 不是可以互换的标签。
Commission Implementing Regulation (EU) 2026/248
涉及公共部门在线服务中高级电子签名的格式、容器和替代验证方法;不应扩展成所有私营合同的统一格式要求。
Trusted List v6
欧盟委员会正在按照 Implementing Decision (EU) 2025/2164 和 ETSI TS 119 612 v2.4.1 推进 Trusted List v6。自动读取列表的系统需测试解析、签名真实性、刷新和失败处理。
欧盟互认并不能回答所有跨境合同问题
跨境交易需要把 eIDAS 资格、合同法、冲突法、个人数据和证据分别处理。
欧盟内部
基于一个成员国签发的合格证书形成的 QES,应在其他成员国被认定为 QES;底层交易仍可能受各国实体法和程序法影响。
非欧盟签署人
签署人位于欧盟外并不自动决定签名等级。应核对管辖法律、证书资格、身份方法、服务覆盖和预期执行地点。
第三国信任服务
不要因视觉上出现数字证书就把第三国签名称为 QES。资格承认需要适用法律路径和服务状态。
合同条款
在适当情况下约定适用法律、电子签名同意、权限、接受等级、记录访问和通知机制,但合同不能排除强制法。
数据流
身份、证书、文件、审计和支持访问可能触发 GDPR 角色、处理者、子处理者、跨境传输和保留问题。
EUDI Framework 如何改变电子签名规划
Regulation (EU) 2024/1183 已于 2024 年 5 月生效。欧盟委员会目前说明,成员国需按照法规和实施条例在 2026 年底前提供欧洲数字身份钱包。钱包旨在让用户识别身份、分享选定属性并访问公共和私营服务。对于签署团队,这不意味着所有钱包签名自动成为 QES,而是高保证身份、合格证书、远程签名创建和依赖方交互可以在用户控制的钱包生态中更紧密衔接。产品团队应把身份验证和签署分开建模,支持标准化凭证交换、选择性披露、清楚同意、依赖方登记和证据导出,并考虑各成员国不同的上线进度。2024 年底首批五项钱包实施条例涉及核心功能、协议接口、人员识别数据与属性证明、认证框架和生态通知。更细的 Wallet 实施内容由专门的 eIDAS 2.0 与 EUDI Wallet Insight 承接。
eIDAS 与 GDPR 互补,但不能相互替代
QES 可以达到最高 eIDAS 签名等级,但周边个人数据处理仍可能违反 GDPR;反过来,隐私控制充分的流程也可能选错法定签名形式。
| eIDAS 问题 | GDPR 问题 | |
|---|---|---|
| 目的 | 采用什么签名、身份或信任服务,法律与技术状态是什么? | 为什么处理个人数据、谁决定目的方式、合法性基础和透明度是什么? |
| 身份数据 | 身份方法是否支持所选签名等级、证书和签署人控制? | 证件、生物特征或特殊类别数据是否必要、适度且受保护? |
| 服务提供者 | 具体 provider/service 是否 qualified,能否在官方列表核验? | 角色、DPA、子处理者和国际传输是否正确治理? |
| 保留 | 签名、证书状态和验证证据能否在法律生命周期内继续证明? | 各类数据是否仅按明确目的保存,并支持删除、限制和权利请求? |
| 安全 | 签名创建、证书、设备、验证和保存是否安全且可互操作? | 保密性、完整性、可用性、访问控制和事件响应是否适当? |
区分客户、平台与信任服务的责任
笼统的“eIDAS compliant”无法分配交易分类、身份、证书、签名创建、验证和保存责任。
| 主要责任 | 应取得的证据 | |
|---|---|---|
| 客户 / 依赖组织 | 分类文件、确定法律与形式、核对权限、选择保证等级、配置流程、确定保留并决定是否依赖验证结果。 | 法律分析、风险决策、权限记录、批准配置、保留计划和依赖程序。 |
| 签署应用 / 工作流平台 | 呈现和路由文件、捕获意图与事件、绑定签名、集成身份和信任服务、保护数据并按合同导出证据。 | 产品规格、集成图、审计字段、安全文档、DPA、测试和证据导出。 |
| 身份提供方 | 执行约定的身份核验或认证并返回结果;其角色可能独立于证书签发和签名创建。 | 方法、保证等级、数据源、异常流程、结果格式、保留和责任条款。 |
| QTSP 与合格服务 | 仅在获授 qualified status 的具体服务范围内提供合格服务。 | Trusted List 中 provider/service 条目、状态历史、服务政策和证书配置。 |
| 验证 / 保存服务 | 按照明确策略验证实际签名,并在需要时维持长期信任证据。 | 验证报告、策略版本、状态来源、时间戳、保存证据和可迁移条款。 |
用十个受控步骤实施 eIDAS 电子签名
每类交易都应形成一份完整判断,通用供应商准入不能替代具体流程证据。
盘点文件
按法律、参与方、金额、监管和保留期整理合同、通知、申报、同意及审批。
核对形式
在选技术前识别 QES、见证、公证、登记、纸质原件、送达或规定文本要求。
评估风险
记录冒用、权限、胁迫、篡改、争议、跨境依赖和运营失败,并说明等级为何适度。
绘制服务链
列出签署应用、身份方、证书签发者、QTSP 服务、QSCD、验证、时间戳、保存与归档。
核验 qualified 主张
用官方 Trusted Lists 核对具体 provider/service,而不是依赖宣传 Logo。
配置意图与权限
让签署动作清楚、呈现最终文件,并单独核对组织或代理权限。
测试证据包
完成真实签署,导出文件、审计、证书和验证报告,并让另一审核者复现结果。
单独审查 GDPR
核对数据、角色、合法性基础、透明度、安全、子处理者、位置、传输、保留和权利。
设计异常流程
处理身份失败、证书失效、服务不可用、无障碍、权限争议、拒绝电子签和安全替代路径。
持续监控
复核法规、实施标准、Trusted List 格式、服务状态、证书、成员国规则和产品版本。
eSign.AI 如何支持 eIDAS-aligned 电子签名工作流
eSign.AI 可以提供文件准备、路由、签署、跟踪和证据留存的应用与工作流层,并按具体配置提供认证、完整性和审计能力。最终法律结果取决于所选方法、集成、供应链、客户配置和适用法律。
工作流编排
通过模板、签署顺序、提醒、审批和证据规则,让选定保证方法稳定用于目标文件。
身份与信任服务集成
需要更高保证或 QES 时,应在合同和技术设计中说明谁核验身份、签发证书、运行 QSCD 并验证结果。
证据与安全
审计事件、认证结果、时间戳和完整性控制有助于归因和争议处理;客户应测试具体套餐和配置实际生成的证据。
合格服务应逐项核验
合格信任服务的资格按具体服务认定。工作流使用合格证书、合格验证、合格保存或其他合格服务时,应记录实际服务方,并在 EU/EEA Trusted Lists 核对具体服务、合格状态及相关时间。
客户决策
客户仍需负责文件分类、适用法律、签署人权限、保证等级、隐私配置、保留和依赖判断;产品标签不能修复不适当的交易设计。
常见问题
关于 eIDAS 电子签名的常见问题
与其使用笼统标签,不如说明实际等级和证据:一般电子签名受 Article 25(1) 保护;AES 满足 Article 26;QES 还需要合格证书、QSCD 和完整验证。交易同时要满足适用形式和实体法。







