# Shortlist towards CRA compliance

**Not legal advice.** The EU Cyber Resilience Act applies to **your product** as a whole.
wolfSSL helps on **specific pillars** below; you remain the **manufacturer** for market obligations.

This page is the **product-level shortlist** (what to do). For **software transparency** work
(SBOM, nesting, sample auditor folder), use the **[CRA Kit](README.md)** cheat sheet and
[`CRA-Cheat-Sheet.md`](CRA-Cheat-Sheet.md).

---

## 1. Know your software components

| **Your job (manufacturer)** | **wolfSSL can help** |
|----------------------------|----------------------|
| Run a **survey** of every component in your embedded system or product: What is it? Who maintains it? Is it actively developed? How do you learn about vulnerabilities, fixes, and releases? | **Component SBOMs** (SPDX + CycloneDX) for wolfSSL libraries you ship — `make sbom` / `gen-sbom` |
| Build and maintain a **product SBOM** for the whole thing you place on the EU market | **Continuous vulnerability management**: [security advisories](https://www.wolfssl.com/docs/security-vulnerabilities/), coordinated disclosure, updates — see wolfSSL [`security.txt`](https://www.wolfssl.com/.well-known/security.txt) and [CVD policy](https://www.wolfssl.com/.well-known/vulnerability-disclosure-policy.txt) |
| Own vulnerability **process**, owners, and fix timelines for **your** release | Nest or reference our component SBOM in yours — worked example: [`auditor-packet/`](auditor-packet/) |

**CRA Kit focus:** pillar 1 — who provides what cheat sheet, glossary, scripts, [`SKILL.md`](SKILL.md).

---

## 2. Implement secure boot

| **Your job (manufacturer)** | **wolfSSL can help** |
|----------------------------|----------------------|
| Treat secure boot as one of the **most influential actions** you can take now: firmware that boots **trusted**, with a defined path to **update** when needed | **[wolfBoot](https://www.wolfssl.com/products/wolfboot/)** — secure bootloader for embedded systems |
| Align update mechanics with your **complaint / incident** procedures and required **timelines** under CRA | Integration with wolfSSL/wolfCrypt; see wolfBoot docs and support |

Secure boot is **product architecture**, not something an SBOM file alone satisfies.

---

## 3. Bring remote data processing and data-in-transfer up to compliance

CRA is **not only about software inventory** — it also concerns **data** moving between the device and the network.

| **Your job (manufacturer)** | **wolfSSL can help** |
|----------------------------|----------------------|
| 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) |

---

## 4. Handle vulnerabilities and report on time

CRA imposes **continuous** vulnerability handling obligations on manufacturers
(Art. 13) and a hard **24-hour** reporting clock for actively exploited
vulnerabilities (Art. 14). This is the only CRA pillar that requires **ongoing
operational capacity**, not a one-time deliverable.

| **Your job (manufacturer)** | **wolfSSL can help** |
|----------------------------|----------------------|
| 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 |
| 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
documented process, named owners, and on-call capacity. The 24-hour ENISA clock
starts from your **awareness** of active exploitation, not from public disclosure.

---

## Beyond this kit (structural CRA obligations)

The four pillars above cover **software transparency**. A full CRA conformity
assessment also requires structural obligations that **this kit does not
cover** — flag these to your CRA consultant or counsel **before** assuming
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. |
| **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. |
| **Free security updates** | Art. 13(8) | Minimum 5-year support period for security updates by default (longer if the product's expected lifetime is longer). |
| **Importer / distributor obligations** | Art. 19, 20 | If your product enters the EU via an importer or moves through distributors, additional obligations attach to those parties. |

These are **legal and structural decisions**, not artefacts you can generate
from source code. wolfSSL ships SBOMs, security-policy templates, and the
narrative in this kit; **you** appoint your EU AR, classify your product, run
your conformity assessment, and produce your declaration of conformity. If
you do not yet have a CRA consultant, engaging one for the
classification + AR questions specifically is usually the highest-leverage
early step.

**See how wolfSSL Inc. itself answers each of these.**
[`wolfssl-inc-auditor-packet/`](wolfssl-inc-auditor-packet/) holds the
manufacturer-side filings wolfSSL Inc. ships under CRA: Annex III/IV
classification statement, conformity assessment route, declaration of
conformity template, EU Authorised Representative status, support-period
policy, vulnerability-handling process, technical documentation outline,
and CE marking statement. Where decisions are made, they're stated; where
they're in flight (EU AR appointment, public SLA), the gap is named.
Adapt as a template for your own product.

---

## How this maps to the CRA Kit

| Shortlist pillar | Kit deliverable |
|------------------|-----------------|
| Know your components | Cheat sheet (who provides what), glossary, `auditor-packet/`, generate/validate scripts |
| Secure boot | Out of scope for SBOM files — evaluate **wolfBoot** separately |
| Data in transfer | Configure and document **your** protocol stack; wolfSSL ships crypto libraries, not your full product compliance |
| Vulnerability handling & reporting | Outside scope of SBOM artefacts — see Art. 13/14 obligations above; wolfSSL's own [CVD policy](https://www.wolfssl.com/.well-known/vulnerability-disclosure-policy.txt) and [`security.txt`](https://www.wolfssl.com/.well-known/security.txt) are usable as reference templates |
| Structural CRA obligations (EU AR, Annex III/IV, CE, technical docs, support period) | **Out of scope** for this kit — see "Beyond this kit" section above; engage CRA counsel or consultant |

**You will leave with (presentation Promise):**

1. **Who provides what** — [`CRA-Cheat-Sheet.md`](CRA-Cheat-Sheet.md)  
2. **Worked example** — [`auditor-packet/`](auditor-packet/)  
3. **Helper scripts + AI playbook** — product SBOM, nest wolfSSL, optional bomsh on **Linux CI** + [`SKILL.md`](SKILL.md)

---

## Related wolfSSL products (beyond this kit)

| Area | Product / doc |
|------|----------------|
| TLS / wolfCrypt | [wolfssl.com](https://www.wolfssl.com/) · upstream SBOM reference: [doc/SBOM.md](https://github.com/wolfSSL/wolfssl/blob/master/doc/SBOM.md) |
| Secure boot | [wolfBoot](https://www.wolfssl.com/products/wolfboot/) |
| SSH | wolfSSH |
| MQTT | wolfMQTT |

**Questions about this kit:** support@wolfssl.com · **Security reports:** see [`security.txt`](https://www.wolfssl.com/.well-known/security.txt)