歐盟電子符合性證明書（eCoC）已進入法規正式實施階段，產業界相關討論持續深入，關注重點也逐步轉向實際執行。目前，業界已出現大量政策解讀、知識普及內容，甚至是實際導入的解決方案，但相關資訊品質良莠不齊，在為出口企業提供參考的同時，也容易造成認知上的混淆。

本文旨在為關注歐盟 eCoC 的中國企業進行系統性整理，從 eCoC 的概念、法規體系、政策現況、實施路徑及執行關鍵等面向，力求呈現準確的專業知識與清晰的實施脈絡，協助中國汽車企業順利拓展歐盟市場。

一、深度解析：eCoC 核心概念與法規體系

什麼是 eCoC？

eCoC（Electronic Certificate of Conformity）即電子化符合性證明書，也稱為 IVI（Initial Vehicle Information，初始車輛資訊），是傳統紙本 CoC（Certificate of Conformity）為實現數位化管理所發展出的新型態。

其核心是將紙本 CoC 轉換為 XML 結構化資料，使相關資訊可由系統自動辨識、交換與驗證，並支援版本管理及資訊追蹤。

圖 1 紙質 CoC 範本*

圖 2 eCoC 範本*

*注：截圖資料來源 https://ecoc.eucaris.net/tools

歐盟 eCoC 專案的開發已推動多年，在技術要求方面主要分為兩大版本：IVI 1.x 與 IVI 2.0。除資料結構上的差異外，IVI 2.0 最顯著的特點，是在 XML 檔案中嵌入電子簽名／簽章機制，以實現簽署主體的身分追溯，並防止資料遭到竄改。

1. 核心法規合規要求

eCoC 的實際導入主要依循歐盟整車型式認證（WVTA）及電子簽名（eIDAS）兩大法規架構，具體法規依據如下：

•  (EU) 2018/858 Article 37：WVTA 架構法規，明確規範 eCoC 的法律地位，並規定自 2026 年 7 月 5 日起，製造商應提供 eCoC 資料。

•  (EU) 2021/1321：WVTA 架構法規的補充規定，明確將 EUCARIS 定位為資料傳輸中樞，並規範 eCoC 資料採用 XML 檔案格式，以及 XSD 的修訂頻率。

•  (EU) 2024/1061：WVTA 架構法規的補充規定，明確規範資料安全交換原則、防竄改要求，以及上傳節點應具備的基本功能。

•  (EU) 910/2014：eIDAS 法規，為電子簽名／簽章及信任服務提供法律基礎，使 eCoC 具備可驗證性、防竄改等基本特性。

2. 實施範圍和節點

實施時間：

法規原定強制實施時間為 2026 年 7 月 5 日，即自該日起，在歐盟成員國註冊的車輛必須使用 eCoC。受歐盟各國基礎設施建置進度不一致且整體落後的影響，強制實施時間已延後至 2026 年 11 月 29 日。

在此過渡期內，紙本 CoC 仍為強制要求，eCoC 為可選擇的提交方式。該要求適用於所有歐盟成員國，與各國基礎設施建置進度無關。

實施範圍：

a.  認證類別：歐盟大批量、小批量 WVTA、豁免國家小批量。

b.  車輛類別：M、N、O 類車輛。

c.  適用地區：歐盟成員國。

d.  強制版本：IVI 2.0。

二、eCoC 如何落地？

1. eCoC 的實施路徑（設計）

eCoC 的實施並非製造商簡單生成 XML 檔並提交至歐盟成員國或型式認證機構即可，而是涵蓋 XML 資料生成、電子簽名、資料傳輸、結果回饋、資訊查詢的完整作業流程。需要特別說明的是，截至發稿時，該完整傳輸路徑仍處於建置階段，尚未全面投入使用。儘管如此，製造商仍應預留充足時間，提前展開資料生成能力建置、簽名方案選擇、國家節點（NAP）權限申請及串接測試等準備工作。

按照歐盟設計的標準路徑：製造商生成符合 IVI 2.0 資料規範且完成簽名／簽章的 XML 檔，上傳至選定的國家接入節點（NAP）；NAP 驗證通過後，將資料傳輸至 EUCARIS 系統；EUCARIS 再將資料分發至各成員國。製造商可選擇任一成員國的 NAP 進行上傳，使車輛可在任一歐盟國家完成註冊。

2. XML 檔生成

在 eCoC 導入過程中，XML 檔生成是製造商面臨的首要技術挑戰。歐盟車輛型式認證 CoC 資料嚴格遵循 (EU) 2020/683 CoC 資料範本要求，而 eCoC 在傳統 CoC 基礎上，不僅將資料格式轉換為 XML，更對資料結構進行大幅重構，並新增大量資料元素。換言之，紙本 CoC 資料與 eCoC 資料已不存在嚴格的一一對應關係。

