Article 16 Regulation (EU) 2024/2847 · Chapter II 法規 (EU) 2024/2847 · 第二章
Establishment of a single reporting platform 單一通報平台之建立
ENISA establishes a single reporting platform that simplifies manufacturer notifications under Article 14(1)/(3) and Article 15(1)/(2). National CSIRTs receive via electronic end-points; ENISA aggregates and disseminates per CRA rules. ENISA 建立單一通報平台、簡化製造商依第 14(1)/(3)、15(1)/(2) 條之通報。會員國 CSIRT 透過電子端點接收；ENISA 依 CRA 規則匯整並發送。
Block 1 · Official text 區塊 1 · 官方條文
What the Regulation actually says 條文實際怎麼寫
Source. From Regulation (EU) 2024/2847, OJ L 2024/2847 (20 Nov 2024). Translation unofficial; refer to EUR-Lex for binding text. 來源。節錄自《法規 (EU) 2024/2847》，OJ L 2024/2847（2024 年 11 月 20 日）。中文為非官方翻譯；強制適用條文請見 EUR-Lex。
1. For the purposes of the notifications referred to in Article 14(1) and (3) and Article 15(1) and (2) and in order to simplify the reporting obligations of manufacturers, a single reporting platform shall be established by ENISA. ENISA shall act as a front office for the receipt of notifications referred to in this paragraph. The single reporting platform shall be designed to facilitate the receipt of notifications by the relevant CSIRTs designated as coordinators via electronic notification end-points.
2. Upon receipt of a notification, ENISA shall, without undue delay, transmit the notification to the CSIRT designated as coordinator of the relevant Member State, namely the Member State where the manufacturer has its main establishment in the Union, or, in the case of a non-EU manufacturer, the Member State where its authorised representative is established. The CSIRT designated as coordinator initially receiving the notification shall disseminate it without undue delay to other CSIRTs designated as coordinators that may be affected and to ENISA, except where the manufacturer has indicated cybersecurity-related grounds for delaying dissemination.
3. Where the dissemination of a notification is delayed for cybersecurity-related grounds as indicated by the manufacturer under Article 14(2), point (a), the dissemination of the notification may be delayed based on justified cybersecurity-related grounds for a period of time that is no longer than what is strictly necessary, including where a vulnerability is the subject of an ongoing coordinated vulnerability disclosure procedure as referred to in Article 12(1) of Directive (EU) 2022/2555. Where a CSIRT decides to withhold a notification, it shall immediately inform ENISA of the decision.
4. The single reporting platform shall be designed to ensure the confidentiality and the integrity of the information notified.
1. 為達成第 14(1)、(3) 條與第 15(1)、(2) 條所指通報之目的、並簡化製造商之通報義務，應由 ENISA 建立單一通報平台。ENISA 擔任本項所指通報之接收前台。單一通報平台之設計應促進相關指定為協調者之 CSIRT 透過電子通報端點接收通報。
2. 收到通報時，ENISA 應毫不延遲地將該通報轉送相關會員國指定為協調者之 CSIRT，亦即製造商於歐盟主要設立地所在會員國；非歐盟製造商，則為其授權代表所在會員國。最初接收通報之指定為協調者之 CSIRT，應毫不延遲地將其發送予其他可能受影響之指定為協調者之 CSIRT 與 ENISA，除非製造商已表明因網路安全相關理由而延後發送。
3. 製造商依第 14(2)(a) 條指出網路安全相關理由而延後發送通報時，得基於正當網路安全相關理由延後發送、期間以嚴格必要為限，包括弱點處於依《指令 (EU) 2022/2555》第 12(1) 條進行協調揭露程序中之情形。CSIRT 決定保留通報時，應立即通知 ENISA。
4. 單一通報平台之設計應確保通報資訊之機密性與完整性。
Block 2 · Plain language 區塊 2 · 白話解讀
The single reporting platform — one URL for 27 CSIRTs 單一通報平台，一個 URL 對應 27 個 CSIRT
Article 16 is the article that turns the otherwise impossible-looking Article 14 reporting obligations into something operationally feasible. Without it, a manufacturer of an internet-connected product would face the prospect of notifying 27 different national CSIRTs in 24 hours, each with its own portal, language, and procedure. With Article 16, ENISA runs a single front-end platform; the manufacturer files once; routing happens internally.
One front office, internal routing. Article 16(1) is unambiguous: ENISA acts as the front office for receiving notifications under Article 14(1), 14(3), 15(1), and 15(2). The manufacturer interacts with ENISA. ENISA then transmits to the CSIRT designated as coordinator of the relevant Member State (Article 16(2)). The relevant Member State is the country of the manufacturer's main EU establishment, or for non-EU manufacturers, the country where the authorised representative is established.
The CSIRT then disseminates further. Article 16(2) second sentence: the receiving CSIRT "shall disseminate it without undue delay to other CSIRTs designated as coordinators that may be affected and to ENISA". The dissemination is fast — "without undue delay" — but conditional on "cybersecurity-related grounds for delaying dissemination" identified by the manufacturer under Article 14(2)(a). The grounds let the manufacturer pause the spread of vulnerability info until a coordinated disclosure timing is appropriate.
Delays are time-boxed and audited. Article 16(3) sets the delay regime: "justified cybersecurity-related grounds for a period of time that is no longer than what is strictly necessary, including where a vulnerability is the subject of an ongoing coordinated vulnerability disclosure procedure". The CSIRT can decide to withhold a notification, but "shall immediately inform ENISA of the decision". This is the audit trail — every delay is documented, justified, and time-bounded.
Confidentiality and integrity are by design. Article 16(4) is one short paragraph but heavy in implication: "the single reporting platform shall be designed to ensure the confidentiality and the integrity of the information notified". This is a regulatory commitment — ENISA cannot run the platform on a vulnerable infrastructure. Manufacturers can rely on the platform without leaking sensitive vulnerability data to third parties before the coordinated disclosure is ready.
The platform is operational from 11 September 2026. Article 71 (entry into force) singles out Articles 14 and 15 — the reporting obligations — as applying from 11 Sep 2026, before the rest of CRA. The single reporting platform must be operational by then. ENISA has been openly building infrastructure for this through 2025–2026; manufacturers should not assume the platform will be perfect on day one and should test their internal escalation flows in advance.
第 16 條把第 14 條看起來不可能的通報義務、變成營運上可行的事。沒有它、連網產品製造商面對的是 24 小時內通報 27 個不同國家 CSIRT、各有自己的入口、語言、程序。有了第 16 條、ENISA 跑一個單一前端平台；製造商通報一次；路由在內部處理。
一個前台、內部路由。第 16(1) 條毫不含糊：ENISA 擔任接收第 14(1)、14(3)、15(1)、15(2) 條通報的前台。製造商跟 ENISA 互動。ENISA 之後轉送到相關會員國指定為協調者的 CSIRT（第 16(2) 條）。相關會員國是製造商歐盟主要設立地所在國家、或對非歐盟製造商、授權代表所在國家。
CSIRT 之後再向外發送。第 16(2) 條第二句：接收 CSIRT「應毫不延遲地將其發送予其他可能受影響之指定為協調者之 CSIRT 與 ENISA」。發送很快，「毫不延遲」：但以製造商依第 14(2)(a) 條提出的「網路安全相關延後發送理由」為條件。這些理由讓製造商可以暫停弱點資訊的擴散、直到協調揭露的時機適當。
延後是定時、有稽核的。第 16(3) 條設定延後制度：「正當網路安全相關理由、期間以嚴格必要為限、包括弱點處於進行中的協調揭露程序」。CSIRT 可以決定保留通報、但「應立即通知 ENISA 該決定」。這是稽核軌跡，每一次延後都被記錄、合理化、時限化。
機密性與完整性是設計內建的。第 16(4) 條一段話、含意很重：「單一通報平台之設計應確保通報資訊之機密性與完整性」。這是一個法規承諾，ENISA 不能用脆弱的基礎設施跑這個平台。製造商可以依賴這個平台、不擔心敏感弱點資料在協調揭露準備好之前洩露給第三方。
平台於 2026 年 9 月 11 日生效。第 71 條（生效）特別把第 14 條跟第 15 條：通報義務，挑出來、適用日期是 2026 年 9 月 11 日、早於 CRA 其他條文。單一通報平台必須在那之前可運作。ENISA 公開在 2025-2026 年建立相關基礎設施；製造商不應假設平台第一天就完美、應該先測試自己內部的升級流程。
Block 3 · APAC perspective 區塊 3 · APAC 觀點
SRP and APAC PSIRT operating reality SRP 跟 APAC PSIRT 營運現實
For APAC manufacturers selling into the EU, the single reporting platform is the single biggest operational shift Article 14 forces. Many Taiwan, Japan, and Korea OEM/ODMs do not currently run a 24/7 PSIRT. They have product security teams that operate during local business hours. The 24-hour CRA early warning timer does not respect local business hours. From 11 Sep 2026, an actively exploited vulnerability discovered at 23:00 Friday Tokyo time triggers a 24-hour clock that ENDS at 23:00 Saturday Tokyo time — Saturday afternoon European time. Someone has to file the early warning before 23:00 Saturday Tokyo, or the manufacturer is non-compliant.
對賣到 EU 的 APAC 製造商、單一通報平台是第 14 條強制的最大營運轉變。很多台日韓 OEM / ODM 目前沒有 24/7 PSIRT。他們有當地工作時間運作的產品安全團隊。CRA 24 小時早期警報時鐘不尊重當地工作時間。從 2026 年 9 月 11 日起、週五東京時間 23:00 發現的主動受利用弱點、觸發一個在週六東京時間 23:00 結束的時鐘，歐洲週六下午。在那之前必須有人提交早期警報、否則製造商不合規。
The realistic options: build a 24/7 PSIRT (expensive, only viable for Tier-1 manufacturers); contract a 24/7 PSIRT-as-a-service provider (cheaper, but introduces a third party in the chain); use the EU AR for after-hours filing (only works if the AR is contractually committed to act and has the technical info). Most Tier-2 and Tier-3 APAC manufacturers will need a hybrid model.
實務選項：建 24/7 PSIRT（貴、只 Tier-1 製造商適用）；簽 24/7 PSIRT-as-a-service 供應商（較便宜、但鏈條上多一個第三方）；用 EU AR 處理工作時間外通報（只在 AR 合約上承諾行動且有技術資訊時可行）。多數 Tier-2 跟 Tier-3 APAC 製造商會需要混合模式。
Country-of-AR matters more than most APAC manufacturers initially realise — because the country-of-AR determines the receiving CSIRT under Article 16(2). The receiving CSIRT then handles the further dissemination and coordinates with the manufacturer through any delays. Different national CSIRTs have very different operational profiles.
AR 在哪一國比多數 APAC 製造商一開始想得更重要，因為 AR 所在國決定第 16(2) 條下接收的 CSIRT。接收 CSIRT 之後處理進一步發送、並在任何延後期間跟製造商協調。各國 CSIRT 的運作特徵差別很大。
| If AR established in...如果 AR 設於…… | Receiving CSIRT接收 CSIRT | Operational characteristic運作特徵 |
|---|---|---|
| Germany德國 | BSI CERT-BundBSI CERT-Bund | Strong technical capability, deep IT/OT cybersecurity expertise. Most procedures in German; English-capable but not English-default.技術能力強、IT / OT 網路安全專長深。多數程序德文；英文可、但非預設。 |
| Netherlands荷蘭 | NCSC-NLNCSC-NL | English-friendly, technically strong, fast response cadence. Popular AR jurisdiction for APAC vendors targeting English-speaking workflows.對英文友善、技術強、回應速度快。APAC 廠商以英文工作流程為主時、熱門的 AR 司法管轄。 |
| Ireland愛爾蘭 | NCSC-IENCSC-IE | English-only, lighter procedures, capable but smaller team. Suits APAC vendors with EU presence already in Dublin.純英文、程序較輕、能力到位但團隊較小。適合在都柏林已有歐盟設立地的 APAC 廠商。 |
| Belgium比利時 | CERT.beCERT.be | Brussels location convenient for EU institutional access. Multilingual French / Dutch / English.布魯塞爾位置方便接觸歐盟機構。法 / 荷 / 英多語。 |
| Spain西班牙 | INCIBE-CERTINCIBE-CERT | Strong industrial cybersecurity (CERT for industrial sector). Spanish-default; English-capable.工業網路安全強（工業部門 CERT）。預設西班牙文；英文可。 |
For APAC PSIRT operations, an important detail in Article 16(3): the manufacturer can request a delay in dissemination on "cybersecurity-related grounds" — most importantly, when a coordinated vulnerability disclosure (CVD) is in flight. APAC manufacturers that participate in CVD programmes (most major Taiwan / Korea ICT vendors do, via MITRE CVE Numbering Authorities, or through Japanese JPCERT/CC) need to ensure their CVD timelines align with their CRA early-warning filings. Filing the early warning at 23:59 of hour 24, then immediately requesting delay to align with a 30-day CVD window, is a coherent strategy — but the strategy has to be pre-agreed with the receiving CSIRT, not improvised.
對 APAC PSIRT 運作、第 16(3) 條有個重要細節：製造商可以以「網路安全相關理由」請求延後發送，最重要的是、協調弱點揭露（CVD）進行中時。參與 CVD 計畫的 APAC 製造商（多數主要台 / 韓 ICT 廠商透過 MITRE CVE Numbering Authorities、日本廠商透過 JPCERT/CC）、需要確保 CVD 時程跟 CRA 早期警報通報對齊。在 24 小時的 23:59 提交早期警報、然後立即請求延後對齊 30 天 CVD 窗口、是合理策略，但策略要事先跟接收 CSIRT 協議好、不是臨時起意。
A practical pre-CRA action item for APAC PSIRT teams: in 2026, run a tabletop exercise that simulates a Friday-evening discovery of an actively exploited vulnerability, and run the full Article 14 + Article 16 flow including ENISA platform filing, CSIRT routing, and any CVD-related delay request. Identify the gaps before September 2026, not after.
APAC PSIRT 團隊的 CRA 前實務行動：2026 年跑一次桌上演練、模擬週五傍晚發現主動受利用弱點、跑完整第 14 + 16 條流程、含 ENISA 平台通報、CSIRT 路由、跟任何 CVD 相關延後請求。在 2026 年 9 月之前、不是之後、找出落差。
Block 4 · Cross-regulation map 區塊 4 · 跨法規對照
SRP in the EU cyber-incident reporting landscape SRP 在 EU 網路事件通報全景中的位置
CRA is one of multiple EU regimes that require incident reporting. Each has its own clock, its own scope, its own routing. APAC manufacturers selling diverse product portfolios into the EU may face several of these simultaneously. The SRP simplifies CRA-side reporting but does not consolidate across regimes. CRA 是多個要求事件通報的 EU 制度之一。各有自己的時鐘、範圍、路由。賣多元產品組合到 EU 的 APAC 製造商可能同時面對好幾個。SRP 簡化 CRA 側通報、但不會跨制度整合。
NIS2 Directive 2022/2555 — incident reporting for essential and important entitiesNIS2 指令 2022/2555：essential 跟 important entities 的事件通報
NIS2 requires essential and important entities to notify their national CSIRT of significant incidents within 24 hours (early warning), 72 hours (incident notification), and 1 month (final report). The clock is similar to CRA Article 14 but the trigger is different — NIS2 fires on incidents at the entity itself; CRA fires on actively exploited vulnerabilities or severe incidents in products. A vendor that is also a NIS2 essential entity may face both clocks for the same root event.
NIS2 要求 essential 跟 important entities 在 24 小時內通報國家 CSIRT 重大事件（早期警報）、72 小時（事件通報）、1 個月（最終報告）。時鐘跟 CRA 第 14 條相似、但觸發不同，NIS2 觸發於實體本身的事件；CRA 觸發於產品的主動受利用弱點或嚴重事件。同時是 NIS2 essential entity 的廠商、可能就同一個根源事件面對兩個時鐘。
DORA 2022/2554 — financial sector ICT incident reportingDORA 2022/2554：金融部門 ICT 事件通報
DORA imposes ICT incident reporting on financial entities. APAC manufacturers selling PwDE into financial-sector customers may need to support their customers' DORA reporting alongside CRA Article 14 — DORA-driven information requests from financial entities will increase pressure on supplier-side incident handling.
DORA 對金融實體課 ICT 事件通報義務。賣具數位元素產品給金融部門客戶的 APAC 製造商、可能需要在 CRA 第 14 條之外、支援客戶的 DORA 通報，DORA 驅動的金融實體資訊請求、會增加供應商端事件處理的壓力。
GDPR Article 33 — personal data breach notificationGDPR 第 33 條：個資外洩通報
GDPR requires notification to the supervisory authority within 72 hours of becoming aware of a personal data breach. A vulnerability that leads to personal data exfiltration triggers both CRA Article 14 (the vulnerability) and GDPR Article 33 (the personal data breach). Two separate filings, two separate time-tracks, two separate authorities (CSIRT vs Data Protection Authority).
GDPR 要求知悉個資外洩後 72 小時內通報監管機關。導致個資外流的弱點、同時觸發 CRA 第 14 條（弱點）跟 GDPR 第 33 條（個資外洩）。兩個分別的通報、兩個分別的時程、兩個分別的機關（CSIRT vs 資料保護機關）。
EU Vulnerability Database (Directive 2022/2555 Article 12(2))EU 弱點資料庫（指令 2022/2555 第 12(2) 條）
ENISA also runs the European vulnerability database — a public-facing CVE-style listing for known vulnerabilities. CRA Article 17(5) connects the SRP to the vulnerability database: CSIRTs designated as coordinators may communicate publicly known vulnerabilities to the database. This is the disclosure end of the pipeline — early warnings flow in via SRP, fully disclosed CVE-style entries flow out via the vulnerability database.
ENISA 也跑歐洲弱點資料庫，已知弱點的公開 CVE 式清單。CRA 第 17(5) 條把 SRP 連到弱點資料庫：指定為協調者的 CSIRT 可以將已公開弱點通訊到資料庫。這是 pipeline 的揭露端，早期警報透過 SRP 流入、完全揭露的 CVE 式條目透過弱點資料庫流出。
EU-CyCLONe (Directive 2022/2555 Article 16) — large-scale crisis liaisonEU-CyCLONe（指令 2022/2555 第 16 條），大規模危機聯絡
CRA Article 17(1) lets ENISA share CRA notifications with EU-CyCLONe (the European cyber crisis liaison organisation network) when relevant for coordinated management of large-scale incidents. This is the escalation path for CRA notifications that turn into Union-wide cyber crises. Most APAC manufacturer notifications will not reach this level — but Tier-1 vendors with widespread products (a router brand on millions of EU homes) should expect their actively exploited vulnerability filings could escalate via this route.
CRA 第 17(1) 條讓 ENISA 在大規模事件協調管理相關時、將 CRA 通報分享給 EU-CyCLONe（歐洲網路危機聯絡組織網絡）。這是 CRA 通報轉成歐盟全境網路危機的升級路徑。多數 APAC 製造商的通報不會到這個層級，但有廣泛產品的 Tier-1 廠商（出現在數百萬 EU 家庭的 router 品牌）應該預期主動受利用弱點通報可能透過這條路升級。