cra-kit: correct Art. 14 reporting mechanics and Art. 18 (an AR is optional); remove ROADMAP.md

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)
 
 ---
 
@@ -89,7 +89,7 @@ the EU market you also need:
 
 | Obligation | Article | Action |
 |------------|---------|--------|
-| **EU Authorised Representative** | Art. 18 | Required if you're established outside the EU |
+| **EU Authorised Representative** | Art. 18 | Optional (Art. 18(1) says "may") — but it fixes your Art. 14(7) reporting end-point |
 | **Product class** (Annex III/IV) | — | Determines self-cert vs **Notified Body** — long queues |
 | **Conformity assessment + CE mark** | Art. 32, 30 | Module A or external review |
 | **Technical documentation** | Annex VII | Risk assessment, support-period commitment |

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
@@ -73,7 +73,7 @@ SBOMs alone make you ready:
 
 | Obligation | Article | What it means |
 |------------|---------|---------------|
-| **EU Authorised Representative** | Art. 18 | Manufacturers established **outside** the EU must appoint a written-mandated representative **inside** the EU before placing a product on the EU market. Either contract a third-party AR service or use an existing EU subsidiary. |
+| **EU Authorised Representative** | Art. 18 | **Optional.** Art. 18(1) says a manufacturer *may* appoint a written-mandated representative inside the EU; there is no duty to, even from outside the EU. Appointing one gives you a single EU contact point, puts your documentation inside the Union, and fixes your Art. 14(7) reporting end-point in a Member State you choose. Without one, that end-point falls to your importer, your distributor, or wherever most of your users are. Either contract a third-party AR service or use an existing EU subsidiary. |
 | **Product classification** | Annex III / IV | Determines whether conformity assessment is self-declared (default class) or requires a **Notified Body** (important / critical class). Notified-body queues are already long — if you may need one, get in queue early. |
 | **Conformity assessment + CE mark** | Art. 32, 30 | Module A (self-assessment) or external review per classification; CE marking before placing the product on the EU market. |
 | **Technical documentation** | Annex VII | Risk assessment, secure-design rationale, vulnerability handling process, support-period commitment — more than the SBOM. |

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`. |
@@ -71,7 +71,7 @@ that no SBOM tool can satisfy. **Not legal advice** — engage CRA counsel.
 
 | Term | Article / location | Plain English |
 |------|--------------------|---------------|
-| **EU Authorised Representative** (EU AR) | Art. 18 | Required if the manufacturer is established **outside** the EU. A written-mandated EU-resident legal entity that receives regulator correspondence on the manufacturer's behalf. Either contract a third-party AR service or use an existing EU subsidiary. **Long-lead** — start now. |
+| **EU Authorised Representative** (EU AR) | Art. 18 | A written-mandated EU-resident legal entity that holds the manufacturer's documentation and receives regulator correspondence on its behalf. **Optional** — Art. 18(1) says a manufacturer *may* appoint one, including from outside the EU. It cannot take on the Art. 13 core obligations (Art. 18(2)). It does fix the Art. 14(7) coordinator CSIRT. Either contract a third-party AR service or use an existing EU subsidiary. **Long-lead** if you want one. |
 | **Notified Body** | — | Independent third-party conformity-assessment organisation. For "important" or "critical" products (Annex III/IV) the conformity assessment must involve a Notified Body. Queues are long — engage early if you may need one. |
 | **Annex III** | Annex III | List of **"important"** products with above-baseline cybersecurity risk (e.g. password managers, network management systems, browsers, certain identity-management components). Triggers stricter conformity assessment than the default class. |
 | **Annex IV** | Annex IV | List of **"critical"** products (highest-risk class), e.g. hardware security modules, secure-boot devices, smart-meter gateways of certain types. Always requires Notified Body involvement. |
@@ -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(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, 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)".

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
@@ -258,10 +254,14 @@ distributor obligations. See [`CRA-Compliance-Shortlist.md`](CRA-Compliance-Shor
 legal/structural decisions, not artefacts.
 
 **Are we outside the EU? (US / Asia / etc.)**  
-Then you almost certainly need an **EU Authorised Representative** (Art. 18)
-appointed in writing **before** placing your product on the EU market. Either
-contract a third-party AR service or use an existing EU subsidiary. This is a
-long-lead item — start now, do not wait for September 2026.
+Then consider an **EU Authorised Representative** (Art. 18). It is **optional** —
+Art. 18(1) says a manufacturer *may* appoint one, and there is no duty even from
+outside the EU. It is still worth weighing: an AR gives you one EU contact point,
+holds your documentation inside the Union, and fixes your Art. 14(7) reporting
+end-point in a Member State you choose rather than leaving it to an importer, a
+distributor, or wherever most of your users happen to be. Either contract a
+third-party AR service or use an existing EU subsidiary. If you decide you want
+one, it is a long-lead item — start early. Your own counsel should make the call.
 
 ---