wolfSSL · sameehj · Jul 17, 2026
diff --git 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
@@ -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
@@ -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
@@ -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
diff --git 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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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.