因此，製造商通常面臨三種選擇：自行建置資料對應與轉換系統、使用歐盟官方平台手動輸入填報，或採購第三方服務。

附圖 4：紙質 CoC 中對車門的描述

附圖 5：eCoC 中對車門的描述

• 自行建置資料對應與轉換系統

製造商應首先整理現有及計畫出口歐盟的產品矩陣，確保開發的系統既能滿足業務需求，又能避免資源浪費。在此基礎上，進行 IVI 2.0 欄位解析、驗證規則整理、WVTA 認證資訊與 IVI 2.0 對應關係建立、前端介面設計及資料轉換邏輯開發等工作。

由於 IVI 2.0 資料通常採用 Group 陣列結構，且大量使用列舉類型，原有的 WVTA 認證資訊存在大量無法直接對應的欄位，需要對法規要求有深入理解，才能生成符合要求的 XML 檔。因此，該過程必須有認證與法規專業人員參與，而非僅由 IT 部門獨立完成。

• 使用歐盟官方平台手動輸入填報

透過歐盟 eCoC 官方平台進行手動輸入，可生成符合要求的 IVI 檔。eCoC 官方平台整合了資料驗證和匯出功能，可滿足產量較小的客戶使用。但該平台輸入流程繁瑣，且不提供資料管理功能，若有其他選擇，則不建議使用。

• 採購第三方服務

隨著市場發展，越來越多機構提供 eCoC 相關產品與服務。除費用預算與資料安全因素外，需特別提醒：製造商作為型式認證的責任主體，承擔資料維護與準確性的最終責任。因此，即使採用第三方服務，深入理解 IVI 2.0 的資料要求、資料對應關係及傳統 CoC 與 IVI 的資料轉換邏輯仍至關重要。

3. 憑證管理

3.1. 電子簽章或電子簽名

要實現 IVI 2.0 XML 檔的信封簽名，製造商首先需向專業簽名服務提供者申請簽名或簽章憑證。申請憑證應滿足以下要求：

•  從實務作法角度，建議採用電子簽章，也接受電子簽名。

•  至少需符合歐盟 eIDAS 定義的進階電子簽章或電子簽名，由 QTSP 提供的合格電子簽名或簽章（QES）並非強制要求。

•  若採用簽章，憑證主體可以是製造商或歐盟授權代表，但其資訊必須與 WVTA 證書中的資訊一致。

•  若採用簽名，簽名人需與紙本 CoC 文件的簽署人保持一致。該簽署人一般在 WVTA 認證階段即已確定，其所屬主體必須為 WVTA 證書載明的製造商或歐盟授權代表。

•  簽名或簽章憑證必須有完整的憑證鏈。

除此之外，在實際操作過程中，應注意以下要點：

•  公開金鑰 X.509 簽章憑證鏈需提交至 NAP，用於簽名驗證與信任建立，嚴禁分享私密金鑰；憑證必須以 PEM 格式提交，每個檔案可包含一個或多個憑證區塊。

•  持有簽名或簽章憑證並不等同於具備簽名能力，對 XML 檔進行簽名需要完整的憑證鏈（含私密金鑰）及簽名工具。

•  購買簽名或簽章憑證時，應明確確認憑證的呼叫方式、收費方案，以及是否提供完整的憑證鏈等。

•  無論採用第三方加簽服務或自行加簽，均應預留充足時間與 NAP 確認簽名方案的可接受性，該驗證過程通常耗時較長。

3.2. 用戶端憑證

用戶端憑證用於部分 NAP 的外層信任驗證，主要用於確保 NAP 僅接收來自可信來源的 IVI 文件。並非所有 NAP 都要求用戶端憑證，但目前較為成熟的荷蘭 NAP 強制要求該憑證。

歐盟認可的憑證授權機構（CA，Certificate Authority）可核發用戶端憑證（SSL／TLS 憑證），製造商可向 NAP 申請，或向合格信任服務提供者（QTSP）的 CA 購買。用戶端連線需符合以下技術要求：

•  TLS 版本至少為 TLS 1.2。

•  用戶端證書必須在權威資訊訪問（AIA）擴展中包含 OCSP 回應器 URL，並支援以 OCSP 為基礎的撤銷檢查。

•  用戶端憑證僅可依據已備查並獲核准的憑證實務作業基準（CPS，Certification Practice Statement）核發；適用的 CPS 及憑證政策資訊必須在憑證政策擴充欄位中引用。

•  RSA 金鑰長度：最少 2048 位元（建議 3072 位元以上，或採用 ECC P256／P384）。

•  雜湊演算法：SHA-256 或更高版本。

實務作法建議：直接向 NAP 申請該憑證，通常需填寫申請表並向對應機構提交申請。製造商應與目標 NAP 聯繫，以取得具體申請要求；若自行向 CA 購買，則需將公開金鑰憑證鏈以 PEM 格式提交至 NAP 備查。

