【lwIP】News #9｜SRPが表示する72時間の期限は信じてよいか｜9月11日の開始にあたり確認する4点
CRAの報告義務の開始日は2026年9月11日です。対象は「脆弱性が見つかったこと」ではなく、自社製品に含まれる脆弱性がその製品で積極的に悪用されていること、または自社製品のセキュリティに影響する重大インシデントを、製造者が認識したことです。その直前に、ENISAが3つの文書を更新・公開しました（公開後にさらに動きがあり、後半に追記しています）。そのうちの1つに、SRPが画面に出す72時間の期限が認知から72時間になる前に期限超過として表示される場合があるという、ENISA自身の記載があります。開始にあたって確認しておきたい4点を、一次情報から整理します。
このnoteでは、lwIPで実際に起こり得る不具合・脆弱性・再現方法・最小修正の考え方やデバッグのノウハウをシリーズで解説しています。
▶ 日本語記事一覧はこちら：lwIPトラブル対策室｜日本語記事一覧
本記事は「News」として、lwIPに関する速報・重要な動向をお届けします。News記事は、基本的に外部で公表された情報の整理・注意喚起が中心です。
■ 今回のニュース概要
CRA（サイバーレジリエンス法）の脆弱性報告義務は、2026年9月11日から適用されます。報告先となるENISAのSRP（Single Reporting Platform）について、本記事の初回公開時点（2026年9月6日）で更新・公開されていた文書は次の3つです。
CRA SRP FAQ（2026年9月4日更新）
CRA SRP Glossary（version 1.1、2026年9月5日更新）
List of CSIRTs Designated as Coordinators（2026年9月4日更新）
このうちGlossaryとCSIRT一覧は、これまでの記事で扱っていない新しい文書です。FAQは News #6 で2026年8月31日版を扱いましたが、9月4日更新版を読み直したところ、そこで扱っていなかった記載が含まれていました。
後述する72時間カウンタの記載は、Web Archiveで確認できた8月3日版にはありませんでした。ただし8月31日版の保存を確認できないため、追加された日付は特定できません。本記事では、9月4日版で確認した記載として扱います。
SRPの登録・提出・画面操作そのものは News #6、加盟国CSIRTごとの案内の違いは News #7 で扱いました。本記事はその続報で、手順へ落としておきたい4点に絞ります。報告の3段階（24時間の早期警告、72時間の通知、最終報告）の構造そのものは News #6 をご覧ください。
本記事の確度
上記3文書はすべて、2026年9月6日に筆者が原文を取得して確認しました。要約サービスや二次情報は根拠にしていません
後半の追記分（AR登録ガイド、PECガイド、Glossaryの再取得、CRA条文）は、2026年9月9日に同じ方法で確認しました
さらに後半の【2026年9月12日 追記】は、同日にAR登録ガイドを取得して確認しました。 対象は `Last updated: 10 September 2026` 版です
引用は原文（英語）をそのまま示し、日本語は筆者による説明です
lwIPのコードそのものへの影響はありません。影響するのは報告の運用手順です
稼働開始にあわせて、文書や画面がさらに更新される可能性があります。本記事は上記の日付時点の版に基づきます
■ 確認1：SRPが表示する72時間の期限を、法定期限として使わない
これが今回いちばん重要な項目です。
ENISAが書いていること
FAQに、現行リリースの72時間カウンタについて次の記載があります。
72hrs counter : In the current release, the 72hrs counter logic displays the due date/time for the 72hrs report, 48hrs after the submission of the 24hrs report. Due to this, in some cases, a notification might be displayed as overdue before 72 hours from when the manufacturer or open-source software stewards has become aware of the event. This logic will be updated in future release to start counting using instead the field ‘Date and Time when you became aware of the incident/actively exploited vulnerability’ for both AEV and SI once this field will be introduced as required.
要点は2つです。FAQは、現行リリースのカウンタが「24時間報告を提出した時刻」から48時間後を期限として表示する、と説明しています（筆者は画面を操作しておらず、FAQの記載による）。そのため、認知した時点から72時間が経つ前に、期限超過として表示される場合があります。将来のリリースでは「認知した日時」の入力欄を基準に数え直す予定、とされています。
そしてカウンタ全般について、次のようにも書かれています。
These counters should be used to provide visibility but do not replace the duty of the manufacturers and open-source software stewards Assigned Representative to comply with the obligations laid down in CRA, including the need to report upon becoming aware, without undue delay and in any event within the timeline set out in Article 14.
カウンタは見通しを与えるためのものであって、CRAの義務を置き換えるものではない、という位置づけです。
筆者による整理（ここからはENISAの記載ではありません）
以下は、上の記載をもとにした時刻関係の整理です。ENISAが書いている内容ではなく、筆者が導いたものです。
認知時刻を T、24時間報告がSRP上で提出された時刻を S とします。ここでは便宜上、S を法的にも提出とみなせる時刻と仮定します（前述のとおり、S が送信操作の時刻か受付完了の時刻かは確認できていません）。
CRAが定める72時間の上限：T ＋ 72時間
現行のSRPが表示する期限：S ＋ 48時間
差を取ると、次のようになります。
（S ＋ 48時間）−（T ＋ 72時間）＝ S −（T ＋ 24時間）
つまり、S が T ＋ 24時間以内であれば、表示される期限は条文が定める72時間の上限以前になります。両者が一致するのは、24時間報告をちょうど期限ぎりぎりに出したときだけです。たとえば認知から6時間後に早期警告を提出すると、画面上の期限は、法定の上限より18時間早い時刻になります。
なお T ＋ 72時間は条文が定める上限であって、そこまで待ってよいという意味ではありません。引用したENISAの記載にも `without undue delay`（不当に遅滞することなく）とあります。
S が T ＋ 24時間を超えている場合、この比較はそもそも期限管理に使えません。上の仮定のもとでは、その時点で24時間の上限を超えていることになるためです。
この整理をそのまま信用しないでください
上の計算は、次の前提がすべて成り立つ場合にのみ意味を持ちます。そして後半の4つは、公開されている文書からは確認できませんでした。
T が、法的な意味での製造者の認知時刻と一致していること
S が、カウンタが実際に採用している基準時刻であること（送信操作の時刻か、受付完了の時刻かは不明）
S が、法的にも24時間報告の提出時刻として扱われること
再提出や、CSIRTによる無効化のあとの再処理で、基準時刻が変わらないこと
時刻表示やタイムゾーンの扱いに、別の問題がないこと
したがって、「期限内に出していればカウンタは常に安全側」と実装全体について言い切ることはできません。
手順に落とすこと
結論は単純です。期限は認知時刻から社内で独立に管理し、SRPの画面表示は補助として扱ってください。
News #6 で扱ったとおり、24時間の起算点は「自社製品に含まれる脆弱性が積極的に悪用されていること、または自社製品のセキュリティに影響する重大インシデントを、製造者が認識した時点」です。自社製品への攻撃を直接観測した場合だけではありません。第三者からの通報が認知の契機になることもあります。ただし、他社製品や別の環境で悪用されたという事実だけで、自社製品について直ちに報告義務が生じるわけではありません。News #4 で扱ったとおり、脆弱なコードが自社製品では到達不能である場合や、自社製品で実際に悪用されていない場合、その完成品の製造者に当該脆弱性の報告義務は生じません。
記録すべきは、社内で報告要否を確定した時刻ではありません。自社製品に含まれる脆弱性がその製品で積極的に悪用されていること、または自社製品のセキュリティに影響する重大インシデントを、製造者が認識した時刻です。この時刻を記録に残す仕組みが、画面のカウンタより先に必要です。
なお最終報告は、脆弱性では是正・緩和策が利用可能になってから14日以内、重大インシデントでは72時間通知の提出から1か月以内で、24時間・72時間の通知とは起点が異なります。
■ 確認2：24時間の段階で必須になる項目を、社内テンプレートに入れておく（Glossary v1.1時点）
【更新】以下はGlossary version 1.1 時点の記録です。現行の `Version 1.3` では、実施した是正・緩和措置の72時間欄が `Optional` へ、攻撃ベクタの早期警告欄が `N/A` へ変わり、重大インシデントの発生日時の72時間欄が `Required` へ変わっています。実務用のテンプレートには以下をそのまま使わないでください。News #10 と現行のGlossaryをご確認ください。
新しく公開されたGlossaryは、SRPの入力フィールドを1件ずつ、意味・記入例・期待される形式・そして各段階で必須かどうかまで一覧化した文書です。version 1.1、2026年9月5日更新と明記されています。
先に注意点を1つ
Glossaryが示している `Required` は、SRPというプラットフォーム上で、その段階の入力を完了するために必要かどうかです。CRA条文が定める法的な必須記載事項と同じものではありません。両者を混同しないでください。以下も、あくまで画面上の入力要件として読んでください。
早期警告までに事前準備しておきたい必須項目の例
社内テンプレートに先に用意しておく価値が高いのはここです。全項目ではなく、事前に集めておかないと24時間に間に合いにくいものを挙げます。
通知の種別（脆弱性か、重大インシデントか）
タイトル（製品と事象が分かる短い名称。255文字まで）
概要（何が起きたか、影響製品とバージョン、把握している影響、緩和の状況。4000文字まで）
製品バージョン：影響するバージョン・リリース・ビルド・ファームウェアリビジョンを、範囲が分かる形で書く（255文字まで）
製品が提供されている加盟国（関係CSIRTを特定するために使われます。担当CSIRT（CDaC）はプラットフォームが自動的に表示します）
製造者名は、登録時の情報からプラットフォームが自動的に埋めます。
lwIP搭載製品でいうと、24時間の段階で「どの製品のどのバージョンが影響するか」を書けるかどうかが分かれ目になります。同梱しているlwIPのバージョンと、それを載せた製品・ファームウェアの対応表が手元にあるかどうか、ということです。これは News #6 で書いた「準備の重心は自社製品側の情報整備に寄る」という話と同じ結論に着きます。
72時間通知と最終報告で必須になる項目の例
実施した是正・緩和措置（早期警告の段階では任意、72時間と最終報告では必須）
早期警告の段階では、この欄への実施済み措置の記入は必須ではありません。一方、72時間の通知と最終報告では必須になります。（Glossary上の入力要件の話であり、法的に何も対応しなくてよいという意味ではありません。）「72時間かけて調べてからまとめて報告」ができないことは News #6 のポイント4で扱いました。今回の情報は、その72時間の時点で何を書ける状態にしておくべきかを具体化するものです。
必須と誤解しやすいが、全段階で任意のもの
攻撃ベクタ（どの経路で悪用・侵入され得るか。インタフェース、アクセス経路、プロトコル、利用者の操作など）
技術的には重要な項目ですが、Glossary上はすべての段階で任意です。攻撃ベクタ欄が未入力であることだけを理由に、提出が止まるわけではないと読めます（Glossaryの表記からの読み取りで、筆者は実際の画面を操作していません）。
全フィールドの一覧は本記事には転載しません。分量が多いうえ、公式文書が更新されれば内容が変わります。実際に社内テンプレートを作るときは、上記のGlossary（本記事の確認時点では version 1.1）の最新版を直接ご確認ください。
■ 確認3：9月11日の初期版は必須報告のみ。任意通知とAPIを前提にしない
FAQに、初期リリースの機能制限が明記されました。
On the 11th of September the platform will ONLY allow the submission of mandatory reporting fulfilling Art 14 and 24(x). Voluntary reporting per art15 will not be possible.
原文の表記は `Art 14 and 24(x)` です。FAQは、9月11日の初期版が受け付けるのはFAQが必須報告と呼んでいるものだけだと説明しています。`24(x)` の具体的な参照先は確認できないため、本記事では解釈しません（FAQの他の箇所では `Article 24(3)` という書き方がされています）。第15条による任意の報告は提出できず、将来のフェーズで提供される予定とされています。時期は示されていません。
APIも初期版では提供されず、画面から提出する必要があります。この点は News #6 で2026年8月3日版のFAQをもとに扱っており、方針が変わっていないことの確認になります。
なお News #7 では、フィンランドのNCSC-FIの案内をもとに「APIの提供は2027年春の見込み」と書きました。ENISA側は時期を示していません。2027年春という見込みは、あくまで加盟国側の案内に由来する情報です。
■ 確認4：自社に関係し得る指定CSIRTの公式連絡先を確認する（提出先とは別です）
ENISAが、EU加盟国の指定CSIRT（CSIRTs designated as coordinators）の連絡先一覧を公開しました。2026年9月4日更新です。
これは指定CSIRTの公式連絡先を確認するためのもので、法定通知の提出先URLの一覧ではありません。通知はSRPから提出します。Glossaryの説明では、担当CSIRT（CDaC）はプラットフォームが自動的に表示し、製品を提供している加盟国は利用者が追加で選べる形になっています。掲載されているURLもCRA専用の窓口とは限らず、一般的な連絡先ページが含まれます。
News #7 で扱った「オランダの国内ポータルとSRPの関係」は、この一覧が出たあとも確認できていません。担当CSIRTがどう決まるかも同記事で扱っており、複数拠点やEU域外に本社がある場合は未確定のままです。
本記事で勧める使い方は、自社に関係し得る指定CSIRTと公式の連絡先を、事前に把握しておくことです。照会先を探すところから始めなくて済むようにする、という趣旨です。ただし、この連絡先へ連絡することがSRP経由の法定通知を代替するとは確認できていません。SRPに障害が出た場合の正式な代替手順も未確認です。実際に障害が起きたときは、ENISAまたは担当CSIRTが示す最新の手順をご確認ください。上に書いたとおり、担当CSIRTを自社で特定しきれない場合があります。その場合は、候補となるCSIRTの連絡先を控えておく、という使い方になります。
■ 【2026年9月9日 追記】SRPのURL・MFA・PECに関する開始直前の更新
本記事の公開後、ENISA側に動きがありました。2026年9月9日に原文を取得して確認したものです。タイトルの「4点」は初回公開時の中心項目で、ここから先は日付を付けた追加情報です。
SRP本体のURLを確認しました
`https://portal.cra-srp.enisa.europa.eu` です。AR登録ガイドの2026年9月8日更新版に記載されています。News #6 では未確定事項として扱っていた項目です。公表された時期は特定できていません。
EU LoginにMFAが必要と記載されています
同じガイドに、次の記載があります。
An EU Login account with multi-factor authentication (MFA) is needed in order to access the platform. ARs that have already an EU Login account with no MFA enabled should enable MFA before their first access to the platform.
EU Loginのアカウントを持っているだけでは足りず、MFAを有効にしておく必要があります。すでにアカウントがある場合も、初回アクセスの前に有効化するよう求められています。担当者のアカウント状態は、すぐに確認できる項目です。
ここで確認するのは EU Login 側のMFAの状態です。News #6 のポイント1で扱った「SRPへの事前登録は推奨されていない」という話とは別で、SRPへ先に登録することを勧める趣旨ではありません。
Secondary AR（副担当）の登録手順にも関係する記載があります。以下は同ガイドの `Pre-conditions` から関係する項目を抜粋したものです。
You have an active EU Login account with MFA enabled
You have received a valid SRP email invitation initiated by a Primary AR
The Primary AR is a validated user
一方で、validation そのものが通知提出の前提ではないことは、現行のAR登録ガイドにも明記されています。
Validation by the CSIRT Designated as Coordinator (CDaC) of whether an AR is authorised to submit notifications on behalf of a specific manufacturer takes place after registration (described below) and is not a prerequisite for submitting a notification.
つまり 少なくとも Primary AR は、validation を待たずに通知を提出できます。他方、Secondary AR の登録手順では、Primary AR が validated user であることが `Pre-conditions` として示されています。この条件が招待を送る時点と登録を進める時点のどちらに掛かるかまでは、ガイドの記載からは区別できませんでした。（この点は、その後の改訂で記載が変わっています。後述の【2026年9月12日 追記】をご覧ください）
なお、MFAとSecondary ARの `Pre-conditions` に関するこれらの記載が、2026年9月8日の更新で追加されたのか、それ以前から書かれていたのかは確認できていません。
「Particular Exceptional Circumstances (PEC)」のガイドが公開されています
PECガイド（特定の例外的状況）です。2026年9月6日に筆者がSRPのページ一覧を取得したときには掲載されておらず、9月9日の確認で見つけました。一覧に載っていなかったというだけで、当時ページ自体が存在しなかったかどうかは確認していません。
ガイドの説明では、CRA第16条(2)の第3副段落にもとづく仕組みで、AEV（積極的に悪用されている脆弱性）の72時間通知で使うものとされています。
If PEC is invoked in the 72-hour Notification, the dissemination status becomes '72h Submitted under PEC'.
72時間通知でPECを主張した場合、通知の全文がENISAへ同時には共有されません。展開が必要か、また可能かを判断し、他の関係CSIRTやENISAへ手動で共有するのは担当CSIRT（CDaC）の役割だ、とガイドは説明しています。
ガイドは「3つのケースのうち1つ」と書きながら、その内容をページ上には列挙していません。そこで筆者がCRA条文（Regulation (EU) 2024/2847）の第16条(2)第3副段落を確認しました。製造者が通知で次のいずれかを示した場合、とされています。
(a) that the notified vulnerability has been actively exploited by a malicious actor and, according to the information available, it has been exploited in no other Member State than the one of the CSIRT designated as coordinator to which the manufacturer has notified the vulnerability;
(b) that any immediate further dissemination of the notified vulnerability would likely result in the supply of information the disclosure of which would be contrary to the essential interests of that Member State; or
(c) that the notified vulnerability poses an imminent high cybersecurity risk stemming from the further dissemination;
要するに、(a) 通知された脆弱性が悪意ある者によって積極的に悪用されており、かつ利用可能な情報によれば、通知先の指定CSIRTが属する加盟国以外では悪用されていない場合、(b) 直ちにさらに展開すると、開示が当該加盟国の不可欠な利益に反する情報の提供になる可能性が高い場合、(c) さらに展開すること自体が差し迫った高いサイバーセキュリティリスクを生む場合の3つです。この場合にENISAへ同時に渡るのは、通知があったという事実・製品の一般的な情報・悪用の一般的な性質・セキュリティ上の理由が提起されたという事実に限られる、と条文は定めています。
役割は分かれています。PECに該当すると通知で示すのは製造者の側で、その後に展開が必要か、また可能かを判断するのは担当CSIRT（CDaC）の側です。自社の事案がこの3つに当たるかどうかの判断は、法務部門にご確認ください。本記事は条文とガイドの記載を示すにとどめます。
■ 【2026年9月12日 追記】Secondary ARの招待に条件と期限があります
稼働開始の翌日にAR登録ガイドを取り直したところ、CRA SRP Guidance - AR User Registration が `Last updated: 10 September 2026` へ改訂されていました。本記事の9月9日の追記が読んだのは `08/09/2026` 版です。
現行版で、Secondary AR（副担当）に関する記載を2点確認しました。どちらも、バックアップ担当者を用意する実務に直接効きます。うち1点は、本記事の9月9日の追記が読んだ版から文言が変わっています。
招待できるのは「Verified」になったPrimary ARだけです
9月9日の追記では、Secondary AR の `Pre-conditions` にある `The Primary AR is a validated user` について、この条件が招待を送る時点と登録を進める時点のどちらに掛かるかは区別できなかったと書きました。現行版は、この項目の文言が次のように変わっています。
The feature to invite a Secondary AR is available only to a "Verified" Primary AR
（Secondary ARを招待する機能は、「Verified」なPrimary ARだけが利用できる、という趣旨）
招待機能そのものが Verified 限定であると読める記載になりました。前回「区別できませんでした」と書いた点は、この記載で解消されたものとして扱います。
一方で、Primary AR 自身が validation を待たずに通知を提出できることは変わっていません。9月9日の追記で引用した次の記載は、現行版にもそのまま残っています。
Validation by the CSIRT Designated as Coordinator (CDaC) of whether an AR is authorised to submit notifications on behalf of a specific manufacturer takes place after registration (described below) and is not a prerequisite for submitting a notification.
つまり、通知そのものは validation を待たずに提出できるのに対し、SRP上でSecondary ARへ招待を送る操作のほうは、Primary ARが「Verified」になった後でなければ行えない、という組み合わせになります。担当者の選定やEU LoginとMFAの準備まで待つ必要があるという記載ではありません。SRP上の招待操作だけが後になります。
招待は7日で失効します
もう1点、招待メールに期限があることが明記されています。
If registration is not completed within 7 days of the invitation being sent, the invitation expires and the user status becomes “Invitation Expired” in the SRP.
（招待の送信から7日以内に登録が完了しない場合、招待は失効し、SRP上のユーザー状態は「Invitation Expired」になる、という趣旨）
招待リンクを開いた側から見た記載もあります。
If the invitation link has expired because more than 7 days have passed since the SRP sent the invitation, you will be redirected to a page displaying an error message.
（SRPが招待を送ってから7日を超えている場合、招待リンクは失効しており、エラーメッセージのページへ転送される、という趣旨）
7日は登録にかかる時間ではなく、登録を完了するまでの期限です。実際にどれくらいかかるかは、ガイドには書かれていません。招待を送ったら、相手が7日以内に登録を完了したかどうかを確認する手順が要ります。登録を完了しないまま7日を過ぎた招待は、リンクを開いてもエラーメッセージのページへ転送されます。なお、失効したあとに招待を送り直せるかどうかについては、AR登録ガイドにも画面機能ガイダンスにも記載を見つけられませんでした。
なお、SRPへの登録自体をいつ行うかは、News #6 のポイント1で扱った「ENISAは事前登録を推奨していない」という方針とあわせた判断になります。本記事はどちらを選ぶべきかまでは述べません。
どこまでが確認できていて、どこからが不明かを分けておきます
1点目の `Pre-conditions` については、本記事の9月9日の追記が旧版の文言（`The Primary AR is a validated user`）を記録しているため、文言が変わったこと自体は確認できます。ただし `08/09/2026` 版を保存していないため、その変更が9月10日の改訂で入ったのか、それ以前の版で既に入っていたのかは特定できません。
2点目の7日での失効については、旧版を保存していない以上、新しく追加された記載なのか、以前から書かれていたのかが分かりません。本記事は「現行版にこう書かれている」という事実として扱い、「9月10日に変わった」とは書きません。
いずれも、2026年9月12日に取得した `Last updated: 10 September 2026` 版の記載です。
なお本記事の確認2は、Glossaryの `version 1.1` をもとに段階別の必須項目を整理しています。その後 `Version 1.3` で、入力要件が変わっていることを確認しました。実際に社内テンプレートを作るときは、News #10 と現行のGlossaryをあわせてご確認ください。
なお、現行版では「事前登録を推奨しない」旨の記載（`rather than registering pre-emptively`）も確認しましたが、この方針自体は News #6 のポイント1で扱った内容と同じため、本記事では繰り返しません。
■ 確認できていないこと
カウンタが基準にしている「submission」が、送信操作の時刻なのか、受付完了の時刻なのか
再提出や、CSIRTによる無効化のあとの再処理で、カウンタの基準時刻がどうなるか
時刻表示やタイムゾーンの扱い（その後、Glossary v1.3で重大インシデント側の日時欄に `(UTC time)` が明記されたことを確認しました。一方、脆弱性の認知時刻の欄にはUTCの表記が無く、同じGlossaryの脚注でその欄自体が次期リリースで利用可能になるとされています。詳細は News #10 をご覧ください）
「mijn.NCSC.nl」とSRPの関係（News #7 から継続）
任意通知とAPIが提供される時期
AR登録ガイドのMFA・Secondary AR条件が、どの改訂で追加されたものか（9月8日版・9月10日版のいずれについても、直前の版を保存していないため特定できていません）
7日を過ぎて失効した Secondary AR の招待を、送り直せるかどうか（AR登録ガイドにも画面機能ガイダンスにも記載を見つけられませんでした）
自社の個別事案がPECの3つのケースのいずれかに該当するかどうか（条文上のケースは確認済みだが、当てはめは法務判断）
PECを主張した場合に、担当CSIRTが通知全文をいつ・どの範囲へ展開すると判断するか
`Art 14 and 24(x)` の `24(x)` が指すもの（その後の公式FAQは、OSSスチュワードの報告義務をCRA第24条(3)と明記し、2027年12月11日から適用されるとしています。旧表記は第24条(3)を指していた可能性が高いと考えられますが、2026年9月11日の初期版についてこれを必須報告と書いていた理由は確認できていません。詳細は News #10 をご覧ください）
SRPの実画面が稼働開始後にどう変わったか（公開文書の変更は News #10 で確認しました）
最後の点は特に重要です。本記事の初回公開部分は2026年9月6日、追記は9月9日と9月12日に原文を確認した内容に基づいています。稼働開始後の現在の内容を、FAQ・Glossary・AR登録ガイド・PECガイド・SRPの画面・担当CSIRTの案内について、もう一度ご自身で確認してください。
■ 本記事の取り扱いについて（免責事項）
本記事は、ENISAが公開している一次情報をもとに整理したものです。法的な助言ではありません。CRAへの適合判断・報告義務の有無・報告内容については、必ず自社の法務部門および担当CSIRTにご確認ください。
引用した英文は原文のままです。日本語の説明は筆者によるもので、公式訳ではありません。「筆者による整理」と明記した箇所は、ENISAが書いている内容ではなく、筆者が公開情報から導いたものです。
本記事の情報を利用したことによって生じたいかなる損害についても、筆者は責任を負いません。
■ 最後に
報告義務の開始日は2026年9月11日です。
初回公開時に確認した3文書から手順に落とせることは、多くありません。次の4点です。
画面のカウンタを法定期限の管理に使わない
24時間の段階で製品とバージョンを書ける状態にしておく
任意通知とAPIを初期版の手順に組み込まない
自社に関係し得る指定CSIRTの公式連絡先を確認しておく
これに加えて、9月9日の追記で判明した情報が次のとおりです。
SRP本体のURLは `https://portal.cra-srp.enisa.europa.eu`
EU LoginはMFAが必要。初回アクセスの前に、担当者のアカウント状態を確認しておく
AEVの72時間通知には、PEC（特定の例外的状況）として通知全文の展開を制限する扱いがある。該当すると示すのは製造者側、その後の展開を判断するのは担当CSIRT側
さらに、9月12日の追記で判明した情報が次のとおりです。
Secondary AR を招待できるのは「Verified」になったPrimary ARだけ（9月9日の追記で示した `Pre-conditions` は現行版で文言が変わり、「条件が掛かる時点を区別できない」とした点は解消）
招待は送信から7日以内に登録を終えないと失効し、ユーザー状態は「Invitation Expired」になる。招待を送ったあと、相手が登録を完了したかを確認する手順が要る（失効後に送り直せるかは記載が見つからず要確認）
初回公開時の4点のうち特に1つ目は、ENISA自身が現行リリースの既知の挙動として書いています。画面が期限超過を示していなくても、あるいは示していても、24時間と72時間の期限は、報告対象となる事象を製造者が認識した時刻を基準に進みます。CRAが求めているのは「不当に遅滞することなく、遅くとも定められた期限内に」報告することです。社内で時刻を記録する仕組みのほうが先です。
lwIPは無料で手軽に製品に組み込める反面、利用する際にはバージョンや設定、既知の問題を把握しておくことが重要です。
また、商用製品のような保証付きサポートが前提ではないOSSであるため、最終的にはメーカー自身で不具合や脆弱性に対応しなければなりません。
そのため対応コストが製品出荷後に増大するリスクについても考慮しておく必要があります。
OSSであるlwIPには多くの利点がありますが、長期保守やサポート体制が重要な製品では、商用スタックを選択するケースもあります。
ただし、すでにlwIPで開発中の製品や出荷済みの製品を今から置き換えることは現実的ではありません。
そういった方に向けて、本記事の情報が、
不具合や脆弱性の早期発見
原因特定の時間短縮
対応コストの低減
の参考になれば幸いです。
今後も、lwIPの問題に対して実用的な情報を公開します。
▶ 日本語記事一覧はこちら：lwIPトラブル対策室｜日本語記事一覧
関連記事・新着のお知らせ
News #6｜CRAの脆弱性報告、9月11日開始｜SRP運用ガイドが示した6つの実務ポイント（報告の3段階と、SRPの登録・提出・画面操作）
News #7｜CRA報告はENISAのSRPだけ見ればよいのか｜加盟国4か国の公式案内を読み比べた（加盟国CSIRTごとの案内の違い）
