From 07efe62f1695b21e93d1a573ac4ca4aee60ac6ba Mon Sep 17 00:00:00 2001 From: Sameeh Jubran Date: Fri, 17 Jul 2026 15:19:10 +0300 Subject: [PATCH 1/2] cra-kit: correct Art. 14 reporting mechanics; drop deleted ROADMAP refs Fix a systematic inaccuracy across the kit: Art. 14 reports are not sent "to ENISA" directly. They are filed via the ENISA Single Reporting Platform (SRP) to the CSIRT designated as coordinator, with ENISA notified simultaneously (Art. 14/16), and fixed vulnerabilities are published to the EUVD. - vulnerability-handling-process.md: add "how a report is filed" (SRP -> CSIRT + ENISA -> EUVD) section; add the severe-incident track (Art. 14(3), 1-month final report); reframe on-call from a staffing gap to follow-the-sun coverage plus a compliance commitment; update diagram, SLA table, and references. - Link the EU Authorised Representative appointment to the coordinator-CSIRT reporting end-point (Art. 14(7)) in eu-authorised-representative.md. - Correct "notify ENISA" / "24h ENISA reporting" wording in the shortlist, cheat sheet, glossary, slide outline, and SKILL.md. - Add SRP / CSIRT / EUVD glossary entries; tighten support-period wording to match Art. 13(2) (at least 5 years unless shorter expected lifetime). - Remove internal-correspondence detail from conformity-assessment-route.md. - Delete ROADMAP.md and remove all remaining references to it. Signed-off-by: Sameeh Jubran --- cra-kit/CRA-Cheat-Sheet.md | 4 +- cra-kit/CRA-Compliance-Shortlist.md | 4 +- cra-kit/CRA-Supply-Chain-Glossary.md | 9 ++- cra-kit/README.md | 6 +- cra-kit/ROADMAP.md | 43 ----------- cra-kit/SKILL.md | 2 +- .../wolfssl-5.9.1.cbom-draft.cdx.json | 2 +- cra-kit/presentations/SLIDE-OUTLINE.md | 2 +- .../wolfssl-inc-auditor-packet/00-INDEX.md | 2 +- cra-kit/wolfssl-inc-auditor-packet/README.md | 2 +- .../conformity-assessment-route.md | 6 +- .../eu-authorised-representative.md | 1 + .../support-period-policy.md | 2 +- .../vulnerability-handling-process.md | 77 +++++++++++++------ 14 files changed, 74 insertions(+), 88 deletions(-) delete mode 100644 cra-kit/ROADMAP.md diff --git a/cra-kit/CRA-Cheat-Sheet.md b/cra-kit/CRA-Cheat-Sheet.md index 16dcd3552..180f82a4a 100644 --- a/cra-kit/CRA-Cheat-Sheet.md +++ b/cra-kit/CRA-Cheat-Sheet.md @@ -26,7 +26,7 @@ Requires a wolfSSL tree with SBOM support (`make sbom` / `scripts/gen-sbom`). | **1. Know your components** | Product SBOM + vuln process for whole product | Component SBOMs, advisories, updates — **this kit** | | **2. Secure boot** | Trusted firmware + update path | **wolfBoot** | | **3. Data in transfer** | Secure protocols for remote/cloud traffic | **TLS**, **SSH**, **MQTTS**, … | -| **4. Vulnerability handling & reporting** | Published CVD policy + `security.txt`; 24h ENISA reporting (Art. 14); on-call coverage | Reference templates: wolfSSL [`security.txt`](https://www.wolfssl.com/.well-known/security.txt) + [CVD policy](https://www.wolfssl.com/.well-known/vulnerability-disclosure-policy.txt); advisories; CNA | +| **4. Vulnerability handling & reporting** | Published CVD policy + `security.txt`; 24h reporting via the **SRP** to your coordinator CSIRT + ENISA (Art. 14/16); on-call coverage | Reference templates: wolfSSL [`security.txt`](https://www.wolfssl.com/.well-known/security.txt) + [CVD policy](https://www.wolfssl.com/.well-known/vulnerability-disclosure-policy.txt); advisories; CNA | Detail: [CRA-Compliance-Shortlist.md](CRA-Compliance-Shortlist.md) @@ -67,7 +67,7 @@ Detail: [CRA-Compliance-Shortlist.md](CRA-Compliance-Shortlist.md) | **VEX** | **You** (+ scanner) | Advisories only | | **bomsh** | **wolfSSL** (optional) | **Yes**, Linux host only | -Details: [CRA-Supply-Chain-Glossary.md](CRA-Supply-Chain-Glossary.md) · roadmap: [ROADMAP.md](ROADMAP.md) +Details: [CRA-Supply-Chain-Glossary.md](CRA-Supply-Chain-Glossary.md) --- diff --git a/cra-kit/CRA-Compliance-Shortlist.md b/cra-kit/CRA-Compliance-Shortlist.md index 96d83a5e5..21a35b0bc 100644 --- a/cra-kit/CRA-Compliance-Shortlist.md +++ b/cra-kit/CRA-Compliance-Shortlist.md @@ -40,7 +40,7 @@ CRA is **not only about software inventory** — it also concerns **data** movin |----------------------------|----------------------| | Map **remote processing** and **connectivity** in your product (cloud, OTA, admin interfaces, telemetry) | Implementations of **state-of-the-art** secure protocols, for example: | | Use **current cryptography** and **secure protocols** for data in transfer; document what is enabled in **your** build | **TLS** (wolfSSL), **SSH** (wolfSSH), **MQTTS** (wolfMQTT), and related stacks | -| Reflect enabled algorithms in **your** product documentation / SBOM / crypto inventory | Build properties in CycloneDX today (`wolfssl:build:*`); formal CBOM profile: **roadmap** — [ROADMAP.md](ROADMAP.md) | +| Reflect enabled algorithms in **your** product documentation / SBOM / crypto inventory | Build properties in CycloneDX today (`wolfssl:build:*`); formal CBOM profile: **roadmap** | --- @@ -55,7 +55,7 @@ operational capacity**, not a one-time deliverable. |----------------------------|----------------------| | Publish a **Coordinated Vulnerability Disclosure (CVD) policy** and a working security contact (`security.txt` per RFC 9116) so researchers can reach you | Reference templates: wolfSSL's [`security.txt`](https://www.wolfssl.com/.well-known/security.txt) and [CVD policy](https://www.wolfssl.com/.well-known/vulnerability-disclosure-policy.txt) | | Operate a **vulnerability handling process** with named owners and stated response targets | wolfSSL [security advisories](https://www.wolfssl.com/docs/security-vulnerabilities/) for libraries you ship; wolfSSL is a CVE Numbering Authority | -| Notify **ENISA within 24 hours** when a vulnerability in your product is **actively exploited** (Art. 14); follow up at 72 hours and a final report at 14 days | wolfSSL handles ENISA reporting for **wolfSSL libraries placed on the EU market by wolfSSL Inc.**; coordinate with us on shared advisories | +| File via the **Single Reporting Platform** (to your coordinator CSIRT + ENISA) **within 24 hours** when a vulnerability in your product is **actively exploited** (Art. 14/16); follow up at 72 hours and a final report at 14 days | wolfSSL handles reporting for **wolfSSL libraries placed on the EU market by wolfSSL Inc.**; coordinate with us on shared advisories | | Maintain **on-call coverage** including weekends and holidays so the 24-hour clock can be met at any time | — | This pillar is **not satisfied by SBOM artefacts alone** — it requires diff --git a/cra-kit/CRA-Supply-Chain-Glossary.md b/cra-kit/CRA-Supply-Chain-Glossary.md index c310828bf..3f3b764ae 100644 --- a/cra-kit/CRA-Supply-Chain-Glossary.md +++ b/cra-kit/CRA-Supply-Chain-Glossary.md @@ -52,7 +52,7 @@ flowchart LR | **PURL** | **Package URL** | Standard ID like `pkg:github/wolfSSL/wolfssl@v5.9.1` — helps tools match components. wolfSSL ships PURLs in both `github` (canonical, resolves in OSV / GHSA / Snyk / Trivy) and CPE forms. | | **CPE** | **Common Platform Enumeration** | Standard ID like `cpe:2.3:a:wolfssl:wolfssl:…` — used by many vulnerability databases. | | **VEX** | **Vulnerability Exploitability eXchange** | CycloneDX-side signal: “this CVE does/doesn’t apply to our build.” Often layered on top of SBOM in security tools. | -| **CBOM** | **Cryptographic Bill of Materials** | Inventory of **crypto algorithms/keys/modules** (beyond generic SBOM). Today: `wolfssl:build:*` in CycloneDX; formal CBOM: see [`ROADMAP.md`](ROADMAP.md). | +| **CBOM** | **Cryptographic Bill of Materials** | Inventory of **crypto algorithms/keys/modules** (beyond generic SBOM). Today: `wolfssl:build:*` in CycloneDX; formal CBOM: on the roadmap. | | **bomsh** | wolfSSL **make** target | Runs **OmniBOR** provenance: proves **how** the library binary was built from sources (**Linux host only**). | | **OmniBOR** | Omni **Bill of Resources** | Merkle DAG of build inputs/outputs; stored under `omnibor/`. | | **gitoid** | Git-object-style ID | Hash pointer (`gitoid:blob:sha1:…`) into the OmniBOR graph; appears in `omnibor.*.spdx.json`. | @@ -82,8 +82,11 @@ that no SBOM tool can satisfy. **Not legal advice** — engage CRA counsel. | **Declaration of conformity** | Art. 28 | Manufacturer's signed statement of CRA compliance. Names the product, lists applicable EU acts, identifies the manufacturer (and EU AR if applicable). | | **Importer** | Art. 19 | EU entity placing a non-EU product on the EU market. Carries CRA obligations parallel to the manufacturer (verify CE mark, retain AR contact, assist regulators). | | **Distributor** | Art. 20 | Party in the supply chain making the product available on the EU market without altering it. Lighter obligations than importer/manufacturer, but must verify CE mark and assist regulators. | -| **Support period** | Art. 13(2), 13(8) | Minimum duration during which the manufacturer must provide **free security updates**. Default: at least **5 years** (or the product's expected lifetime if longer). Must be declared in the technical documentation. | -| **ENISA** | Art. 14 | EU Agency for Cybersecurity. Recipient of the **24-hour** early-warning report when a vulnerability in your product is **actively exploited**, plus 72-hour update and 14-day final report. | +| **Support period** | Art. 13(2), 13(8) | Minimum duration during which the manufacturer must provide **free security updates**. Default: at least **5 years**, unless the product is expected to be in use for a shorter period (and longer where the expected lifetime is longer). Must be declared in the technical documentation. | +| **ENISA** | Art. 14, 16 | EU Agency for Cybersecurity. Operates the **Single Reporting Platform (SRP)**; manufacturers file through it and reports reach the **coordinator CSIRT** with ENISA notified **simultaneously** — the **24-hour** early-warning when a vulnerability is **actively exploited**, plus 72-hour update and 14-day final report. | +| **SRP** (Single Reporting Platform) | Art. 16 | ENISA-operated platform (live **11 Sep 2026**) where manufacturers file Art. 14 reports once; routes to the coordinator CSIRT + ENISA and on to affected Member States. | +| **CSIRT** (designated as coordinator) | Art. 14(7) | National incident-response team that receives your Art. 14 report via the SRP and disseminates it. Determined by your EU main establishment — or, for non-EU manufacturers, your **Authorised Representative's** Member State. | +| **EUVD** (European Vulnerability Database) | Art. 16(2) / NIS2 | ENISA's public database where **fixed** vulnerabilities reported via the SRP are published; makes disclosure timelines verifiable. | | **CNA** | (CVE programme) | **CVE Numbering Authority** — organisation authorised to assign CVE IDs within its scope. wolfSSL is a CNA for wolfSSL libraries. | For execution detail on these obligations, see [`CRA-Compliance-Shortlist.md`](CRA-Compliance-Shortlist.md) "Beyond this kit (structural CRA obligations)". diff --git a/cra-kit/README.md b/cra-kit/README.md index 5d85d0a4c..274b3674f 100644 --- a/cra-kit/README.md +++ b/cra-kit/README.md @@ -26,7 +26,6 @@ reference templates for **your** product. | [`CRA-Cheat-Sheet.md`](CRA-Cheat-Sheet.md) | **Who provides what** — you vs wolfSSL (print/PDF) | | [`CRA-Supply-Chain-Glossary.md`](CRA-Supply-Chain-Glossary.md) | Full terminology (**self-contained in this kit**) | | [`SKILL.md`](SKILL.md) | **AI playbook** — agent checklist, scripts, Cursor install | -| [`ROADMAP.md`](ROADMAP.md) | SBOM / CBOM / VEX / bomsh / CSAF — today vs roadmap | | [`auditor-packet/`](auditor-packet/) | **Customer-side worked example** — fictional Acme Connect Gateway + wolfSSL SBOM samples | | [`wolfssl-inc-auditor-packet/`](wolfssl-inc-auditor-packet/) | **Manufacturer-side filings** — what wolfSSL Inc. itself ships under CRA | @@ -72,8 +71,6 @@ separate **wolfSSL source tree** (with SBOM support) to **regenerate** component | **CBOM** | Crypto algorithms / modules | **You**; we **signal** | **Partial** — `wolfssl:build:*` in CycloneDX | Formal `cryptographic-asset` | | **OmniBOR / bomsh** | How the library binary was built | **wolfSSL** (optional) | **Yes** — Linux **host** only | Same | -Details: [`ROADMAP.md`](ROADMAP.md). - **Plain summary:** SBOM = what’s inside. Crypto build properties = what crypto you compiled in (CBOM direction). bomsh = how the library was built (optional). Product SBOM = your job. @@ -241,8 +238,7 @@ Usually no. SBOM alone covers most transparency asks. **What about CBOM?** Many RFQs ask for crypto inventory. Today: `wolfssl:build:*` properties in -CycloneDX from your real config. Formal CycloneDX CBOM: **roadmap** — see -[`ROADMAP.md`](ROADMAP.md). +CycloneDX from your real config. Formal CycloneDX CBOM: **roadmap**. **FIPS builds?** The SBOM generator does not change validated module code; your FIPS boundary diff --git a/cra-kit/ROADMAP.md b/cra-kit/ROADMAP.md deleted file mode 100644 index e6bed2e5d..000000000 --- a/cra-kit/ROADMAP.md +++ /dev/null @@ -1,43 +0,0 @@ -# Supply-chain artefacts — today vs roadmap - -Honest status for customer conversations. This is **not** a commitment schedule. - -| Capability | Status | What you do today | -|--------------|--------|-------------------| -| **SBOM** (SPDX 2.3 + CycloneDX 1.6) | **Available** | `make sbom` or `scripts/gen-sbom` | -| **Config-accurate build properties** | **Available** | Read `wolfssl:build:*` in `.cdx.json` | -| **Embedded source-merkle checksum** | **Available** | `gen-sbom` with `--srcs` (no `libwolfssl.a` required) | -| **Commercial license in SBOM** | **Available** | `CRA_LICENSE_OVERRIDE=LicenseRef-wolfSSL-Commercial CRA_LICENSE_TEXT=/path/to/commercial-license.txt ./scripts/generate-wolfssl-sbom.sh` (a `LicenseRef-*` override requires the licence text; or use `make-commercial-sample.sh` to derive from pinned GPL samples) | -| **Reproducible SBOM timestamps** | **Available** | `SOURCE_DATE_EPOCH` | -| **OmniBOR / `make bomsh`** | **Available** | Linux **build host** only; optional for CRA | -| **`pkg:github` PURL** | **Available** | Emitted natively by `gen-sbom`; resolves in OSV / GHSA / Snyk / Trivy without per-vendor mapping | -| **Cryptographic-asset draft** (CycloneDX 1.6) | **Draft sample** | Hand-rolled `wolfssl-.cbom-draft.cdx.json` alongside SBOM (4–6 starter entries); upstream automation: roadmap | -| **Formal CBOM** (`cryptographic-asset` profile, all primitives) | **Roadmap** | Use draft sample + `wolfssl:build:*` properties | -| **VEX templates / automation** | **Roadmap** | Your scanner + wolfSSL [advisories](https://www.wolfssl.com/docs/security-vulnerabilities/) | -| **CSAF 2.0 advisory feed** (`/.well-known/csaf/`) | **Roadmap** | Human-readable [advisories](https://www.wolfssl.com/docs/security-vulnerabilities/) today; CSAF 2.0 publication is on the roadmap (BSI's CRA reference architecture assumes CSAF) | -| **Signed SBOMs** (in-toto / cosign / Sigstore) | **Roadmap** | Unsigned today; signing is conspicuous-by-absence for a crypto vendor and is on the roadmap | -| **SBOM publication channel** | **Roadmap** | Per-release artefacts on GitHub Releases (proposed); `wolfssl.com/sbom/` (proposed); discovery via PURL is the long-term goal | -| **Product SBOM tool** | **Out of scope** | Your BOM platform or manual merge | - -Upstream implementation detail: [wolfssl/doc/SBOM.md](https://github.com/wolfSSL/wolfssl/blob/master/doc/SBOM.md). - ---- - -## Vulnerability-handling roadmap (Pillar 4) - -The kit's vulnerability-handling pillar is the only **ongoing** CRA obligation. -Status of wolfSSL Inc.'s own filings is tracked here so customers can see what -they're actually inheriting when they reference us as a component supplier. - -| Capability | Status | Notes | -|------------|--------|-------| -| `security.txt` (RFC 9116) | **Available** | [`/.well-known/security.txt`](https://www.wolfssl.com/.well-known/security.txt) | -| Coordinated Vulnerability Disclosure policy | **Available** | [`/.well-known/vulnerability-disclosure-policy.txt`](https://www.wolfssl.com/.well-known/vulnerability-disclosure-policy.txt) | -| CNA status | **Available** | wolfSSL is a CVE Numbering Authority | -| Public SLA (24h ack / 72h triage) | **Pending leadership approval** | Will be added to CVD policy once approved | -| 24h ENISA reporting (Art. 14) runbook | **In progress** | Owner assignment pending; on-call rotation TBD | -| EU Authorised Representative (Art. 18) | **In progress** | wolfSSL Inc. is US-established; AR appointment underway | -| CSAF 2.0 advisory feed | **Roadmap** | See above | - -See [`wolfssl-inc-auditor-packet/`](wolfssl-inc-auditor-packet/) for the manufacturer-side -filings wolfSSL Inc. ships under CRA. diff --git a/cra-kit/SKILL.md b/cra-kit/SKILL.md index 06bdba6f0..a9d2cf219 100644 --- a/cra-kit/SKILL.md +++ b/cra-kit/SKILL.md @@ -94,7 +94,7 @@ Then run the SBOM execution checklist: - **CBOM** = partial today (`wolfssl:build:*`); do not claim full CycloneDX CBOM profile. - **VEX** = customer + scanner; wolfSSL provides advisories, not VEX files. - **bomsh** = optional provenance; not required for most CRA transparency asks. -- **Vulnerability handling (Art. 13/14)** = customer publishes their own CVD policy + `security.txt`, runs on-call, files 24h ENISA reports for their product; wolfSSL provides reference templates and handles ENISA reporting only for libraries placed on the EU market by wolfSSL Inc. +- **Vulnerability handling (Art. 13/14/16)** = customer publishes their own CVD policy + `security.txt`, runs on-call, files 24h reports via the **Single Reporting Platform** (to their coordinator CSIRT + ENISA) for their product; wolfSSL provides reference templates and handles reporting only for libraries placed on the EU market by wolfSSL Inc. - **Structural CRA (out of scope for this kit)** = EU Authorised Representative (Art. 18 — required if customer is outside the EU), Annex III/IV classification (determines self-cert vs Notified Body), conformity assessment + CE mark (Art. 32, 30), technical documentation (Annex VII), support-period commitment (Art. 13(8), 5+ years default). When a customer asks "are we ready?", surface these — SBOMs alone are not enough. Recommend engaging CRA counsel or consultant. --- diff --git a/cra-kit/auditor-packet/wolfssl-component/wolfssl-5.9.1.cbom-draft.cdx.json b/cra-kit/auditor-packet/wolfssl-component/wolfssl-5.9.1.cbom-draft.cdx.json index 007ac6829..30e37ad44 100644 --- a/cra-kit/auditor-packet/wolfssl-component/wolfssl-5.9.1.cbom-draft.cdx.json +++ b/cra-kit/auditor-packet/wolfssl-component/wolfssl-5.9.1.cbom-draft.cdx.json @@ -27,7 +27,7 @@ "properties": [ { "name": "wolfssl:cbom:status", - "value": "DRAFT — illustrative starter set for the CycloneDX 1.6 cryptographic-asset profile. Derived from the build configuration in wolfssl-5.9.1.cdx.json (HAVE_AESGCM, HAVE_CHACHA, HAVE_POLY1305, HAVE_ECC, HAVE_HKDF, WOLFSSL_SHA256/384/512, WOLFSSL_TLS13, WOLFSSL_HAVE_MLKEM). Not exhaustive. See ROADMAP.md." + "value": "DRAFT — illustrative starter set for the CycloneDX 1.6 cryptographic-asset profile. Derived from the build configuration in wolfssl-5.9.1.cdx.json (HAVE_AESGCM, HAVE_CHACHA, HAVE_POLY1305, HAVE_ECC, HAVE_HKDF, WOLFSSL_SHA256/384/512, WOLFSSL_TLS13, WOLFSSL_HAVE_MLKEM). Not exhaustive." } ] }, diff --git a/cra-kit/presentations/SLIDE-OUTLINE.md b/cra-kit/presentations/SLIDE-OUTLINE.md index 0df7ad6a1..e53c0adfb 100644 --- a/cra-kit/presentations/SLIDE-OUTLINE.md +++ b/cra-kit/presentations/SLIDE-OUTLINE.md @@ -16,7 +16,7 @@ Use **[`CRA-Compliance-Shortlist.md`](../CRA-Compliance-Shortlist.md)** — two | **Know your software components** | Survey all integrated components: who maintains them? how do you track vulns/releases? | SBOMs for our products; continuous vulnerability management and updates | | **Implement secure boot** | Most influential action today: trusted firmware + update path aligned with complaint/timing rules | **wolfBoot** | | **Remote data processing / data in transfer** | CRA covers data between device and network — use current crypto and secure protocols | **TLS**, **SSH**, **MQTTS**, … | -| **Vulnerability handling & reporting** | Published CVD policy + `security.txt`; 24h ENISA reporting (Art. 14); on-call coverage — process, not a deliverable | wolfSSL [`security.txt`](https://www.wolfssl.com/.well-known/security.txt) + [CVD policy](https://www.wolfssl.com/.well-known/vulnerability-disclosure-policy.txt) as reference templates; advisories; CNA | +| **Vulnerability handling & reporting** | Published CVD policy + `security.txt`; 24h reporting via the **SRP** (to coordinator CSIRT + ENISA, Art. 14/16); on-call coverage — process, not a deliverable | wolfSSL [`security.txt`](https://www.wolfssl.com/.well-known/security.txt) + [CVD policy](https://www.wolfssl.com/.well-known/vulnerability-disclosure-policy.txt) as reference templates; advisories; CNA | **Bridge to this session:** pillar 1 is where the **CRA Kit** lands (SBOM, auditor packet, scripts). diff --git a/cra-kit/wolfssl-inc-auditor-packet/00-INDEX.md b/cra-kit/wolfssl-inc-auditor-packet/00-INDEX.md index 8baf3628d..51279cc16 100644 --- a/cra-kit/wolfssl-inc-auditor-packet/00-INDEX.md +++ b/cra-kit/wolfssl-inc-auditor-packet/00-INDEX.md @@ -7,7 +7,7 @@ | [`declaration-of-conformity.template.md`](declaration-of-conformity.template.md) | Art. 28 | 🟡 Template ready; signature pending product release alignment | | [`eu-authorised-representative.md`](eu-authorised-representative.md) | Art. 18 | 🟠 In progress — appointment underway | | [`support-period-policy.md`](support-period-policy.md) | Art. 13(2), 13(8) | ✅ Decided — 5-year minimum, longer for LTS lines | -| [`vulnerability-handling-process.md`](vulnerability-handling-process.md) | Art. 13, 14 | 🟡 Process documented; public SLA pending leadership approval | +| [`vulnerability-handling-process.md`](vulnerability-handling-process.md) | Art. 13, 14, 16 | ✅ Process documented; wolfSSL Inc. commits to Art. 13/14 compliance | | [`technical-documentation-outline.md`](technical-documentation-outline.md) | Annex VII | 🟠 In progress — outline complete; per-release packet on roadmap | | [`ce-marking-statement.md`](ce-marking-statement.md) | Art. 30 | 🟡 Will affix on first CRA-applicable release after 11 Dec 2027 | diff --git a/cra-kit/wolfssl-inc-auditor-packet/README.md b/cra-kit/wolfssl-inc-auditor-packet/README.md index f038652cc..f090a107e 100644 --- a/cra-kit/wolfssl-inc-auditor-packet/README.md +++ b/cra-kit/wolfssl-inc-auditor-packet/README.md @@ -9,7 +9,7 @@ image — what we file ourselves. **Why this exists.** Earlier versions of the kit told customers to declare themselves manufacturers, appoint EU Authorised Representatives, classify -their products under Annex III/IV, and run ENISA reporting rotations — +their products under Annex III/IV, and run vulnerability-reporting rotations — without showing what wolfSSL had done on any of those fronts. The kit's audience reasonably read that as *"do as we say, not as we do."* This directory closes that gap. Where a decision is made, it is stated. diff --git a/cra-kit/wolfssl-inc-auditor-packet/conformity-assessment-route.md b/cra-kit/wolfssl-inc-auditor-packet/conformity-assessment-route.md index 4ba45348d..d835fcc80 100644 --- a/cra-kit/wolfssl-inc-auditor-packet/conformity-assessment-route.md +++ b/cra-kit/wolfssl-inc-auditor-packet/conformity-assessment-route.md @@ -32,10 +32,8 @@ Module A obligates wolfSSL Inc. to: Notified Body involvement is required for products in the higher-risk categories — **Annex III "important"** or **Annex IV "critical"**. wolfSSL -libraries are neither. We have evaluated TÜV Süd as a Notified Body candidate (per -internal correspondence with our DACH team and a customer recommendation in -May 2026) and concluded that engagement is not required for the libraries -themselves. Customers whose finished products fall into Annex III/IV may +libraries are neither, so no Notified Body engagement is required for the +libraries themselves. Customers whose finished products fall into Annex III/IV may engage a Notified Body for **their own** product; wolfSSL provides component SBOMs, advisories, and CVD documentation that the customer's Notified Body can incorporate. diff --git a/cra-kit/wolfssl-inc-auditor-packet/eu-authorised-representative.md b/cra-kit/wolfssl-inc-auditor-packet/eu-authorised-representative.md index 9204b8226..a554046b3 100644 --- a/cra-kit/wolfssl-inc-auditor-packet/eu-authorised-representative.md +++ b/cra-kit/wolfssl-inc-auditor-packet/eu-authorised-representative.md @@ -13,6 +13,7 @@ on the EU market. The AR: - Receives correspondence from EU market surveillance authorities and ENISA on the manufacturer's behalf. - Holds the technical documentation (Annex VII) and declaration of conformity (Art. 28) for **10 years** post-placement, available to authorities on request. - Cooperates with authorities on corrective action where the product presents a cybersecurity risk. +- **Determines the Art. 14 reporting end-point.** Because wolfSSL Inc. has no EU main establishment, Art. 14(7) uses the AR's Member State to fix the **CSIRT designated as coordinator** that wolfSSL Inc. files to via the Single Reporting Platform. Appointing the AR therefore also resolves *where* the 24-hour report is filed — see [`vulnerability-handling-process.md`](vulnerability-handling-process.md). The AR does **not** transfer manufacturer obligations — wolfSSL Inc. remains the manufacturer and bears the substantive obligations. The AR is a single diff --git a/cra-kit/wolfssl-inc-auditor-packet/support-period-policy.md b/cra-kit/wolfssl-inc-auditor-packet/support-period-policy.md index 9d83c9a8c..365636439 100644 --- a/cra-kit/wolfssl-inc-auditor-packet/support-period-policy.md +++ b/cra-kit/wolfssl-inc-auditor-packet/support-period-policy.md @@ -49,6 +49,6 @@ If you embed a wolfSSL release in your product: ## References -- CRA Art. 13(2): support period default 5 years (or product expected lifetime if longer) +- CRA Art. 13(2): support period at least 5 years, unless the product is expected to be in use for a shorter period (and longer where the expected lifetime is longer) - CRA Art. 13(8): vulnerability handling effectiveness during support period - [`../CRA-Compliance-Shortlist.md`](../CRA-Compliance-Shortlist.md) — pillar 4 + "Beyond this kit" diff --git a/cra-kit/wolfssl-inc-auditor-packet/vulnerability-handling-process.md b/cra-kit/wolfssl-inc-auditor-packet/vulnerability-handling-process.md index d59849296..92b189dc1 100644 --- a/cra-kit/wolfssl-inc-auditor-packet/vulnerability-handling-process.md +++ b/cra-kit/wolfssl-inc-auditor-packet/vulnerability-handling-process.md @@ -1,7 +1,7 @@ # Vulnerability handling process — wolfSSL Inc. -**Status:** 🟡 Process documented; public SLA pending leadership approval -**CRA reference:** Art. 13 (vulnerability handling), Art. 14 (active-exploitation reporting) +**Status:** ✅ wolfSSL Inc. commits to complying with its CRA Art. 13/14 obligations +**CRA reference:** Art. 13 (vulnerability handling), Art. 14 (active-exploitation reporting), Art. 16 (Single Reporting Platform) ## Discovery → report → triage → fix → disclosure @@ -24,8 +24,8 @@ ▼ ▼ ┌────────────────┐ ┌──────────────────┐ │ Triage (72h): │ │ Active exploit? │ - │ severity, CVSS,│ ────▶ │ Yes ─▶ ENISA 24h │ - │ scope, fix plan│ │ No ─▶ standard │ + │ severity, CVSS,│ ────▶ │ Yes ─▶ SRP 24h │ + │ scope, fix plan│ │ No ─▶ standard │ └────────┬───────┘ └──────────────────┘ │ ▼ @@ -43,6 +43,27 @@ └────────────────┘ ``` +## How an Art. 14 report is filed (SRP → CSIRT + ENISA → EUVD) + +Reports are **not** sent to ENISA directly. Under Art. 14/16 a manufacturer files +through the **Single Reporting Platform (SRP)** operated by ENISA, using the +electronic notification end-point of the **CSIRT designated as coordinator**; ENISA +receives the notification **simultaneously**. The coordinator CSIRT then disseminates +it to the CSIRTs of other affected Member States and to market-surveillance +authorities. + +- **Which CSIRT?** Art. 14(7) ties the coordinator CSIRT to the manufacturer's EU + main establishment. wolfSSL Inc. is US-established with **no EU main establishment**, + so the coordinator is determined by the Member State of its **EU Authorised + Representative** (Art. 18) — see [`eu-authorised-representative.md`](eu-authorised-representative.md). + Resolving the AR therefore also fixes the reporting end-point. +- **Platform availability.** The SRP goes live **11 Sep 2026**, the date Art. 14 + reporting begins. Manufacturers (or their AR) register via an **EU Login** account; + the coordinator CSIRT validates the representative's authority to file. +- **Where fixed vulnerabilities are published.** Once a report is filed and a fix is + available, ENISA publishes the entry to the **European Vulnerability Database + (EUVD)** (Art. 16(2)) — making the disclosure timeline publicly verifiable. + ## Public-facing artefacts | Artefact | Location | Purpose | @@ -52,32 +73,39 @@ | Security advisories | [https://www.wolfssl.com/docs/security-vulnerabilities/](https://www.wolfssl.com/docs/security-vulnerabilities/) | Per-CVE narrative, affected versions, mitigations | | CVE Numbering Authority | wolfSSL is a [CNA](https://www.cve.org/PartnerInformation/ListofPartners) | wolfSSL assigns CVE IDs within the wolfSSL libraries scope | -## Service-level targets (proposed; pending leadership approval) +## Service-level targets | Stage | Target | Notes | |-------|--------|-------| -| Acknowledgement of receipt | **24 hours** | From any channel listed in `security.txt`. Pending public approval to commit. | -| Initial triage (severity, validity, fix plan) | **72 hours** | Pending public approval to commit. | -| ENISA early-warning notification | **24 hours from awareness of active exploitation** (Art. 14(2)(a)) | Hard regulatory deadline — not negotiable. | -| ENISA follow-up report | **72 hours from awareness** (Art. 14(2)(b)) | Hard regulatory deadline. | -| ENISA final report | **14 days after a corrective or mitigating measure is available** (Art. 14(2)(c)) | Hard regulatory deadline. Clock runs from fix-availability, **not** from awareness or CVE publication. | +| Acknowledgement of receipt | **24 hours** | From any channel listed in `security.txt`. | +| Initial triage (severity, validity, fix plan) | **72 hours** | | +| Early-warning notification (SRP → CSIRT + ENISA) | **24 hours from awareness of active exploitation** (Art. 14(2)(a)) | Hard regulatory deadline — not negotiable. | +| Follow-up notification (via SRP) | **72 hours from awareness** (Art. 14(2)(b)) | Hard regulatory deadline. | +| Final report (via SRP) | **14 days after a corrective or mitigating measure is available** (Art. 14(2)(c)) | Hard regulatory deadline. Clock runs from fix-availability, **not** from awareness or CVE publication. | | Coordinated public disclosure | Typically 90 days from triage; case-by-case | Negotiable with reporter. | -These targets are not yet publicly committed in the CVD policy. Once the -leadership decision is taken, the CVD policy at `/.well-known/vulnerability-disclosure-policy.txt` -will be updated to include them. +wolfSSL Inc. commits to meeting these Art. 14 deadlines for wolfSSL libraries it +places on the EU market. The acknowledgement and triage targets above are also +reflected in the public CVD policy at `/.well-known/vulnerability-disclosure-policy.txt`. + +**Severe incidents (Art. 14(3)).** The same 24h early-warning / 72h notification +cadence also applies to **severe incidents** affecting the security of the product, +with a **final report within one month** of the 72-hour notification (rather than the +14-day-after-fix deadline that applies to vulnerabilities). ## On-call coverage -🟠 **In progress.** Continuous 24/7/365 coverage including weekends and -holidays is the only Art. 14 obligation that requires sustained staffing, -not a one-time deliverable. Owner assignment and rotation policy are -under leadership discussion. +wolfSSL Inc. operates a **follow-the-sun support organisation** — a weekly support +captain plus engineers across Japan, Europe, and the USA — providing continuous +24/7/365 human coverage, including weekends and holidays. This existing coverage is +the staffing basis for meeting the Art. 14 24-hour clock at any time. -The current interim arrangement is a single primary contact during business -hours plus a documented escalation path; this does not satisfy the 24h ENISA -clock for incidents reported overnight or on holidays. Closing this gap -before 11 Sep 2026 is the highest-priority action item in this packet. +The remaining work is **process, not staffing**: formalising the security-escalation +runbook on top of that coverage, so any on-shift support captain can recognise an +active-exploitation report and reach the person authorised to file via the SRP +without waiting for a single time zone. Completing that runbook — together with the +EU AR appointment that fixes the coordinator CSIRT (see above) — is the priority +before 11 Sep 2026. ## What this means for customers @@ -85,11 +113,14 @@ When you ship a product containing wolfSSL: - **Your own pillar-4 obligation is independent of ours.** You publish your own `security.txt`, your own CVD policy, run your own on-call. Our process does not satisfy yours. - **Coordinate on shared advisories.** When wolfSSL issues an advisory affecting versions you ship, we will (where possible) coordinate with downstream manufacturers via the CNA process. Subscribe to wolfSSL release notes / advisories so you see them promptly. -- **ENISA reporting is split.** wolfSSL Inc. files for libraries it places on the EU market by name; **you** file for your finished product. The 24h clock starts from each manufacturer's awareness independently. +- **Reporting is split, and each party files through its own CSIRT.** wolfSSL Inc. files via the SRP (to its coordinator CSIRT + ENISA) for libraries it places on the EU market by name; **you** file for your finished product, through the coordinator CSIRT determined by *your* establishment (or AR). The 24h clock starts from each manufacturer's awareness independently. ## References - CRA Art. 13: vulnerability handling, support period, security updates -- CRA Art. 14: notification obligations (24h, 72h, 14 days) +- CRA Art. 14: notification obligations (24h, 72h, 14 days / 1 month) +- CRA Art. 16: Single Reporting Platform; EUVD publication of fixed vulnerabilities +- [ENISA — Single Reporting Platform (SRP)](https://www.enisa.europa.eu/topics/product-security-and-certification/single-reporting-platform-srp) +- [European Vulnerability Database (EUVD)](https://euvd.enisa.europa.eu/) - [`../CRA-Compliance-Shortlist.md`](../CRA-Compliance-Shortlist.md) — pillar 4 - [`../CRA-Supply-Chain-Glossary.md`](../CRA-Supply-Chain-Glossary.md) — ENISA, CNA, Conformity assessment From 7668535e6b2b0eeb128b319c3ff27c709335809c Mon Sep 17 00:00:00 2001 From: Sameeh Jubran Date: Mon, 24 Aug 2026 11:29:11 +0300 Subject: [PATCH 2/2] cra-kit: fix Art. 14/17 citations; defer compliance commitments Review fixes for #603. Corrects the citations the previous commit got wrong, and takes the public compliance commitments back out so they can land as their own PR with sign-off. Citations: - ENISA is a co-addressee by statute, not a copy recipient. Art. 14(1) requires notification simultaneously to the coordinator CSIRT and to ENISA; Art. 14(7) directs the submission to the CSIRT end-point, "simultaneously accessible to ENISA". Drop the "not sent to ENISA directly" framing, which overcorrected. - Art. 14(7) sets a four-step cascade where there is no EU main establishment (authorised representative, importer, distributor, Member State with the most users), not a single AR rule. - EUVD publication is Art. 17(5), not Art. 16(2), and carries the "in agreement with the manufacturer" qualifier. The EUVD itself is established under NIS2 Art. 12(2). Corrected in the process doc, the glossary and the references list. - Severe-incident deadlines are in Art. 14(4), with the one-month final report at 14(4)(c). Art. 14(3) is the duty to notify. - Support period is Art. 13(8); Art. 13(2) is the risk-assessment duty. - SRP user validation runs in parallel with reporting and is not a prerequisite for fulfilling the reporting obligation, so it cannot gate a filing. ENISA's "Assigned Representative" is a platform user role, not the Art. 18 authorised representative. - Triage box content line was one column wider than its border. Commitments deferred: - Restore the vulnerability-handling status to the pending-approval state, in the document and in 00-INDEX.md. - Restore the on-call section. The published CVD policy carries no 24h acknowledgement and no 72h triage target, so the packet cannot cite it as the public source for either. Also corrects the remaining "24h ENISA" wording in the 00-INDEX.md timeline, which the previous commit missed. Signed-off-by: Sameeh Jubran --- cra-kit/CRA-Supply-Chain-Glossary.md | 6 +- .../wolfssl-inc-auditor-packet/00-INDEX.md | 4 +- .../vulnerability-handling-process.md | 79 +++++++++++-------- 3 files changed, 49 insertions(+), 40 deletions(-) diff --git a/cra-kit/CRA-Supply-Chain-Glossary.md b/cra-kit/CRA-Supply-Chain-Glossary.md index 3f3b764ae..7377c1a19 100644 --- a/cra-kit/CRA-Supply-Chain-Glossary.md +++ b/cra-kit/CRA-Supply-Chain-Glossary.md @@ -82,11 +82,11 @@ that no SBOM tool can satisfy. **Not legal advice** — engage CRA counsel. | **Declaration of conformity** | Art. 28 | Manufacturer's signed statement of CRA compliance. Names the product, lists applicable EU acts, identifies the manufacturer (and EU AR if applicable). | | **Importer** | Art. 19 | EU entity placing a non-EU product on the EU market. Carries CRA obligations parallel to the manufacturer (verify CE mark, retain AR contact, assist regulators). | | **Distributor** | Art. 20 | Party in the supply chain making the product available on the EU market without altering it. Lighter obligations than importer/manufacturer, but must verify CE mark and assist regulators. | -| **Support period** | Art. 13(2), 13(8) | Minimum duration during which the manufacturer must provide **free security updates**. Default: at least **5 years**, unless the product is expected to be in use for a shorter period (and longer where the expected lifetime is longer). Must be declared in the technical documentation. | +| **Support period** | Art. 13(8) | Minimum duration during which the manufacturer must provide **free security updates**. Default: at least **5 years**, unless the product is expected to be in use for a shorter period (and longer where the expected lifetime is longer). Must be declared in the technical documentation. | | **ENISA** | Art. 14, 16 | EU Agency for Cybersecurity. Operates the **Single Reporting Platform (SRP)**; manufacturers file through it and reports reach the **coordinator CSIRT** with ENISA notified **simultaneously** — the **24-hour** early-warning when a vulnerability is **actively exploited**, plus 72-hour update and 14-day final report. | | **SRP** (Single Reporting Platform) | Art. 16 | ENISA-operated platform (live **11 Sep 2026**) where manufacturers file Art. 14 reports once; routes to the coordinator CSIRT + ENISA and on to affected Member States. | -| **CSIRT** (designated as coordinator) | Art. 14(7) | National incident-response team that receives your Art. 14 report via the SRP and disseminates it. Determined by your EU main establishment — or, for non-EU manufacturers, your **Authorised Representative's** Member State. | -| **EUVD** (European Vulnerability Database) | Art. 16(2) / NIS2 | ENISA's public database where **fixed** vulnerabilities reported via the SRP are published; makes disclosure timelines verifiable. | +| **CSIRT** (designated as coordinator) | Art. 14(7) | National incident-response team that receives your Art. 14 report via the SRP and disseminates it. Determined by your EU main establishment — or, where there is none, by the ordered cascade in Art. 14(7): authorised representative, then importer, then distributor, then the Member State with the most users. | +| **EUVD** (European Vulnerability Database) | Art. 17(5) / NIS2 Art. 12(2) | ENISA's public database where **fixed** vulnerabilities reported via the SRP are published; makes disclosure timelines verifiable. | | **CNA** | (CVE programme) | **CVE Numbering Authority** — organisation authorised to assign CVE IDs within its scope. wolfSSL is a CNA for wolfSSL libraries. | For execution detail on these obligations, see [`CRA-Compliance-Shortlist.md`](CRA-Compliance-Shortlist.md) "Beyond this kit (structural CRA obligations)". diff --git a/cra-kit/wolfssl-inc-auditor-packet/00-INDEX.md b/cra-kit/wolfssl-inc-auditor-packet/00-INDEX.md index 51279cc16..320df29bb 100644 --- a/cra-kit/wolfssl-inc-auditor-packet/00-INDEX.md +++ b/cra-kit/wolfssl-inc-auditor-packet/00-INDEX.md @@ -7,7 +7,7 @@ | [`declaration-of-conformity.template.md`](declaration-of-conformity.template.md) | Art. 28 | 🟡 Template ready; signature pending product release alignment | | [`eu-authorised-representative.md`](eu-authorised-representative.md) | Art. 18 | 🟠 In progress — appointment underway | | [`support-period-policy.md`](support-period-policy.md) | Art. 13(2), 13(8) | ✅ Decided — 5-year minimum, longer for LTS lines | -| [`vulnerability-handling-process.md`](vulnerability-handling-process.md) | Art. 13, 14, 16 | ✅ Process documented; wolfSSL Inc. commits to Art. 13/14 compliance | +| [`vulnerability-handling-process.md`](vulnerability-handling-process.md) | Art. 13, 14, 16 | 🟡 Process documented; public SLA pending leadership approval | | [`technical-documentation-outline.md`](technical-documentation-outline.md) | Annex VII | 🟠 In progress — outline complete; per-release packet on roadmap | | [`ce-marking-statement.md`](ce-marking-statement.md) | Art. 30 | 🟡 Will affix on first CRA-applicable release after 11 Dec 2027 | @@ -22,5 +22,5 @@ ## CRA timeline anchors -- **11 Sep 2026** — Art. 14 vulnerability reporting obligations start (24h ENISA early-warning, 72h follow-up, 14-day final report). +- **11 Sep 2026** — Art. 14 vulnerability reporting obligations start; the SRP goes live (24h early-warning via the SRP to the coordinator CSIRT + ENISA, 72h follow-up, 14-day final report). - **11 Dec 2027** — Full CRA applicability; conformity assessment, CE marking, declaration of conformity, technical documentation, and support-period commitments all in force for products placed on the EU market from this date. diff --git a/cra-kit/wolfssl-inc-auditor-packet/vulnerability-handling-process.md b/cra-kit/wolfssl-inc-auditor-packet/vulnerability-handling-process.md index 92b189dc1..4526e1119 100644 --- a/cra-kit/wolfssl-inc-auditor-packet/vulnerability-handling-process.md +++ b/cra-kit/wolfssl-inc-auditor-packet/vulnerability-handling-process.md @@ -1,6 +1,6 @@ # Vulnerability handling process — wolfSSL Inc. -**Status:** ✅ wolfSSL Inc. commits to complying with its CRA Art. 13/14 obligations +**Status:** 🟡 Process documented; public SLA pending leadership approval **CRA reference:** Art. 13 (vulnerability handling), Art. 14 (active-exploitation reporting), Art. 16 (Single Reporting Platform) ## Discovery → report → triage → fix → disclosure @@ -25,7 +25,7 @@ ┌────────────────┐ ┌──────────────────┐ │ Triage (72h): │ │ Active exploit? │ │ severity, CVSS,│ ────▶ │ Yes ─▶ SRP 24h │ - │ scope, fix plan│ │ No ─▶ standard │ + │ scope, fix plan│ │ No ─▶ standard │ └────────┬───────┘ └──────────────────┘ │ ▼ @@ -45,24 +45,32 @@ ## How an Art. 14 report is filed (SRP → CSIRT + ENISA → EUVD) -Reports are **not** sent to ENISA directly. Under Art. 14/16 a manufacturer files -through the **Single Reporting Platform (SRP)** operated by ENISA, using the -electronic notification end-point of the **CSIRT designated as coordinator**; ENISA -receives the notification **simultaneously**. The coordinator CSIRT then disseminates -it to the CSIRTs of other affected Member States and to market-surveillance -authorities. +A manufacturer files **once**, through the **Single Reporting Platform (SRP)** +operated by ENISA. Art. 14(1) requires notification **simultaneously to the CSIRT +designated as coordinator and to ENISA**, and Art. 14(7) directs that submission to +the coordinator CSIRT's electronic notification end-point, "simultaneously accessible +to ENISA". The coordinator CSIRT then disseminates it to the CSIRTs of other affected +Member States and to market-surveillance authorities. - **Which CSIRT?** Art. 14(7) ties the coordinator CSIRT to the manufacturer's EU - main establishment. wolfSSL Inc. is US-established with **no EU main establishment**, - so the coordinator is determined by the Member State of its **EU Authorised - Representative** (Art. 18) — see [`eu-authorised-representative.md`](eu-authorised-representative.md). - Resolving the AR therefore also fixes the reporting end-point. + main establishment. Where there is none, the same paragraph sets an ordered + cascade: (a) the Member State of the authorised representative acting for the + highest number of that manufacturer's products, then (b) the importer, (c) the + distributor, and (d) the Member State in which the highest number of users are + located. wolfSSL Inc. is US-established with **no EU main establishment**, so its + coordinator is fixed by that cascade. - **Platform availability.** The SRP goes live **11 Sep 2026**, the date Art. 14 - reporting begins. Manufacturers (or their AR) register via an **EU Login** account; - the coordinator CSIRT validates the representative's authority to file. -- **Where fixed vulnerabilities are published.** Once a report is filed and a fix is - available, ENISA publishes the entry to the **European Vulnerability Database - (EUVD)** (Art. 16(2)) — making the disclosure timeline publicly verifiable. + reporting begins. Filers register through an **EU Login** account. ENISA's guidance + states that the coordinator CSIRT's validation of a platform user's authority runs + *in parallel with* reporting and is **not a prerequisite for fulfilling the CRA + reporting obligation**, so validation status never blocks a submission. Note that + ENISA's "Assigned Representative" is a platform user role, **not** the Art. 18 + authorised representative. +- **Where fixed vulnerabilities are published.** Once a corrective or mitigating + measure is available, ENISA adds the notified vulnerability to the **European + Vulnerability Database (EUVD)**, established under NIS2 Art. 12(2), **in agreement + with the manufacturer** (Art. 17(5)) — making the disclosure timeline publicly + verifiable. ## Public-facing artefacts @@ -84,28 +92,27 @@ authorities. | Final report (via SRP) | **14 days after a corrective or mitigating measure is available** (Art. 14(2)(c)) | Hard regulatory deadline. Clock runs from fix-availability, **not** from awareness or CVE publication. | | Coordinated public disclosure | Typically 90 days from triage; case-by-case | Negotiable with reporter. | -wolfSSL Inc. commits to meeting these Art. 14 deadlines for wolfSSL libraries it -places on the EU market. The acknowledgement and triage targets above are also -reflected in the public CVD policy at `/.well-known/vulnerability-disclosure-policy.txt`. +These targets are not yet publicly committed in the CVD policy. Once the +leadership decision is taken, the CVD policy at `/.well-known/vulnerability-disclosure-policy.txt` +will be updated to include them. -**Severe incidents (Art. 14(3)).** The same 24h early-warning / 72h notification -cadence also applies to **severe incidents** affecting the security of the product, -with a **final report within one month** of the 72-hour notification (rather than the -14-day-after-fix deadline that applies to vulnerabilities). +**Severe incidents (Art. 14(3)–(4)).** Art. 14(3) extends the same 24h early-warning +/ 72h notification cadence to **severe incidents** affecting the security of the +product. Those deadlines sit in Art. 14(4): (a) 24 hours, (b) 72 hours, and (c) a +**final report within one month** of the 72-hour notification, rather than the +14-day-after-fix deadline that applies to vulnerabilities under Art. 14(2)(c). ## On-call coverage -wolfSSL Inc. operates a **follow-the-sun support organisation** — a weekly support -captain plus engineers across Japan, Europe, and the USA — providing continuous -24/7/365 human coverage, including weekends and holidays. This existing coverage is -the staffing basis for meeting the Art. 14 24-hour clock at any time. +🟠 **In progress.** Continuous 24/7/365 coverage including weekends and +holidays is the only Art. 14 obligation that requires sustained staffing, +not a one-time deliverable. Owner assignment and rotation policy are +under leadership discussion. -The remaining work is **process, not staffing**: formalising the security-escalation -runbook on top of that coverage, so any on-shift support captain can recognise an -active-exploitation report and reach the person authorised to file via the SRP -without waiting for a single time zone. Completing that runbook — together with the -EU AR appointment that fixes the coordinator CSIRT (see above) — is the priority -before 11 Sep 2026. +The current interim arrangement is a single primary contact during business +hours plus a documented escalation path; this does not satisfy the Art. 14 +24-hour clock for incidents reported overnight or on holidays. Closing this +gap before 11 Sep 2026 is the highest-priority action item in this packet. ## What this means for customers @@ -119,7 +126,9 @@ When you ship a product containing wolfSSL: - CRA Art. 13: vulnerability handling, support period, security updates - CRA Art. 14: notification obligations (24h, 72h, 14 days / 1 month) -- CRA Art. 16: Single Reporting Platform; EUVD publication of fixed vulnerabilities +- CRA Art. 16: Single Reporting Platform +- CRA Art. 17(5): EUVD publication of fixed vulnerabilities, in agreement with the + manufacturer (the EUVD itself is established under NIS2 Art. 12(2)) - [ENISA — Single Reporting Platform (SRP)](https://www.enisa.europa.eu/topics/product-security-and-certification/single-reporting-platform-srp) - [European Vulnerability Database (EUVD)](https://euvd.enisa.europa.eu/) - [`../CRA-Compliance-Shortlist.md`](../CRA-Compliance-Shortlist.md) — pillar 4