From 07efe62f1695b21e93d1a573ac4ca4aee60ac6ba Mon Sep 17 00:00:00 2001 From: Sameeh Jubran Date: Fri, 17 Jul 2026 15:19:10 +0300 Subject: [PATCH 1/3] 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/3] 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 From a4110d3a9bf2c2bff2101e6afe21370fe8461494 Mon Sep 17 00:00:00 2001 From: Sameeh Jubran Date: Fri, 28 Aug 2026 11:27:10 +0300 Subject: [PATCH 3/3] =?UTF-8?q?cra-kit:=20correct=20Art.=2018=20=E2=80=94?= =?UTF-8?q?=20an=20authorised=20representative=20is=20optional?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Art. 18(1) reads "a manufacturer may, by a written mandate, appoint an authorised representative". The kit stated the opposite in eight places, telling readers that a manufacturer established outside the EU is obliged to appoint one. That is wrong, and in the customer-facing pages it is advice about a duty that does not exist. Art. 66 CRA adds the CRA only to Annex I of Regulation (EU) 2019/1020, the market-surveillance list. It does not bring products with digital elements under Art. 4 of that Regulation, so there is no indirect requirement for an EU-established economic operator either. Rewrite eu-authorised-representative.md around the correct mechanism: what Art. 18(3) puts in a mandate, what Art. 18(2) keeps with the manufacturer, and how an AR fixes the Art. 14(7) coordinator CSIRT at step 1 of the cascade instead of leaving it to an importer, a distributor, or the Member State with the most users. Also drop the appointment status, the target dates, the third-party vendor shortlist, and the placeholder identity block. The packet no longer asserts that an appointment is underway, and does not assert the opposite either. 00-INDEX.md is updated to match. Follow-up to #603, where this was raised in review as out of scope. --- cra-kit/CRA-Cheat-Sheet.md | 2 +- cra-kit/CRA-Compliance-Shortlist.md | 2 +- cra-kit/CRA-Supply-Chain-Glossary.md | 2 +- cra-kit/README.md | 12 +- cra-kit/SKILL.md | 4 +- cra-kit/auditor-packet/00-INDEX.md | 2 +- .../wolfssl-inc-auditor-packet/00-INDEX.md | 4 +- cra-kit/wolfssl-inc-auditor-packet/README.md | 2 +- .../declaration-of-conformity.template.md | 4 +- .../eu-authorised-representative.md | 109 +++++++++++------- .../technical-documentation-outline.md | 2 +- 11 files changed, 88 insertions(+), 57 deletions(-) diff --git a/cra-kit/CRA-Cheat-Sheet.md b/cra-kit/CRA-Cheat-Sheet.md index 180f82a4a..76280b402 100644 --- a/cra-kit/CRA-Cheat-Sheet.md +++ b/cra-kit/CRA-Cheat-Sheet.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 | diff --git a/cra-kit/CRA-Compliance-Shortlist.md b/cra-kit/CRA-Compliance-Shortlist.md index 21a35b0bc..267eefa5b 100644 --- a/cra-kit/CRA-Compliance-Shortlist.md +++ b/cra-kit/CRA-Compliance-Shortlist.md @@ -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. | diff --git a/cra-kit/CRA-Supply-Chain-Glossary.md b/cra-kit/CRA-Supply-Chain-Glossary.md index 7377c1a19..92d8d865f 100644 --- a/cra-kit/CRA-Supply-Chain-Glossary.md +++ b/cra-kit/CRA-Supply-Chain-Glossary.md @@ -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. | diff --git a/cra-kit/README.md b/cra-kit/README.md index 274b3674f..f844b2af8 100644 --- a/cra-kit/README.md +++ b/cra-kit/README.md @@ -254,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. --- diff --git a/cra-kit/SKILL.md b/cra-kit/SKILL.md index a9d2cf219..56e880ab2 100644 --- a/cra-kit/SKILL.md +++ b/cra-kit/SKILL.md @@ -59,7 +59,7 @@ Set `WOLFSSL_DIR` to your wolfSSL source tree when regenerating SBOMs. **Before starting**, confirm with the customer (do not assume): -- Where is the customer **established** (US / EU / other)? If outside the EU, flag the **EU Authorised Representative** requirement (Art. 18) — long-lead item, start now. +- Where is the customer **established** (US / EU / other)? If outside the EU, raise the **EU Authorised Representative** option (Art. 18). Do not call it a requirement — Art. 18(1) says *may*. Frame it as the choice that fixes their Art. 14(7) reporting end-point, and as a long-lead item if they want one. - What is the **product classification** under Annex III/IV? Self-declared (default class) or Notified Body required (important / critical)? Flag if unknown — Notified Body queues are long. - Is the customer's CRA work **on track for 11 Sep 2026** (Art. 14 reporting wave) and **11 Dec 2027** (full applicability)? If structural items are open, SBOM work alone won't make them ready. @@ -95,7 +95,7 @@ Then run the SBOM execution checklist: - **VEX** = customer + scanner; wolfSSL provides advisories, not VEX files. - **bomsh** = optional provenance; not required for most CRA transparency asks. - **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. +- **Structural CRA (out of scope for this kit)** = EU Authorised Representative (Art. 18 — optional, never state it as required), 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/00-INDEX.md b/cra-kit/auditor-packet/00-INDEX.md index 96ef38605..7c56b0a1c 100644 --- a/cra-kit/auditor-packet/00-INDEX.md +++ b/cra-kit/auditor-packet/00-INDEX.md @@ -28,7 +28,7 @@ CRA conformity packet for a real product also includes: - Declaration of conformity (Art. 28) - Technical documentation per Annex VII (risk assessment, design info, support-period commitment, vulnerability handling process) - Proof of conformity assessment (self-declared per Art. 32 Module A, or Notified Body certificate per product class) -- Identity of the EU Authorised Representative (Art. 18) if the manufacturer is established outside the EU +- Identity of the EU Authorised Representative (Art. 18) where one has been appointed — appointment is optional - CE marking declaration See [`../CRA-Compliance-Shortlist.md`](../CRA-Compliance-Shortlist.md) diff --git a/cra-kit/wolfssl-inc-auditor-packet/00-INDEX.md b/cra-kit/wolfssl-inc-auditor-packet/00-INDEX.md index 320df29bb..ed9ff1de8 100644 --- a/cra-kit/wolfssl-inc-auditor-packet/00-INDEX.md +++ b/cra-kit/wolfssl-inc-auditor-packet/00-INDEX.md @@ -5,7 +5,7 @@ | [`classification-statement.md`](classification-statement.md) | Annex III / IV | ✅ Decided — default category (not Annex III/IV), self-certification | | [`conformity-assessment-route.md`](conformity-assessment-route.md) | Art. 32, Annex VIII | ✅ Module A self-assessment | | [`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 | +| [`eu-authorised-representative.md`](eu-authorised-representative.md) | Art. 18 | Reference page — an AR is optional under Art. 18(1); what a mandate covers and how it affects the Art. 14(7) end-point | | [`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; public SLA pending leadership approval | | [`technical-documentation-outline.md`](technical-documentation-outline.md) | Annex VII | 🟠 In progress — outline complete; per-release packet on roadmap | @@ -17,7 +17,7 @@ 2. **`conformity-assessment-route.md`** — why Module A self-assessment fits this classification 3. **`vulnerability-handling-process.md`** — the only continuous obligation 4. **`support-period-policy.md`** — what we commit to maintain, for how long -5. **`eu-authorised-representative.md`** — how a US-established manufacturer satisfies Art. 18 +5. **`eu-authorised-representative.md`** — what Art. 18 offers a manufacturer established outside the EU, and why it is optional 6. **`declaration-of-conformity.template.md`** + **`technical-documentation-outline.md`** + **`ce-marking-statement.md`** — the formal output ## CRA timeline anchors diff --git a/cra-kit/wolfssl-inc-auditor-packet/README.md b/cra-kit/wolfssl-inc-auditor-packet/README.md index f090a107e..d13d8b1ab 100644 --- a/cra-kit/wolfssl-inc-auditor-packet/README.md +++ b/cra-kit/wolfssl-inc-auditor-packet/README.md @@ -26,7 +26,7 @@ fiction. **Not legal advice.** These artefacts are templates and statements of position; they are not, and do not replace, the actual signed legal documents wolfSSL Inc. -files with EU regulators or its EU Authorised Representative. +files with EU regulators, or that an EU Authorised Representative would hold. --- diff --git a/cra-kit/wolfssl-inc-auditor-packet/declaration-of-conformity.template.md b/cra-kit/wolfssl-inc-auditor-packet/declaration-of-conformity.template.md index 5fdf88150..3027e3293 100644 --- a/cra-kit/wolfssl-inc-auditor-packet/declaration-of-conformity.template.md +++ b/cra-kit/wolfssl-inc-auditor-packet/declaration-of-conformity.template.md @@ -25,7 +25,7 @@ template for their own products. - Email: [TO BE FILLED — kept synchronised with `/.well-known/security.txt` once wolfSSL Inc.'s security alias is provisioned] - Website: https://www.wolfssl.com/ -**3. EU Authorised Representative** (Art. 18, required for non-EU manufacturers) +**3. EU Authorised Representative** (Art. 18 — optional; omit this block where no AR is appointed) - Name: [TO BE FILLED — see `eu-authorised-representative.md`] - Postal address: [TO BE FILLED] @@ -72,6 +72,6 @@ No Notified Body involvement required for default-class products. ## Notes for customers adapting this template 1. Fields in `[BRACKETS]` must be filled before signature. -2. The declaration must be drawn up in **at least one of the official languages** of the Member State where the product is placed on the market. English is generally accepted but verify with your EU Authorised Representative. +2. The declaration must be drawn up in **at least one of the official languages** of the Member State where the product is placed on the market. English is generally accepted, but verify against the Member States you place the product in — or ask your EU Authorised Representative, where you have appointed one. 3. The signed declaration is part of the **technical documentation** (Annex VII) and must be retained for **10 years**. 4. The declaration accompanies the product. For software products, this typically means including it in the release tarball, in a `LEGAL/` directory, or alongside the SBOMs. 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 a554046b3..ba81c190a 100644 --- a/cra-kit/wolfssl-inc-auditor-packet/eu-authorised-representative.md +++ b/cra-kit/wolfssl-inc-auditor-packet/eu-authorised-representative.md @@ -1,64 +1,91 @@ -# EU Authorised Representative — wolfSSL Inc. +# EU Authorised Representative — Art. 18 -**Status:** 🟠 In progress — appointment underway; target completion before 11 Sep 2026 +**Status:** Reference page. wolfSSL Inc. is a manufacturer under the CRA and complies with its manufacturer obligations. This page explains the Art. 18 mechanism. It does not publish an appointment, a decision, or a date. **CRA reference:** Art. 18 -## Why an EU AR is required +## An AR is optional, not mandatory -wolfSSL Inc. is established in the **United States** (Edmonds, Washington). CRA -Art. 18 requires manufacturers established outside the EU to appoint, **in -writing**, an Authorised Representative inside the EU before placing a product -on the EU market. The AR: +Art. 18(1) is permissive: -- 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). +> A manufacturer **may**, by a written mandate, appoint an authorised representative. -The AR does **not** transfer manufacturer obligations — wolfSSL Inc. remains -the manufacturer and bears the substantive obligations. The AR is a single -point of contact in the EU. +There is no obligation to appoint one. This holds for manufacturers established +outside the Union as well. The CRA differs here from regimes such as the MDR, +which does require a representative for non-EU manufacturers. -## Current state +The usual back-door route does not apply either. Art. 4 of Regulation (EU) +2019/1020 forces some products to have an economic operator established in the +Union, but Art. 66 CRA adds the CRA only to **Annex I** of that Regulation, +which is the market-surveillance list. It does not bring products with digital +elements within the scope of Art. 4. -🟠 **wolfSSL Inc. is finalising the EU AR appointment.** Two paths were evaluated: +## What an AR does when one is appointed -1. **Use an existing wolfSSL EU presence.** wolfSSL has business operations in - the DACH region (Germany / Austria / Switzerland). Nominating an existing - EU-resident wolfSSL legal entity as the AR is the simplest path if such an - entity exists with the appropriate legal capacity to act as AR. -2. **Contract a third-party AR service.** Several vendors (e.g. Obelis, Authrep, - Casa Group) offer AR-as-a-service across CE-marking regulations. Cost is - typically EUR 1500–4000/year per regulation; lead time 4–6 weeks. +An AR is a natural or legal person established in the Union that holds a written +mandate from the manufacturer (Art. 3(15)). Art. 18(3) sets the minimum scope of +that mandate: -The internal decision is being finalised by wolfSSL leadership. The written -mandate will be in place before 11 Sep 2026 (Art. 14 vulnerability reporting -onset) and certainly before 11 Dec 2027 (full CRA applicability). +- Keep the EU declaration of conformity (Art. 28) and the technical documentation + (Art. 31) available to market surveillance authorities for at least **10 years** + after the product is placed on the market, or for the support period, whichever + is longer. +- Provide an authority with the information and documentation needed to demonstrate + conformity, following a reasoned request. +- Cooperate with authorities on any action taken to eliminate the risks a product + presents. -## Placeholder identity +Art. 18(2) sets a hard limit. The obligations in Art. 13(1) to (11), Art. 13(12) +first subparagraph, and Art. 13(14) cannot form part of the mandate. Design, +development, production, risk assessment, vulnerability handling, and Art. 14 +reporting stay with the manufacturer. An AR is a document custodian and a contact +point. It does not transfer manufacturer obligations. -Once the appointment is signed: +## Effect on the Art. 14 reporting end-point -- **Name:** [TO BE FILLED] -- **Address:** [TO BE FILLED] -- **Email:** [TO BE FILLED] -- **Mandate effective date:** [TO BE FILLED] -- **Mandate scope:** all wolfSSL libraries placed on the EU market by wolfSSL Inc. under CRA. +Art. 14(7) ties the **CSIRT designated as coordinator** to the manufacturer's EU +main establishment. Where there is no EU main establishment, the same paragraph +sets an ordered cascade: + +1. The Member State of the authorised representative acting for the highest number + of the manufacturer's products. +2. The Member State of the importer placing the highest number of products on the + market. +3. The Member State of the distributor making available the highest number of + products. +4. The Member State in which the highest number of users are located. + +An AR therefore fixes the reporting end-point at step 1, in a Member State the +manufacturer chooses. Without an AR the cascade continues, and the end-point is +determined by an importer, a distributor, or by where the users happen to be. The +obligation to report is unaffected either way — only the destination changes. See +[`vulnerability-handling-process.md`](vulnerability-handling-process.md). ## What this means for customers -If your company is established **outside the EU** (US / UK post-Brexit / Asia / -elsewhere), you face the same Art. 18 obligation. wolfSSL's choice of AR does -not satisfy your obligation — you appoint your own. +If your company is established outside the EU, Art. 18 gives you the same option +and imposes no duty. Weigh it on the merits: + +- **A single EU contact point** for market surveillance authorities, rather than + correspondence reaching you through an importer or distributor. +- **Custody of the documentation** inside the Union, which is what an authority + asks for first. +- **A predictable Art. 14 end-point**, chosen by you rather than derived from the + cascade. + +Against that, an AR is a contracted relationship with lead time. Third-party AR +services exist across CE-marking regimes and appointments take weeks to months, +including legal review on both sides. If you decide you want one, start early — +the lead time compounds with conformity assessment timelines. -The single-most-important advice we can give: **start now**. AR appointments -take weeks to months including legal review on both sides; the lead time -compounds with conformity assessment timelines and is the most common -last-minute blocker for non-EU manufacturers. +wolfSSL's own arrangements do not satisfy your Art. 18 position, whichever way you +resolve it. This is a decision for your own legal counsel. ## References - CRA Art. 18 (Authorised Representative) -- CRA Art. 19 (Importer obligations) — what an EU importer carries if no AR is in place +- CRA Art. 3(15) (definition), Art. 13(1)–(14) (obligations that cannot be delegated) +- CRA Art. 14(7) (coordinator CSIRT cascade) +- CRA Art. 19 (Importer obligations) — what an EU importer carries where no AR is in place +- CRA Art. 66 (amendment to Regulation (EU) 2019/1020) - [`../CRA-Compliance-Shortlist.md`](../CRA-Compliance-Shortlist.md) — "Beyond this kit" - [`../CRA-Supply-Chain-Glossary.md`](../CRA-Supply-Chain-Glossary.md) — EU Authorised Representative diff --git a/cra-kit/wolfssl-inc-auditor-packet/technical-documentation-outline.md b/cra-kit/wolfssl-inc-auditor-packet/technical-documentation-outline.md index 98d0409f5..777eb9f1b 100644 --- a/cra-kit/wolfssl-inc-auditor-packet/technical-documentation-outline.md +++ b/cra-kit/wolfssl-inc-auditor-packet/technical-documentation-outline.md @@ -71,7 +71,7 @@ following sections are populated: ## Retention - **10 years** from the date the product is placed on the EU market, or for the duration of the support period (whichever is longer). -- Held by wolfSSL Inc. **and** the EU Authorised Representative ([`eu-authorised-representative.md`](eu-authorised-representative.md)). +- Held by the manufacturer, and also by the EU Authorised Representative where one is appointed ([`eu-authorised-representative.md`](eu-authorised-representative.md)). ## What this means for customers