【lwIP】News #10｜CRA SRPの利用規約が公開｜稼働後に変わった公式文書4点と参照版の記録
製造者に対するCRA第14条の報告義務は、2026年9月11日に始まりました。ところが稼働の前後で、ENISAのSRP関連文書は数日単位で内容が変わり続けています。入力項目を一覧化したGlossaryは、9月5日のversion 1.1から9月10日のVersion 1.3へ2版進み、どの段階で何が必須かが変わりました。新しく公開された利用規約には、SRPに対するセキュリティテストにENISAの事前同意を求める条項が入っています。公式文書を読んで社内手順を作るなら、読んだ版を書き残し、原文そのものを保存しておかないと、次に差分が取れません。稼働前後に何が変わったのかを、一次情報から4点に整理します。
【2026年9月25日 訂正】確認4のSecondary ARの閲覧範囲の記述を訂正しました。9月13日の追記では「Secondary ARは自分が提出した通知しか閲覧できない」と書きました。しかし9月17日のFAQとマニュアル4.6.1は、同じメーカーの別のARが提出した通知も閲覧・更新できるとしています。ほかの公式記載とは食い違っているため、実際の挙動は未確認です。詳しくは確認4と、末尾の【2026年9月25日 追記】をご覧ください。
このnoteでは、lwIPで実際に起こり得る不具合・脆弱性・再現方法・最小修正の考え方やデバッグのノウハウをシリーズで解説しています。
▶ 日本語記事一覧はこちら：lwIPトラブル対策室｜日本語記事一覧
本記事は「News」として、lwIPに関する速報・重要な動向をお届けします。News記事は、基本的に外部で公表された情報の整理・注意喚起が中心です。
■ 今回のニュース概要
2026年9月11日の稼働開始をはさんで、ENISAはSRPの公式文書を追加・更新しました。本記事で扱うのは次の4つです。
利用規約（CRA Single Reporting Platform - Terms and Conditions）：ページの表示は `Version 1.0`、`Last updated: 10/09/2026`。PDFのファイル名も `v1.0` と `20260910` を含みます
公式FAQ（ENISA CRA SRP Frequently Asked Questions）：本記事の初回確認時点では `Updated: 12 September 2026` で、質問が2件追加され、5件に `[UPDATED]` の表示が付いていました。その後9月17日に再更新され、9月25日時点では `Updated: 17 September 2026`、質問は32件です
Glossary（CRA SRP Glossary）：`Version 1.3`、`Last update: 10 September 2026`。入力項目の必須／任意が変わっています。その後、`Version 1.3` のまま `Last update: 25 September 2026` に改訂されました（末尾の【2026年9月27日 追記】）
操作マニュアル（CRA SRP - AR User Manual）：`Last updated: 10 September 2026`。PDFは55ページ、内部の表記は `Version: 1.1`。9月17日に、この表示と版表記のままPDFの中身が差し替わっています（確認4）
前回の News #9 は、9月6日と9月9日、9月12日に確認した内容で書いています。本記事はその続きで、同じ文書が短い間隔で改訂されているという事実そのものを扱います。
本記事は、lwIPを組み込んだ製品を出荷しているメーカーで、脆弱性・インシデントの報告を担当する方（品質保証・セキュリティ担当、開発リーダー、製品担当者）に向けたものです。読むと、稼働後に変わった点と、社内の準備をどう版管理すべきかが分かります。
本記事の確度
上記4文書はすべて、2026年9月12日に筆者が原文を取得して確認しました。要約サービスや二次情報は根拠にしていません
版どうしの差分は、Internet Archive（Wayback Machine）の保存版と、筆者が各日に保存した原文を突き合わせて確認しました。使ったスナップショットのURLは本文中に示します。以降は Wayback Machine と表記します
2026年9月13日に4文書を再取得し、いずれも版が変わっていないことを確認しました（FAQは `Updated: 12 September 2026`、Glossaryは `Version 1.3`、利用規約は `Version 1.0`、操作マニュアルは `Last updated: 10 September 2026`）
2026年9月25日に4文書を再取得しました。FAQは `Updated: 17 September 2026` に更新されていました。操作マニュアルは、同じURL・同じ版表記のまま中身が差し替わっていました（サーバの `last-modified` は9月17日）。Glossary（`Version 1.3`）と利用規約（`Version 1.0`）は変わっていませんでした。Glossaryは、この取得の後に改訂されています（末尾の【2026年9月27日 追記】）
確認4のSecondary ARの閲覧範囲は、9月25日に訂正しました。9月13日の追記では旧版マニュアル4.6.1などを根拠に説明しましたが、同じ旧版マニュアル内にも反対趣旨の記載があった可能性が高いことを考慮していませんでした。その後、9月17日にFAQとマニュアル4.6.1の記載も反対方向へ書き換わっています
引用は原文（英語）をそのまま示します。引用符の種類も原文どおりです。日本語は筆者による説明です
lwIPのコードそのものへの影響はありません。影響するのは報告の運用手順です
筆者はSRPの画面を操作していません。本記事は公開文書の記載に基づきます
■ 確認1：CRA SRPの利用規約から手順書へ書き写す条項
利用規約が公開されました。CRAの報告手続きそのものではなく、SRPというシステムの使い方を定めた文書です。社内の報告手順書に転記しておく価値が高い条項を挙げます。
(1) SRPへのセキュリティテストにはENISAの事前同意が必要です
プラットフォームの利用許諾を定めた4.2.3に、禁止事項の一つとして置かれています。
f) conduct any security testing of the Platform without ENISA’s prior consent.
（ENISAの事前の同意なく、プラットフォームに対するいかなるセキュリティテストも実施してはならない、という趣旨）
禁止されているのは事前同意のないテストです。テスト自体が一律に禁じられているわけではありません。社内の脆弱性診断の対象範囲に外部サービスをまとめて含めている場合、SRPをその範囲へ無条件に入れることはできない、という条項になります。
同じ4.2.3にはプラットフォームの改変・逆コンパイル・複製の禁止も並び、4.1.3には次の禁止行為があります。
a) undertake any action which might jeopardise the proper functioning and/or functionality of the Platform.
（プラットフォームの正常な機能・機能性を損なうおそれのあるいかなる行為も行わないこと、という趣旨）
負荷試験や自動化スクリプトでの試行も、この条項の側から見る必要があります。なお、事前同意をどこへどう求めるのかは、規約に手続きの記載がありません。
(2) アクセスを求めた時点で規約を了解したものと扱われます
規約2.4です。
Requesting access to the Platform, accessing the Platform or using the Platform signifies acknowledgment of these Terms and Conditions.
（プラットフォームへのアクセスを要求すること、アクセスすること、または利用することが、本規約を了解したことを意味する、という趣旨）
続けて、初回ログイン時に明示的な了解を求められる場合があるとも書かれています。画面の同意ボタンを待つ前に、アクセスを求めた時点で規約の対象になると読めます。社内で規約のレビューが必要な組織は、担当者がSRPへのアクセスを要求する前に済ませておく必要があります。
(3) アクセス手段は本人専用と定められています
規約3.1.8です。
The means of access (e.g. the username and password) are strictly personal, and Users are responsible for safeguarding their confidentiality and security and ensuring their appropriate use. Users undertake to take all necessary steps to prevent any unauthorised third party from gaining knowledge and making use thereof. Users may not transfer or sell their means of access to third parties.
（アクセス手段（例：ユーザー名とパスワード）は厳密に本人専用であり、利用者はその機密性と安全性を守り、適切に使用する責任を負う。権限のない第三者がこれを知り、使用することを防ぐために必要なすべての措置を講じる。利用者はアクセス手段を第三者に譲渡または売却してはならない、という趣旨）
ユーザー名とパスワードは本人専用と定められています。したがって、担当者ごとに個別のEU Loginアカウントを用意する必要があります。News #6 のポイント2と News #9 で扱ったPrimary AR／Secondary ARの登録も、担当者ごとのアカウントを前提に書かれています。
続く一文も実務に効きます。
The use of any account will be at all times attributable to the authorized User of the respective organization.
（アカウントの使用は、常に当該組織の認可された利用者に帰属する、という趣旨）
そのアカウントの使用は、実際に操作した人物にかかわらず、登録された認可利用者による使用として帰属すると読めます。
(4) アクセスを止められる場合が並んでいます
規約4.6.1は、同じアクセス手段でのログインが重なった場合について述べています。
Users acknowledge that ENISA may refuse access to a user logging in, if a session is already open on another computer where another user is using the same means of access (e.g. the same EU Login account).
（別のコンピュータで、同じアクセス手段（例：同じEU Loginアカウント）を使う別の利用者のセッションが既に開いている場合、ENISAはログインしようとする利用者のアクセスを拒否できる、という趣旨）
条文は「拒否できる」（`may refuse`）という書き方です。(3)の本人専用の定めとあわせて読むと、共有アカウントの運用は規約の想定から外れます。
規約4.6.2は、アクセスを停止・拒否できる場合を a) から i) まで9項目挙げています。3.1.9は、アクセス手段の機密性が破られたと疑う理由がある場合に、ENISAが事前の通知なくアクセスを停止または拒否できるとしています。あわせて、紛失・盗難・機密性の侵害・不正利用のおそれを `cra-srp-security@enisa.europa.eu` へ直ちに届け出る義務も定めています。報告の期限が動いている最中にアカウントが止まり得るということです。担当者が1人しかいない体制は、この観点でも弱くなります。
(5) 提出後に更新する義務が書かれています
規約4.1.7と4.1.8です。
Users are responsible for the accuracy, completeness and timeliness of the information and documentation submitted through the Platform.
Users shall ensure that notifications submitted through the Platform comply with the reporting obligations set out in Article 14 of the Regulation and shall promptly update any notification where additional relevant information becomes available or where previously submitted information/documentation is inaccurate or incomplete, in accordance with applicable law.
（利用者は提出した情報・文書の正確性、完全性、適時性について責任を負う。また、追加の関連情報が得られた場合、または既に提出した情報・文書が不正確もしくは不完全である場合には、適用法に従い、当該通知を速やかに更新しなければならない、という趣旨）
期限内に出したら終わりではなく、新しく分かったことが出たら更新する側の作業が残ります。ここで1つ、公開文書だけでは解けない点があります。今回公開された操作マニュアルにも、最終報告についてこう書かれています。
The Final Report is made available to the designated CSIRT for review and is no longer editable by the AR.
（最終報告は担当CSIRTのレビューに供され、AR側からは編集できなくなる、という趣旨）
News #6 のポイント5で扱った制約が、操作マニュアル側でも確認できました。最終報告の後に追加の情報が出た場合、規約4.1.8の更新義務をどの経路で果たすのかは、公開文書からは読み取れませんでした。これは期限内の提出を遅らせる理由にはなりません。期限は守ったうえで、担当CSIRTへの確認事項として持っておく形になります。
(6) 守秘義務はアクセス終了後5年間続きます
規約4.3.4です。担当者が異動・退職してSRPへのアクセスを失っても、義務はそこで切れません。
The confidentiality obligations set out in these Terms and Conditions shall survive the termination or expiry of the User's access to the Platform and shall remain binding for five (5) years after the end of user access to the Platform.
（本規約に定める守秘義務は、プラットフォームへのアクセスの終了または失効の後も存続し、アクセス終了後5年間は拘束力を持つ、という趣旨）
組織としてこの義務をどう担保するかは、社内規程や誓約の内容を含めて法務部門へご確認ください。
■ 確認2：製造者のCRA第14条通知以外は、現行SRPの対応外です
公式FAQに質問が2件追加されました。1件目は、メーカー以外の立場からの報告についてです。
The current version of the platform supports only mandatory notifications submitted by manufacturers under Art. 14 of the CRA. If you are not a manufacturer and would like to report a vulnerability or other security issue, please contact the relevant national CSIRT directly. Your submission might be marked as ‘invalid’ in the SRP.
（現行版のプラットフォームは、CRA第14条に基づく製造者による義務的通知のみに対応している。製造者でない立場で脆弱性その他のセキュリティ上の問題を報告したい場合は、該当する各国CSIRTへ直接連絡すること。SRPへ提出したものは「invalid」と記録される場合がある、という趣旨）
操作として提出できないとは書かれていません。書かれているのは、現行版が対応しているのは製造者の義務的通知だけであり、それ以外は `‘invalid’` と記録される場合があるということです。読者の立場では、現行SRPを一般的な脆弱性の受付窓口として使う前提を置かない、という形になります。なお、製造者に代わってAR（Assigned Representative）がSRPを操作して出す通知は、この製造者の通知に含まれます。
News #9 の確認3では、CRAの第15条の任意通知が初期版では利用できないことを扱いました。今回のFAQは、そのうち製造者以外の立場から報告する場合について、該当する各国CSIRTへ直接連絡するよう案内しています。
なお、同じFAQにはOSS（オープンソースソフトウェア）スチュワードの義務についての記載もあります。
In accordance with Art. 71(2) of the CRA, the reporting obligations for open-source software stewards under Art. 24(3) apply from 11 December 2027.
（CRA第71条(2)に従い、オープンソースソフトウェアスチュワードに対するCRA第24条(3)の報告義務は2027年12月11日から適用される、という趣旨）
製造者に対する第14条の義務（2026年9月11日開始）とは1年3か月の差があります。なお、2027年12月11日はOSSスチュワード専用の日付ではありません。CRA第71条(2)は、規則全体の適用開始を2027年12月11日とし、第14条（2026年9月11日）と第IV章（2026年6月11日）だけを前倒しの例外にしています。第24条(3)はこの例外に入っていないため、規則全体と同じ日になる、という関係です。News #2 で「CRAの主要義務の適用開始」として触れた日付と同じです。News #9 では、当時のFAQの原文表記 `Art 14 and 24(x)` の `24(x)` が何を指すのか分からない、としていました。現行FAQが第24条(3)と明記しているため、旧表記は第24条(3)を指していた可能性が高いと考えられます。ただし、旧FAQが2026年9月11日の初期版について `24(x)` を含めて必須報告と書いていた理由は、今回の記載だけでは説明が付きません。
自社がCRA上の製造者に当たるかどうかは、製品の提供形態によって変わります。第三者コンポーネントを含む場合の義務主体は News #4 で整理しました。lwIP本体の問題を見つけた場合は、上流のプロジェクトへの報告に加え、立場や事案に応じて該当する各国CSIRTへの連絡を検討します。マイコンベンダーのSDKに同梱されたlwIPで見つけた場合は、SDK提供元に製品セキュリティ窓口（PSIRT）が設けられていれば、そこへ報告する経路も検討します。これはSDK提供元への技術的な連絡経路であり、自社が製造者として負うCRA上の影響判定・通知義務を置き換えるものではありません。
SRP自体の問題を見つけた場合の窓口
追加された2件目のFAQは、SRPというシステム自身のセキュリティ問題についてです。
To report security incidents involving the platform, you can contact ENISA at cra-srp-security@enisa.europa.eu (PGP link: https://www.enisa.europa.eu/sites/default/files/2026-09/CRA-SRP_Security_Public_Key.txt). If you have found a vulnerability in the platform you can contact responsible-disclosure@enisa.europa.eu. More information at enisa.europa.eu/.well-known/security.txt .
（プラットフォームに関わるセキュリティインシデントの報告は `cra-srp-security@enisa.europa.eu` へ、プラットフォームに脆弱性を見つけた場合は `responsible-disclosure@enisa.europa.eu` へ連絡できる、という趣旨。前者にはPGP公開鍵のリンクが、後者には `security.txt` への案内が添えられています）
（引用は9月12日版の原文のままです。引用内のURLは、note.comの自動リンクで後ろの記号まで含まれる場合があります。PGP公開鍵は次のURLです：https://www.enisa.europa.eu/sites/default/files/2026-09/CRA-SRP_Security_Public_Key.txt 。9月17日版では `If you find a vulnerability in the platform, you can contact` と書き換わっていますが、趣旨は同じです）
確認1の(1)と、この窓口はセットで読むところです。SRPに脆弱性を見つけた場合の連絡先は用意されています。一方、それを探すためのテストには事前同意が必要です。規約は、ENISAが事前に同意したテストまで一律に禁止してはいません。ただし、同意の申請方法や許可の条件は確認できませんでした。
この2件が追加された時期
Wayback Machineの保存版で確認できました。
`Updated: 07 September 2026` 版：どちらも無し（スナップショット）
`Updated: 09 September 2026` 版：メーカー以外の報告についてのFAQが追加（スナップショット）
`Updated: 10 September 2026` 版：SRP自体の問題の窓口についてのFAQが追加（スナップショット）
News #9 が読んだのは9月4日版なので、どちらも既報のあとに加わったものです。
■ 確認3：CRA SRP Glossaryがv1.3になり、入力要件が変わりました
ここが本記事でいちばん実務に響く部分です。
News #9 の確認2では、Glossaryの `version 1.1`（2026年9月5日更新）をもとに、どの段階で何が必須かを整理しました。現行のGlossaryは `Version 1.3`（2026年9月10日更新）です。以下ではまず、News #9への訂正・補足として重要な4種類の変更を示します。そのあとに、それ以外に確認した変更を挙げます。
Wayback Machineに `version 1.2`（9月9日更新）のスナップショットがあったため、v1.2からv1.3への差分は原文どおりに確認できました。以下の4件はいずれもv1.3で入った変更です。一方、v1.1の保存は見つからず、v1.1からv1.2への差分は確認できていません。
変更1：72時間通知の是正・緩和措置が任意になりました
News #9では「実施した是正・緩和措置は、早期警告の段階では任意、72時間と最終報告では必須」と書きました。v1.3では、`Corrective or mitigating measures taken`（実施した是正・緩和措置）と `Corrective or mitigating measures that users can take`（利用者が取り得る是正・緩和措置）の2項目について、72時間の段階が `Required` から `Optional` へ変わっています。最終報告では引き続き `Required` です。
社内テンプレートの観点では、Glossary上、72時間の時点で措置欄を必須入力とする前提が外れたことになります。実画面の動作は未検証です。ただしこれはSRPという画面の入力要件の話であり、CRA条文が定める法的な記載事項とは別のものです。この区別はNews #9でも強調しました。
変更2：攻撃ベクタが早期警告の段階では適用外になりました
News #9では「攻撃ベクタは全段階で任意」と書きました。v1.3では、`Attack vector` の早期警告（24時間）欄が `Optional` から `N/A` へ変わっています。72時間と最終報告では `Optional` のままです。
`N/A` から確定できるのは、Glossary上でこの欄が早期警告の段階には適用されないということです。実際の画面で欄が表示されないのか、表示されても入力できないのかは確認できていません。早期警告の段階で「任意だから空欄のまま出せばよい項目」として扱うのは、現行版の記載と合いません。72時間と最終報告では引き続き任意です。要求としては緩んだ側の変更になります。
変更3：製品を提供している加盟国が無条件で必須になりました
News #9では「製品が提供されている加盟国」を、24時間の段階で用意しておく必須項目として挙げました。v1.3では、`Member States where product available (Concerned CSIRT)` の早期警告欄が `Required if such information available` から `Required` へ変わっています。
条件が外れて、無条件の必須になりました。News #9の結論（用意しておく）は変わりません。News #9はこの項目を条件付きとは書いていないため、News #9の読者にとって前提が崩れる変更ではありません。ただしv1.2を読んで「情報がある場合だけ必須」と理解した場合は、前提が変わります。なおv1.1の保存が無いため、News #9が読んだ版でこの欄が条件付きだったかどうかは確認できていません。lwIP搭載製品でいうと、どの製品をどの国に出荷したかという流通情報を、報告の場面で24時間以内に出せるかどうかという話になります。
変更4：72時間通知に必須項目が1つ増えました
変更1から3は、要求が緩んだ側と条件が外れた側でした。逆方向の変更が1件あります。重大インシデント側の項目です。
v1.2：`i37. Date/time when the incident occurred` は72時間の段階が `Optional`
v1.3：`i38. Date and time when the incident occurred (UTC time)` は72時間の段階が `Required`
早期警告と最終報告では `Optional` のままです。SRP上では、72時間通知でインシデントの発生日時の入力が必須になりました。認知した日時とは別の項目です。正確な時刻が分からない場合について、同じ行の記入方法の欄には次の記載があります。
If the exact time is unknown, enter the best supported estimate and identify it as estimated in the incident description.
（正確な時刻が不明な場合は、根拠のある推定値を入力し、インシデントの説明欄で推定値であることを明記する、という趣旨）
推定値でよいので、推定の根拠を社内で記録しておくことが要ります。
その他に確認した変更
AEV（積極的に悪用されている脆弱性）側に項目が1つ増えました。`Details about the security update/corrective measure available`（利用可能なセキュリティ更新・是正措置の詳細）が追加され、最終報告で `Required`、早期警告と72時間では `Optional` です。記入例はセキュリティパッチ、2000文字までとされています
PECの説明欄が、記入方法欄とそろいました。v1.2の説明欄は `select one of the three` でしたが、v1.3では `select at least one of the three legally specified circumstances` に変わっています。v1.2の記入方法欄には、すでに `You may select at least one of the three options.` とあったため、複数選択できる扱い自体は変わっていないとみられます。CRA第16条(2)第3副段落の3つのケースは、News #9 で条文から引いています
時刻の欄にUTCが明記されました
News #9の「確認できていないこと」に、時刻表示やタイムゾーンの扱いを挙げていました。v1.3では、重大インシデント側の2つの時刻欄について、項目名が `Date/time` から `Date and time` へ書き換わり、あわせて `(UTC time)` が入りました。
`Date and time when you become aware of the incident (UTC time)`
`Date and time when the incident occurred (UTC time)`
脚注も更新され、現行リリースでの画面上の名称が `Date and time when the incident was detected (UTC time)` であると書かれています。
入力はUTCで行うと読めます。社内で時刻を日本時間で記録したものをそのまま入れると9時間ずれます。News #9 の確認1で扱った72時間カウンタの話とあわせて、認識時刻はタイムゾーンを明示した形で記録する必要があります。
なお、脆弱性側の認知時刻の欄（`Date and time when you become aware of the Actively Exploited Vulnerability`）には、v1.3でも項目名にUTCの表記が付いていません（同じ行の記入例は `2026-08-24 09:15 UTC` とUTCで書かれています）。この欄には脚注が付いており、内容は次のとおりです。
[1] This field will be available in the next release of the Platform.
（この項目はプラットフォームの次期リリースで利用可能になる、という趣旨）
脆弱性の認知時刻を入れる欄そのものが、現行リリースにはまだ無いと読めます。News #9 の確認1で扱った「SRPの72時間カウンタが認知時刻ではなく24時間報告の提出時刻を基準にしている」という挙動と、同じ方向を向いた記載になります。項目名にUTCの表記が付いていない理由は、この記載からは判断できませんでした（扱いが違うのか、まだ整備されていないのか）。
版が上がる速さを前提にした運用が必要です
ここまでの変更は、9月5日のv1.1から9月10日のv1.3までの5日間に入ったものです。社内テンプレートを作るときは、参照したGlossaryの版を必ず記録してください。版を書いておかないと、次に読んだときに何が変わったのか分からなくなります。
本記事も、全フィールドの一覧は転載しません。分量が多く、公式文書が更新されれば内容が変わります。
■ 確認4：操作マニュアルが公開され、FAQの文言が整理されました
55ページの操作マニュアルが出ています
操作マニュアルが公開されています。ページの表示は `Last updated: 10 September 2026`、PDF内部の表記は `Version: 1.1` です。ページの日付は更新日であり、公開日そのものは特定できていません。内容は、これまで個別のガイダンスで説明されていた事項を含み、画面の手順に沿って構成されています。
この文書には、本記事の主題そのものが現れています。PDFの本文ページのフッタは `Version: 1.1` ですが、冒頭の `Document History` には次の1行しか載っていません。
09/09/2026 v1.0 First version
v1.1で何が変わったのかは、その文書自身に記録されていません。版番号を書き写すだけでは足りず、原文そのものを保存しておく必要がある、という例になります。
内容面では、マニュアルが `notification status`、`report sub-state`、`dissemination status` の3つを書き分けていることが確認できます（News #9 で扱った `72h Submitted under PEC` は3つ目です）。状態遷移の詳細は本記事の主題から外れるため、ここでは立ち入りません。
【9月25日 訂正】Secondary ARの閲覧範囲について、FAQとマニュアル4.6.1の記載が9月17日に逆方向へ書き換わりました
9月13日の追記で、この節に「Secondary ARは自分が提出した通知しか見られない」と書き、News #6 のポイント2の要確認に答えが出た、としていました。この記述は、9月17日以降の公式FAQと操作マニュアルの記載とは逆になっています。あわせて、当時の操作マニュアルの中にも反対の趣旨の記載があった可能性が高く、筆者はそれを考慮していませんでした（後述）。
9月17日の差し替え前の操作マニュアル（4.6.1。9月15日にWayback Machineへ保存された版で再確認）と、画面機能ガイダンスには、次のように書かれていました。公式FAQ（質問9）にも同じ趣旨の記載がありました。
A Primary AR can access all notifications associated with their manufacturer, whereas a Secondary AR can only access notifications they submitted and drafts they created. Secondary ARs cannot view notifications submitted by another AR associated with the same manufacturer.
（Primary ARは自社に関連付けられたすべての通知にアクセスできるが、Secondary ARは自分が提出した通知と自分が作成した下書きにしかアクセスできない。Secondary ARは、同じメーカーに関連付けられた別のARが提出した通知を閲覧できない、という趣旨）
`Updated: 17 September 2026` の公式FAQ（質問9）と、同じ日に差し替えられた操作マニュアルの4.6.1は、こう書いています。
Primary and Secondary ARs associated with the same manufacturer can access, view, and update notifications associated with that manufacturer, regardless of which AR originally submitted them. This allows another AR associated with the same manufacturer to continue the reporting process, including subsequent reporting stages and updates, as applicable.
（同じメーカーに関連付けられたPrimary ARとSecondary ARは、どのARが最初に提出したかにかかわらず、そのメーカーの通知にアクセスし、閲覧し、更新できる。これにより、同じメーカーの別のARが、後続の報告段階や更新を含めて報告手続きを引き継げる、という趣旨）
引用はマニュアルの文言です。FAQは原文のまま `regardless of with AR` となっており、`which` の誤記とみられます。ほかは同じ内容です。例外は下書きだけで、下書きは各ARのアカウントに保存され、他のARからは見えないとされています。
ただし、これで「解消した」とは書けません。2026年9月25日時点で、公式文書どうしが食い違っているからです。
画面機能ガイダンス（`Last updated: 12 September 2026`）は、旧記載（`Secondary ARs cannot view notifications submitted by another AR`）のままです。これは現行のFAQ・マニュアル4.6.1と直接食い違っています
差し替え後の操作マニュアルには、4.6.1と整合しているか説明が付かない文言も残っています。まず4.6.1の手順1そのものが、`The content displayed depends on the notifications created by the logged-in AR.` のままです。同じ節の中で、新しい例外の説明と食い違って読めます。通知の更新（4.8）の前提条件も `A notification has previously been submitted or saved as a draft by you.` です。巻末のFAQには、ダッシュボードに通知が見えない理由の一つとして `the notification may have been created by another user.` とあります。ただし、これらの文言だけで「同じメーカーの別のARが提出した通知は見られない」とまでは言えません
旧版のマニュアルの中でも、記載は食い違っていました。9月15日にWayback Machineへ保存された版（PDFの作成日時は9月10日）の巻末FAQには、すでに `Both Primary and Secondary ARs can open, review, and edit the notification(s) associated with their manufacturer.` とあります。筆者が9月12日と13日に読んだ版も、版表記とページ数が同じで、同じ内容だった可能性が高いと考えています。その場合、筆者はこの記載を考慮せずに結論を書いていたことになります
実務では、次のように扱うのが無難です。SRP上で別のARが報告を引き継げることを前提にせず、確かめるまでは、案件と提出状況をSRPの外でも共有しておく。下書きが共有されない点は、どの版でも変わっていません。
変更がSRP自体の挙動の変更なのか、文書の誤りの訂正なのかは、公開文書からは判断できません。筆者はSRPの画面を操作していません。
FAQの報告期限の文言が、既報の整理に揃いました
公式FAQの報告期限の項目に、9月12日の更新で `or mitigating` という語句が加わっています。筆者が9月11日に取得した原文と、9月12日に取得した原文を比べたものです。
旧：`after a corrective measure (e.g., patch) becomes available`
新：`after a corrective or mitigating measure (e.g., patch) becomes available`
これは新しい期限ルールが加わったのではなく、FAQの説明が既存の整理に近づいたものと読むのが妥当です。News #6 のポイント5では、すでに「脆弱性の場合、最終報告の期限は修正・緩和策が利用可能になってから14日以内」と書いています。是正措置だけを挙げていたFAQの書き方が、緩和措置も含む形に直ったという理解になります。
根拠はFAQ自身の中にもあります。9月11日版の時点で、72時間カウンタを説明する別の回答には次の記載がすでにありました。
For AEVs, no counter is currently implemented, as the Final Report deadline depends on the date and time when a corrective or mitigating measure becomes available.
（AEVについては、最終報告の期限が是正または緩和の措置が利用可能になった日時に依存するため、現在カウンタは実装されていない、という趣旨）
同じFAQの中で、期限を説明する回答だけが `corrective measure` のままだったことになります。9月12日の編集は、文書内の表現を揃えたものと読めます。
ただし、個別の事案で何をもって措置が `becomes available` の状態になったと扱うのかは、このFAQからは判断できません。回避策の案内を公開した時点が起算点になる、といった具体化は公開文書からは導けませんでした。判断はCRA条文と法務部門の確認によります。
■ 【2026年9月27日 追記】Glossaryが版番号1.3のまま改訂されました
Glossaryが、`Version 1.3` の表示を変えないまま、`Last update: 25 September 2026` に改訂されました。筆者が9月25日の朝に取得した版（`Last update: 10 September 2026`）と比べると、本文の差分は1項目です。
脆弱性側に、項目番号 `v26a`（脆弱性が発生した日時、UTC）が追加されました。Glossary上、早期警告では任意、72時間通知では必須とされています（実際の画面は未確認です）
正確に分からない場合は、根拠のある推定値を入れ、推定であることを説明欄に明記するよう書かれています
本記事の確認3で扱った重大インシデント側の発生日時（`i38`）と同じく、72時間で必須という扱いが脆弱性側にもそろいました。操作マニュアル（9月17日）に続き、筆者が確認した範囲で、版番号を変えずに内容が変わった2例目です。本記事の主題である「版番号だけでなく、取得日と原文を残す」ことの実例でもあります。
「発生した日時」が製品の何を指すのか、SRPへの報告とは別に必要な利用者への通知（CRA第14条(8)）とあわせて、News #12 で整理しています。
■ 【2026年9月25日 追記】Secondary ARの閲覧範囲などの訂正と補足
9月25日に公式文書を再確認し、本文を次のとおり直しました。
確認4（訂正）：Secondary ARの閲覧範囲について、FAQ質問9と操作マニュアル4.6.1の記載が、9月17日に逆方向へ書き換わりました。ただし旧版マニュアル内にも、変更後と同じ趣旨の記載が併存していた可能性が高く、それを考慮できていませんでした。詳細は確認4の訂正節をご覧ください
確認3の変更4（訂正）：発生日時が正確に分からない場合の扱いは、Glossaryに書かれていました（推定値を入れ、説明欄で推定と明記する）。「Glossaryからは判断できない」としていた記述を直し、確認できていないことの一覧から外しました
確認3（訂正）：PECの複数選択は、v1.2でも記入方法欄で認められていました。「複数選択できる書き方になった」を「説明欄が記入方法欄とそろった」に直しました
確認2（補足）：2027年12月11日は、CRA第71条(2)が定める規則全体の適用開始日です
確認2（補足）：SDKに同梱されたlwIPの問題について、SDK提供元の窓口へ報告する経路を追記しました
操作マニュアルのPDFは、中身だけが差し替わっていました。URLは同じで、版表記は `Version: 1.1`、ページの表示は `Last updated: 10 September 2026` のままです。サーバの `last-modified` は `Thu, 17 Sep 2026 14:30:33 GMT` です。版番号とページの日付だけを記録していても、この変更には気づけません。原文を保存しておく必要がある、という本記事の主題の実例です。
■ 【2026年9月13日 追記】初回公開後に本文へ足した5点
初回公開の後、同じ4文書を読み直して、本文に入れておくべき記載が5つ見つかりました。いずれも該当する節の本文へ反映済みです。ここには履歴だけ残します。
利用規約3.1.8：アクセス手段は本人専用と定められ、第三者への譲渡・売却も禁止されています。初回公開時は規約4.6.1だけを根拠に「止まるリスク」と書いていましたが、この説明では不十分でした（確認1の(3)）
利用規約4.3.4：守秘義務はアクセス終了後5年間続きます（確認1の(6)）
Glossary v1.3：重大インシデントの発生日時が、72時間の段階で `Optional` から `Required` へ変わっていました。要求が増えた側の変更を落としていました（確認3の変更4）
公式FAQ：OSSスチュワードの報告義務はCRA第24条(3)で、2027年12月11日から適用されます（確認2）
操作マニュアルと画面機能ガイダンス：9月13日の追記では、Secondary ARは自分が提出した通知と自分が作成した下書きに限られる、と記載しました（確認4）。この結論は9月25日に撤回しました
この5点はいずれも、初回公開の時点で読める記載でした。新しい改訂で増えたものではなく、筆者が保存した原文を読み切れていなかっただけです。参照した原文を保存せよと書いている記事で、その原文を読み落としていたことになります。
■ 筆者による整理（ここからはENISAの記載ではありません）
ここまでの4点から言えることを、公式文書の記載ではなく筆者の整理として書きます。
公式文書の版を、社内文書の側に記録してください。
9月4日から9月12日までの9日間で、本記事が扱った文書には次の動きがありました。
FAQ：9月7日版、9月9日版、9月10日版、9月11日版、9月12日版と、少なくとも5回
Glossary：version 1.1（9月5日）、version 1.2（9月9日）、Version 1.3（9月10日）と、5日で2版
AR登録ガイド：9月8日版、9月10日版、9月12日版（12日版は本文が10日版と同じで、日付の表示だけが変わっています。Wayback Machineの保存版で比較）
画面機能ガイダンス：9月9日版、9月12日版
利用規約：`Last updated: 10/09/2026` で公開（公開日そのものは、これ以前の保存が無いため特定できていません）
操作マニュアル：`Last updated: 10 September 2026` で公開（PDFの文書履歴では初版が9月9日。公開日そのものは特定できていません）
本記事の初回公開後も、動きは続きました。
FAQ：9月17日に再更新（`Updated: 17 September 2026`）。Secondary ARの閲覧範囲の記載が逆方向に変わり、質問32が追加されました
操作マニュアル：9月17日に、ページの `Last updated`、PDF内の `Version: 1.1`、`Document History` のいずれも変えないまま、PDFの中身が差し替わりました
2つ目の差し替えは、版番号と更新日を記録していても気づけない変更です。旧版との比較には、Wayback Machineの9月15日保存版を使いました。
報告の手順書を社内で作るなら、次の3つをやっておく必要があります。
文書名、版、更新日、取得日を手順書の中に書く。どの文書のどの版を読んで作ったかが分からないと、次に差分を取る起点がありません
取得したPDFやHTMLを、そのまま社内に保存する。版番号の記録だけでは足りません。今回確認した公式ページには旧版への導線が見当たりませんでした。原文が手元に無ければ、完全な差分を取れない場合があります
手順書を見直すときに、保存した原文と現行版を比べる。現行版だけを読み直すと、変わったことに気づけません
2つ目が要る理由は、本記事自身が示しています。筆者が今回v1.2とv1.3の差分を示せたのは、Wayback Machineに保存があったからです。保存が無い版については、完全な差分や、変更が入った正確な版を特定できませんでした（v1.1とv1.3で記載が違うこと自体は、News #9に残した記述から示せています）。Wayback Machineに保存があるかどうかは運任せです。
発行側が付けている変更マーカーも、差分検出には使えません。FAQには `[NEW]` と `[UPDATED]` の表示がありますが、筆者が確認した6つの版では次のように付け替わっていました。
`Updated: 07 September 2026` 版：`[UPDATED]` が4件、`[NEW]` が2件
`Updated: 09 September 2026` 版：`[UPDATED]` が4件、`[NEW]` が3件
`Updated: 10 September 2026` 版：`[UPDATED]` が5件、`[NEW]` が4件
`Updated: 11 September 2026` 版：`[UPDATED]` が1件のみ、`[NEW]` は0件
`Updated: 12 September 2026` 版：`[UPDATED]` が5件、`[NEW]` は0件
`Updated: 17 September 2026` 版：`[UPDATED]` が1件、`[NEW]` が1件（12日版で `[UPDATED]` だった5件は、いずれも回答本文が変わらないまま印が消えています。うち1件は質問文だけが修正されています）
マーカーが付いている質問の番号も版ごとに入れ替わります。前の版で `[UPDATED]` だった質問の印が、次の版では消えます。そのため、マーカーを追いかけても累積の差分は再現できません。
そして今回、Wayback Machineを使わず、筆者が保存した公式原文どうしを直接比較できたのは、FAQの報告期限の1件だけでした。9月11日版と9月12日版の両方を保存していたからです。逆に利用規約は、これ以前の保存が無いため公開日を特定できていません。
この整理はENISAが書いていることではありません。公開文書の更新状況から筆者が導いたものです。
■ 確認できていないこと
v1.1からv1.2へのGlossaryの差分（v1.1の保存が見つからず、変更がどちらの版で入ったか特定できない項目があります）
脆弱性側の認知時刻の欄の項目名にUTCの表記が無い理由（表記の不統一か、扱いが違うのか）
`Attack vector` の `N/A` が、実際の画面でどう見えるか（欄が表示されないのか、入力できない状態で表示されるのか）
最終報告の提出後に追加の情報が出た場合、規約4.1.8の更新義務をどの経路で果たすのか（通知は編集不可になります）
利用規約のセキュリティテストに関する事前同意を、どこへどう求めるのか（規約に手続きの記載がありません）
FAQの報告期限の記載で、何をもって措置が利用可能になったと扱うのか
他のARが提出した通知を、実際に閲覧・更新できるかどうか（9月17日のFAQと操作マニュアル4.6.1は「できる」としています。ただし、同じマニュアルの4.6.1の手順1と4.8には、新しい記載との整合性が説明されていない文言が残り、画面機能ガイダンスは旧記載のままです。挙動の変更か文書の訂正かも分かりません）
旧FAQが2026年9月11日の初期版について `Art 14 and 24(x)` を必須報告と書いていた理由（現行FAQは第24条(3)の適用開始を2027年12月11日としています）
筆者はSRPの画面を操作していません。実際の入力項目・必須の範囲・画面遷移は未検証です
公式文書は本記事の公開後も更新される可能性が高いです。実務判断の際は、必ず一次情報の最新版をご自身で確認してください。
■ 本記事の取り扱いについて（免責事項）
目的： 本記事は、公開情報をもとに、lwIP搭載製品の担当者向けにCRA報告実務の要点を整理し、注意喚起・確認ポイントの整理を目的としています。
法的助言ではありません： CRAの条文解釈や利用規約の解釈に関する法的助言ではありません。個別の義務の有無・報告要否・規約上の可否は、一次情報および法務・専門家の確認に基づいて行ってください。
自己責任： 対応の判断にあたっては、各社の事業形態・製品要件に基づき、利用者自身の責任において十分な確認を行ってください。
免責： 万一、本記事の情報に基づいて生じた損害やトラブルについて、筆者は一切の責任を負いかねます。
本記事が触れているCRAの条文番号（第14条、第15条、第16条(2)、第24条(3)、第71条(2)）は、ENISAの公開文書および Regulation (EU) 2024/2847 の記載に基づくものです。条文そのものの解釈については一次情報をご確認ください。
引用した英文は原文のままです。日本語の説明は筆者によるもので、公式訳ではありません。「筆者による整理」と明記した箇所は、ENISAが書いている内容ではなく、筆者が公開情報から導いたものです。
■ 最後に
稼働が始まったあとも、SRPの公式文書は数日単位で変わっています。今回確認した4点は次のとおりです。
利用規約が公開されました。SRPへのセキュリティテストにはENISAの事前同意が必要で、アクセスを求めた時点で規約の対象になります。アクセス手段は本人専用と定められ、守秘義務はアクセス終了後5年間続きます
製造者のCRA第14条通知以外は、現行SRPの対応外です。各国CSIRTへ直接連絡する案内が出ています。OSSスチュワードの義務は第24条(3)で2027年12月11日からです（規則全体の適用開始日と同じ日です）
Glossaryがv1.3になり、72時間の是正措置が任意へ、攻撃ベクタが早期警告では適用外へ（どちらも要求は緩みました）、提供国が無条件の必須へ、インシデントの発生日時が72時間で必須へ変わりました。重大インシデント側の時刻欄にはUTCが明記されました
55ページの操作マニュアルが公開されました。Secondary ARの閲覧範囲は、9月17日にFAQとマニュアルの記載が「同じメーカーのARは誰が提出した通知でも閲覧・更新できる」へ書き換わりましたが、画面機能ガイダンスは旧記載のままです。本記事が9月13日に書いた「Secondary ARは自分の提出分のみ」は訂正し、News #6 のポイント2の要確認も未解消に戻りました。FAQの期限の記載も緩和措置を含む文言に直っています
このうち3つ目は、News #9 で書いた内容の一部が現行版では成り立たなくなったことを意味します。4つ目は、本記事自身の記述が公開後の改訂で成り立たなくなった例です（旧版の中の反対趣旨の記載を筆者が考慮していなかった点も含みます）。担当者の体制では、確かめるまでは、別のARが報告を引き継げることを前提にせず、案件と提出状況をSRPの外でも共有しておくのが無難です。公式文書を読んで作った社内手順は、読んだ版を記録し、原文を保存しておかないと差分が取れません。SRPを使う準備で最初にやることは、画面を触ることではなく、参照した文書の版を書き留めて原文を保存することかもしれません。
lwIPは無料で手軽に製品に組み込める反面、利用する際にはバージョンや設定、既知の問題を把握しておくことが重要です。
また、商用製品のような保証付きサポートが前提ではないOSSであるため、最終的にはメーカー自身で不具合や脆弱性に対応しなければなりません。
そのため対応コストが製品出荷後に増大するリスクについても考慮しておく必要があります。
OSSであるlwIPには多くの利点がありますが、長期保守やサポート体制が重要な製品では、商用スタックを選択するケースもあります。
ただし、すでにlwIPで開発中の製品や出荷済みの製品を今から置き換えることは現実的ではありません。
そういった方に向けて、本記事の情報が、
不具合や脆弱性の早期発見
原因特定の時間短縮
対応コストの低減
の参考になれば幸いです。
今後も、lwIPの問題に対して実用的な情報を公開します。
▶ 日本語記事一覧はこちら：lwIPトラブル対策室｜日本語記事一覧
関連記事・新着のお知らせ
News #9｜SRPが表示する72時間の期限は信じてよいか｜9月11日の開始にあたり確認する4点（72時間カウンタの既知のズレと、開始直前の更新）
News #6｜CRAの脆弱性報告、9月11日開始｜SRP運用ガイドが示した6つの実務ポイント（報告の3段階と、SRPの登録・提出・画面操作）
News #7｜CRA報告はENISAのSRPだけ見ればよいのか｜加盟国4か国の公式案内を読み比べた（加盟国CSIRTごとの案内の違い）