4. NAP 連接和資料上傳

國家接入節點（NAP，National Access Point）是歐盟成員國為製造商建立的通訊介面，是製造商向 EUCARIS 傳輸 eCoC 資料的唯一通道。並非所有歐盟成員國均提供 NAP 服務。以下以荷蘭 NAP 為例進行說明。

首次連線時，傳輸方需向 NAP 申請存取權限，申請時需提供通訊資訊及公司登記資訊。荷蘭 NAP 的存取權限為免費提供。

荷蘭 NAP 支援兩種傳輸方式：

•  手動傳遞

透過 NAP Tool 用戶端進行傳輸，每次僅可傳輸一份 IVI 2.0 檔，該用戶端同時提供 IVI 2.0 簽署功能。需注意：

o  透過該用戶端傳輸需提前設置用戶端憑證。

o  若透過該用戶端完成 IVI 2.0 簽署，則需設定簽名或簽章憑證。

o  不具備完整憑證鏈的憑證無法完成簽署操作。

•  自動傳遞

自動傳輸是透過 Web Service 的方式進行，需要製造商開發相應的服務，與其建立安全、穩定的連線。這通常需要設定相應的用戶端憑證，用於連線信任驗證。

在核准傳輸方正式向正式環境傳輸 IVI 資料前，通常需與 NAP 完成串接測試。因此，製造商需針對所支援的每一種車輛類別（如 M1、N2 等），各提供一份紙本 CoC 及其對應的 eCoC 用於測試；若支援不同動力類型的車輛變體（如純電動、插電式／非插電式油電混合動力、非電動車輛等），也需分別提供測試樣本。

荷蘭 NAP 為製造商提供測試環境與正式環境兩套獨立介面，製造商設定時需確保用途正確。實際存取權限並非透過帳號密碼登入用戶端或網站，而是採用 Web Service 的連線認證，製造商的連線系統必須遵循其介面規範。

NAP 的權限申請與串接測試通常所需時間較長，建議製造商預留充裕時間提前準備，避免 2026 年 11 月 29 日後無法完成緊急出口車輛的註冊。同時，製造商集中提出申請，可能導致 NAP 處理時間進一步延長。

5. 難點與風險

5.1. 資料合規與準確性

IVI 2.0 資料結構與紙本 CoC 資料本身存在不完全對應的關係，製造商需要專業的認證團隊參與，以確保生成資料的合規性。此外，儘管製造商系統與 NAP 均設置了 XSD 驗證、簽名驗證及 ICM 驗證，但這些技術驗證並不能保證 IVI 2.0 生成資料與 WVTA 認證資訊的實質一致性，需特別關注。資料準確性的最終責任主體為製造商。

5.2. 簽名或簽章憑證的申請

實際操作中，歐盟合格 CA 名單中的絕大多數機構無法為中國境內實體或個人提供身分核實服務，即無法為中國境內主體直接核發簽名或簽章憑證，通常僅能為歐盟授權代表（歐代）核發憑證。

此外，不同 CA 機構提供的憑證價格差異較大、服務內容各不相同，製造商應充分溝通並確認需求後再進行採購，重點確認憑證鏈完整性、收費方案及服務範圍等。

最後，憑證申請主體必須與 WVTA 認證資訊保持一致，否則憑證將無法使用。

5.3. NAP 連接風險

各成員國 NAP 的連線方式與要求存在差異，建置進度也不一致，且溝通週期與測試週期普遍較長。製造商在確定目標 NAP 後，應提前啟動溝通與準備工作，不可混淆不同 NAP 的要求而延誤進度。通常情況下，製造商申請一個 NAP 即可滿足業務需求。

另外，截至發稿時，部分國家的 NAP 雖已開放測試，但尚不具備完整的 NAP 能力——即現階段測試通過後，資料仍僅停留於 NAP 所在國，暫時無法透過 EUCARIS 路徑分發至其他成員國。

三、德國萊因 TÜV 可以為你做什麼？

憑藉豐富的型式認證經驗，以及對 eCoC 議題的持續深入研究，德國萊因 TÜV 可為製造商提供以下專業服務：

1. eCoC 資料合規服務：

結合專業認證經驗與 IVI 2.0 技術規範，為製造商提供符合其產品範圍的資料解析、驗證規則整理、WVTA 資訊對應轉換、欄位填寫輔導、前端設計及資料轉換技術支援。

2. 電子簽名方案服務：

協助製造商制定合適的簽名方案，提供簽章技術溝通、簽章憑證申請指導及簽章驗證等完整流程服務。電子簽章／簽名是 eCoC 實施的核心難點，建議製造商充分了解技術要求並完成相關溝通後，再進行方案選擇與採購。

3. NAP 接入服務：

協助製造商完成 NAP 權限申請、資料準備、溝通協調、串接測試及錯誤分析等完整流程工作，確保順利接入。