# CRA Survival Guide β€” ADLINK > Internal quick reference. Regulation (EU) 2024/2847 ("CRA"). Where documents conflict, the Regulation text wins. Sources: this folder (incl. **CPU and CRA support v1.7**, the Meteor Lake BIOS SBOM) + web (July 2026). ## 1. 🎯 Why this concerns us > **Art 3(1):** "'product with digital elements' means a software or hardware product and its remote data processing solutions, **including software or hardware components being placed on the market separately**" The EU FAQ (Β§1.2) explicitly names **motherboards, integrated circuits, sensors** as in-scope. ADLINK position (ATGD analysis Β§4.1): **every ADLINK product is in scope** β€” each board, module, BIOS or firmware sold separately is its own "product with digital elements" with its own manufacturer obligations. There is **no B2B or industrial exemption**. The following are exempted from the CRA: * Medical devices (Regulation (EU) 2017/745) * In-vitro diagnostics (Regulation (EU) 2017/746) * Motor vehicles (Regulation (EU) 2019/2144) * Certified aeronautical products (Regulation (EU) 2018/1139) * Marine equipment (Directive 2014/90/EU) * National security or defense * Spare parts of repair ## 2. πŸ“… The three dates ```mermaid timeline title CRA timeline 10 Dec 2024 : CRA in force (Art 71) 11 Sep 2026 : Art 14 reporting starts β€” also for products already on the market (Art 69(3)) 11 Dec 2027 : Full compliance β€” non-compliant products may no longer be placed on the EU market beyond : Support-period duties run per product (β‰₯5 y) : Updates stay available β‰₯10 y ``` Transitional rule (Art 69(2)): products *placed* before 11 Dec 2027 stay exempt **unless substantially modified** after that date β€” but Art 14 reporting applies to them anyway. > πŸ›œ **Worked example (EU FAQ 7.2)** β€” placement counts per *unit*, not per model: "a manufacturer has produced 10 000 copies of a router according to a type that is not compliant with the CRA. It places those 10 000 copies on the market before 11 December 2027. Even if those units have not reached their final user … the manufacturer does not need to bring them into compliance … However, that manufacturer **may not produce another 5 000 copies** of that router and place them on the market after 11 December 2027." β†’ old stock stays legal; *new production* of the same non-compliant model becomes illegal (basis of the EOL-silicon end-of-sale dates, Β§8.4). ## 3. πŸ“– Key definitions (verbatim) - **Manufacturer β€” Art 3(13):** "a natural or legal person who develops or manufactures products with digital elements **or has products with digital elements designed, developed or manufactured, and markets them under its name or trademark**, whether for payment, monetisation or free of charge" - **Placing on the market β€” Art 3(21):** "the **first** making available of a product with digital elements on the Union market" (⚠️ per individual unit, not per model) - **Making available β€” Art 3(22):** "the supply … for distribution or use on the Union market in the course of a commercial activity, whether in return for payment or free of charge" - **Substantial modification β€” Art 3(30):** "a change … which affects the compliance … with the essential cybersecurity requirements set out in Part I of Annex I **or** which results in a modification to the intended purpose". Security patches and minor updates are NOT substantial (Recital 39); new features usually are. - **Severe incident β€” Art 14(5):** negatively affects the product's ability to protect availability/authenticity/integrity/confidentiality of data or functions, or leads to introduction/execution of malicious code. - **Spare-parts exemption β€” Art 2(6):** "This Regulation does not apply to **spare parts** … to replace **identical components** … manufactured according to the **same specifications**" (incl. spare parts for legacy products, Recital 29). - ⚠️ "CRA notification" / "CRA report" / "CRA ready" are **not** terms of the Regulation. ## 4. βœ… Duties before first sale (from 11 Dec 2027) 1. Meet **Annex I Part I** essential requirements (secure-by-default, no known exploitable vulns, access control, data protection, attack-surface minimisation, logging, secure updates …) 2. **Cybersecurity risk assessment** (Art 13(2)–(3)) β€” kept in technical documentation β†’ *illustrated in Β§6c* 3. **SBOM** "in a commonly used machine-readable format, covering at the very least the top-level dependencies" (Annex I Part II Β§1) β†’ *illustrated in Β§6a* 4. **CVD policy** + single point of contact for vulnerability reports (Annex I Part II Β§5, Art 13(17)) 5. **Annex II user information** β€” incl. the **end date of the support period stated at time of purchase** (Art 13(19)) 6. **Technical documentation** per Annex VII (Art 13(12), Art 31) 7. **Conformity assessment** β†’ **CE marking + EU Declaration of Conformity** (Art 13(12), Art 28/30) None of this involves an authority up front: **no registration, no submission, no prior authorisation** β€” the CE marking is self-affixed, the DoC travels with the product, and the technical file stays internal, provided to market surveillance only on request (FAQ 6.6/6.7). **Already covered by our IEC 62443-4-1 ML2 cert** (a *process* standard): the risk assessment (#2, Practice 2 threat modelling), the vulnerability- and update-handling processes behind the CVD duty (#4, Practices 6–7), the secure-use documentation feeding #5 (Practice 8), and most evidence for the technical file (#6). **Not covered:** the product-level properties (#1 β†’ 62443-4-2, planned), the SBOM (#3 β€” covered by the syft pipeline) and the CE/DoC paperwork (#7). ⚠ 4-1 is **not yet a harmonised standard** β€” until the CEN/CENELEC ENs are cited in the OJEU, the cert is strong evidence, not an automatic self-assessment ticket. **Classification decides the conformity route** (core-functionality rule, FAQ 3.4 β€” integrating a Class I/II component does *not* upgrade the end product): | Class | ADLINK-relevant examples (Annex III/IV) | Route | | ------------------- | -------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------- | | Default | plain boards/modules without security function | self-assessment (Module A) | | Important Class I | **boot managers (BIOS)**, network interfaces, Β΅P/Β΅C/FPGAs *with security-related functionalities*, operating systems | self-assessment **only if harmonised standard applied**, else notified body | | Important Class II | firewalls/IDS/IPS, tamper-resistant Β΅P/Β΅C | notified body | | Critical (Annex IV) | security boxes, smart-meter gateways, smartcards/secure elements | EU cert scheme | The Class I row decoded: a **harmonised standard** (hEN) is a European norm written by CEN/CENELEC on Commission mandate and **cited in the EU Official Journal**; applying it in full grants *presumption of conformity* (Art 27), which is what lets a Class I product stay in cheap self-assessment (Art 32(2)). No cited hEN applied β†’ an accredited third-party lab (**notified body**) must assess the product β€” cost, queue, and their schedule. ⚠ As of mid-2026 **no CRA hENs are cited yet** (CEN/CENELEC drafting targets ~2026/27): if that slips past Dec 2027, our BIOS β€” Class I β€” needs a notified body until the standards land. That is the bet behind the 62443 track (Β§8.5). ## 5. πŸ”„ Duties during the support period - **Support period β€” Art 13(8):** "the support period shall be **at least five years**", set by expected time in use; Recital 60 expects **longer** for "hardware components such as motherboards or microprocessors" and industrial products. ADLINK commercial line: 10–15-year industrial lifecycles, backed by Intel's free CRA baseline updates plus optional paid LTSC Extended / Premium Support (Β§8.4). - **Handle & remediate vulnerabilities "without delay"**, provide **security updates free of charge** (Annex I Part II Β§2, Β§8). Risk-based: not every CVE needs a patch (FAQ 4.3.1). ⚠ "Free" is bounded: it applies **within the declared support period** (plus the tailor-made-B2B carve-out) β€” support sold *beyond* that period, like Intel Premium or AMI extended support, is legal commerce (Β§8.6). - Each issued update stays **available β‰₯10 years** or the rest of the support period, whichever is longer (Art 13(9)). - Keep technical documentation + DoC **β‰₯10 years** or support period (Art 13(13)). - End-of-support: date must be visible at purchase; notify users when reached (Art 13(19)). - ⚠ Liability trap: an Art 14 report filed while remediation stalls is documentary proof of "known but unfixed" β†’ Product Liability Directive exposure. Report *and* fix. ## 6. πŸ”¬ From SBOM to report β€” the artefacts How the artefacts connect during the support period: ```mermaid flowchart LR S["πŸ“„ SBOM
per release"] --> M["Auto-match vs NVD/OSV
(Dependency-Track)"] M -->|CVE hit| R["βš–οΈ Risk assessment"] R -->|affected| F["πŸ”§ Fix + advisory
+ free signed update"] R -->|not exploitable| V["VEX: 'not affected'
(documented, no patch)"] F --> Q{actively
exploited?} Q -->|yes| A14["⏱ Art 14 clocks β†’ Β§7"] Q -->|no| DONE["support-period duty done"] ``` ### 6a. SBOM β€” the parts list A real one from this folder: the Meteor Lake COM BIOS SBOM ([[engineering/regulations/cra/meteorlake-5-32-9aama-rc0d-e0-fd-30-5272-44-416-bios-cdx.json]]), generated with **syft 1.28.0** (CycloneDX 1.6), **1 670 firmware components** for one BIOS image: ```json { "bomFormat": "CycloneDX", "specVersion": "1.6", "metadata": { "timestamp": "2026-01-16T15:12:25+08:00", "component": { "name": ".../BIOS/MeteorLake_5.32_9AAMA_RC0D.E0.FD.30(5272.44)_416" } }, "components": [ { "type": "firmware", "name": "$/AptioV/.../NESGMeteorLake/ArlRcPkg/PlatPkg/Setup/VfrParser", "version": "IntelRcPkg_0D.E0.FD.30(5272.44)_011", "cpe": "cpe:2.3:o:ami:$/AptioV/...:IntelRcPkg_0D.E0.FD.30(5272.44)_011:*:*:*:*:*:*:*", "purl": "pkg:ami/$/AptioV/.../VfrParser@IntelRcPkg_0D.E0.FD.30(5272.44)_011" } ] } ``` Why it satisfies Annex I Part II Β§1: **machine-readable**, one per release, and every component carries a **`cpe`/`purl` identifier** β€” that is what lets a tool match it against vulnerability databases automatically. The supply chain is visible inside: AMI AptioV codebase + Intel reference code (`IntelRcPkg`), the same Intel + AMI + ADLINK dependency chain that drives the EOL-silicon problem (Β§8.4). **Who delivers it:** the manufacturer of each product ### 6b. CVE β€” the alarm bell A **CVE** (Common Vulnerabilities and Exposures) is the public ID a disclosed vulnerability gets, scored 0–10 via **CVSS** and mapped to affected products via CPE in the NVD database. A published one affecting the AMI AptioV codebase documented in the Β§6a SBOM (LogoFAIL family β€” crafted boot-logo images executing before the OS loads): ```text CVE-2023-39539 published 6 Dec 2023 Description : "AMI AptioV contains a vulnerability in BIOS where a User may cause an unrestricted upload of a PNG Logo file with dangerous type by Local access." Severity : CVSS 3.1 β†’ 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) = Local access, Low complexity, no user interaction, High impact on Confidentiality/Integrity/Availability Affected : AptioV BKS_5.0 < BKS_5.34 ← auto-matched against the SBOM's cpe:2.3:o:ami:... entries (no manual audit of 1 670 components) ``` Match β†’ **risk assessment (Β§6c)** decides: *affected* β†’ pull the fixed AMI module, ship a **signed capsule update free of charge** + advisory; *not affected* β†’ record a VEX receipt (Β§6d). Only a CVE that is being **actively exploited** in the wild starts the Art 14 clocks (Β§7) β€” a merely published CVE is not a reportable event. **Who publishes it**: whoever owns the flawed code ### 6c. Risk assessment β€” the decision record Art 13(3): assess "the cybersecurity risks associated with a product with digital elements and take the outcome of that assessment into account during the planning, design, development…". Example of a module-level assessment as kept in the Annex VII technical file: | # | Asset / interface | Threat | Risk | Decision (Annex I Part I anchor) | | - | ----------------------- | --------------------------------- | ----- | --------------------------------------------------------------------- | | 1 | BIOS SPI flash | malicious reflash / implant | πŸ”΄ H | signed capsule updates only + Intel Boot Guard *(secure updates)* | | 2 | Boot logo parser (Β§6b) | LogoFAIL-class code execution | 🟠 M | patched AMI module; logo not user-replaceable *(no known exploitable vulns)* | | 3 | Debug UART / JTAG | local takeover | 🟠 M | disabled by default, fuse-lockable *(secure-by-default, attack surface)* | | 4 | OS / customer app stack | any | βšͺ n/a | **out of scope β€” OS not part of the product; documented exclusion** (ATGD Β§4.4, Β§8.2 below) | Row 4 documents the responsibility boundary in writing: the risk assessment is **where ADLINK's exclusions become legally visible**. The same applies to the declared **intended purpose** β€” it is a legal scope boundary, and OEM deployment outside it is not ADLINK's risk to cover (FAQ 4.1.4). **Who writes it:** only the manufacturer > πŸ›œ **Worked example (EU FAQ 4.3.1)** β€” the canonical "not every CVE needs a patch": "a manufacturer of a Wi-Fi router finds a buffer overflow vulnerability in one of the software libraries contained in the router's firmware; the manufacturer's **risk assessment, however, shows that the vulnerability cannot be exploited, as the library functions are never called** in the firmware. The manufacturer may be expected … to **document the vulnerability, but may decide not to fix it** with a dedicated update … [and] to remove the unused library in its next regular firmware release." β†’ the documented decision, not the patch, is the compliance artefact. ### 6d. VEX β€” the "no patch needed" receipt The machine-readable form of that documented decision (OpenVEX; customers feed it into their own scanners, so an ADLINK "not affected" silences their alerts too): ```json { "statements": [{ "vulnerability": { "name": "CVE-2023-39539" }, "products": [ "pkg:ami/AptioV/MeteorLake_5.32_9AAMA@RC0D.E0.FD.30(5272.44)_416" ], "status": "not_affected", "justification": "vulnerable_code_not_in_execute_path" }] } ``` One statement per CVE-per-product turns a "don't patch" decision (Β§6c) into auditable Annex I Part II Β§2 evidence β€” and stops 1 670 components' worth of false-positive alarms at every customer running the SBOM through a scanner. **Who issues it: us, per CVE per ADLINK product.** A supplier's VEX ("AptioV not affected") is reusable evidence, but the statement our customers' scanners trust must carry *our* product identifier β€” so it's ours to sign, just as our customers issue their own on top. ## 7. 🚨 Vulnerability response & Art 14 reporting One flow, one chart. However it arrives β€” someone reports it to psirt@, our own scanning finds it, a supplier's CVE goes public, or a supplier pre-warns us confidentially β€” **two questions decide everything**: is it in a shipped product, and is it being exploited. The first decides whether we owe anything; the second starts government clocks. (The four arrival routes are the A–D scenarios of [[engineering/regulations/cra/vulnerability-response-flow.xlsx]]; they all run this same flow and differ only in who sets the disclosure date.) Two terms of art, in plain words: > **Exploited in the wild** β€” someone malicious is *actually using* the flaw against real systems (Art 3(42)). **How we know**: CISA-KEV lists it Β· a supplier or CERT advisory says "exploited" Β· a customer reports an attack to psirt@ Β· a threat-intel sighting. Published exploit code alone does **not** count β€” we treat it as if it did, but the authority filing is then voluntary (Art 15). > > **Embargo** β€” everyone who knows promises silence until the fix is out, so attackers don't get the manual before customers get the defence. Whoever knew first sets the terms: the reporter, us, or the supplier. It ends on fix day, at the 90-day limit, or the instant exploitation is spotted β€” and it binds public disclosure only, never the authority filings. ```mermaid %%{init: {"flowchart": {"wrappingWidth": 440}}}%% flowchart TD classDef auth fill:#fdecea,stroke:#c0392b,stroke-width:2px classDef cust fill:#eaf7ea,stroke:#27ae60,stroke-width:2px classDef supp fill:#eaf0fb,stroke:#2c5aa0,stroke-width:2px classDef done fill:#f4f4f4,stroke:#999 RP["πŸ“¨ REPORTED to us β€” customer or researcher
psirt#64;adlinktech.com Β· security.txt Β· or forwarded
by the national CSIRT/ENISA (Art 15(4))
ack ≀5 wd Β· verdict ≀10 wd: confirmed? severity? fix plan (BSI Β§4.4.8)
anonymous reports: no reply clocks β€” but the channel must exist (Β§4.4.9)"] FD["πŸ” FOUND by us β€” internal discovery
scanner match of our SBOMs vs NVD/OSV (Dependency-Track) Β·
CI/CD gate (Trivy Β· Grype Β· cve-bin-tool Β· osv-scanner) Β·
pentest Β· internal audit
no counterparty β€” we own fix and disclosure date"] PB["πŸ“’ PUBLIC feed β€” the supplier's CVE is already out
NVD Β· EUVD Β· CISA KEV (KEV hit = exploited + P1) Β· RSS Β·
vendor bulletins: Intel PSIRT Β· AMD Β· NXP SEN Β·
distro lists: Ubuntu USN Β· Debian DSA Β· SUSE
⚠ watching these is due diligence, not optional (Recital 34)
already public β†’ no confidentiality hold, move fast (Annex I Pt II Β§2)"] PRE["🀫 PRE-NOTIFIED under embargo β€” supplier advance notice
Intel / AMD / NXP advance-notice programs, under NDA
log the embargo terms + the supplier's coordinated disclosure date
their date binds our publication β€” never our authority filings"] RP --> IN FD --> IN PB --> IN PRE --> IN IN["πŸ”” open confidential ticket Β· assign the PSIRT lead
Tβ‚€ = awareness β€” every clock measures from here"] IN --> A{"in a shipped
product?
check the SBOM"} A -->|no| OUT["πŸ—ƒ LOG & CLOSE β€” nothing on the market is affected
in unsold stock? fix it before selling (Annex I Pt I Β§2(a))
legacy pre-2027 products: no fix duty (Art 69(2)) β€”
but REPORT still applies (Art 69(3))"]:::done A -->|yes| SEV["βš–οΈ SET PRIORITY β€” our PSIRT lead decides, not the CVE feed:
P1/P2/P3 from the CVSS score + context β€” exploitation, public
exploit code, or network exposure force P1
patch targets 7 d / 30 d / ≀90 d (our policy reading of
'without delay', Annex I Pt II Β§2 β€” not law)"] SEV --> E{"exploited in
the wild?
tripwires above"} E -->|"yes β€” the clock started when we first knew"| R["πŸ› REPORT to the authority β€” only the manufacturer files (Art 14(1)):
ADLINK-brand product β†’ that's us β€” TPE or ATG staff file with the
German CSIRT (BSI) on the ENISA platform
ODM / partner rebrand β†’ the brand owner files, we feed them the fix (Β§9)
⏱ warning ≀24 h Β· notification ≀72 h Β· final ≀14 d after the fix
severe incident: final ≀1 month Β· BSI may demand status updates
⚠ nothing pauses this β€” no NDA, embargo, or pending analysis
(the platform keeps filings confidential until a fix exists, Recital 69)"]:::auth E -->|no| H["🀝 FIX QUIETLY, under embargo β€” no filing due (voluntary only, Art 15)
agree the disclosure date with whoever else knows:
the reporter and/or the supplier β€” only we know? we set it
publish ≀90 d, +90 d once with BSI (BSI Β§4.4.10)
deadline with no fix? publish a workaround β€” never silence
already public? nothing to protect, move fast
exploitation spotted later β†’ REPORT immediately"] R --> RU["πŸ“£ WARN AFFECTED CUSTOMERS β€” workarounds now,
before any patch exists (Art 14(8))"]:::cust RU --> W H --> W{"whose code
is broken?"} W -->|ours| FO["πŸ›  OUR CODE β€” we own the patch and the disclosure date
no CVE ID yet? we request one from MITRE (or another CNA)"] W -->|"the supplier's"| UP["🏭 ENGAGE THE SUPPLIER'S PSIRT β€” notify under NDA
(unless they told us first) Β· share any fix we develop (Art 13(6))
the CVE ID comes from their CNA Β· chase them β€”
the CRA duty stays ours (Art 13(8), 14(8))
⚠ their flaw already public? check the production line:
shipping affected units is illegal (Annex I Pt I Β§2(a)) β†’
halt/rework, up to recall (Art 13(21))"]:::supp FO --> FX UP --> FX["πŸ”§ FIX β€” signed update Β· validation gate
(smoke, regression, reproducible build) Β· refresh the SBOM"] FX --> P["πŸ“£ PUBLISH β€” advisory: what Β· which products Β· impact Β· severity Β·
remedy (Annex I Pt II Β§4) β†’ all registered contacts + public security page
machine-readable too: CSAF 2.0 at /.well-known/csaf β€” customer tools auto-ingest
EU vulnerability database on request Β· update free of charge (Pt II Β§8)
optional early patch to key customers under NDA Β· credit the reporter"]:::cust P --> C["βœ… CLOSE β€” tell the reporter it's done
keep tech file + DoC β‰₯10 y (Art 13(13)) Β· post-incident review"]:::done ``` **Who we talk to:** πŸ”΄ the authority Β· 🟒 customers Β· πŸ”΅ the supplier Β· βšͺ done β€” plain boxes are internal work. The names on the map: **CISA KEV** β€” the US government's *Known Exploited Vulnerabilities* catalogue: CVEs with confirmed real-world attacks; a KEV entry = "exploited in the wild", full stop. **MITRE / CNA** β€” MITRE runs the CVE programme; a CNA (*CVE Numbering Authority*) is an organisation entitled to assign CVE IDs. Suppliers are CNAs for their own code (Intel, AMD, NXP, AMI…); for flaws in **our** code we request the ID from MITRE. **ENISA** β€” the EU cybersecurity agency: runs the single reporting platform where Art 14 filings land (live Sep 2026) and the EU vulnerability database (EUVD). **BSI** β€” Germany's federal cybersecurity office, our coordinating **CSIRT** (national incident-response team) and first reader of every filing; Germany because that's where our EU representative ATG sits (Art 14(7)) β€” the endpoint is German, but the *filing* is the manufacturer's duty, so TP HQ can submit directly (final TPE↔ATG allocation: the open SOP question, Β§13). **CSAF 2.0** β€” the OASIS standard for *machine-readable* advisories: JSON documents served from `/.well-known/csaf/provider-metadata.json`, which customers' vulnerability-tracking tools discover and pull automatically and correlate with our SBOM via the product identifiers β€” the machine channel that makes the PUBLISH box land in tools, not inboxes (BSI co-authored it and runs a national CSAF aggregator; their free editor is Secvisogram). VEX (Β§6d) rides the same rails as a CSAF profile. ### The communications, step by step The flowchart above carries the decisions; this is **every message that crosses a company boundary** β€” channel and deadline on each arrow: ```mermaid sequenceDiagram autonumber participant S as Source
(reporter Β· supplier Β· feeds) participant A as ADLINK PSIRT
(TPE files, ATG deputy) participant U as Supplier PSIRT participant C as CSIRT (BSI)
via ENISA platform participant K as Customers S->>A: report via psirt#64;adlinktech.com / security.txt β€” Tβ‚€, all clocks start A-->>S: ack ≀5 wd Β· verdict ≀10 wd: confirmed? severity? fix plan (BSI Β§4.4.8) alt exploited in the wild A->>C: ⏱ ≀24 h β€” early warning (Art 14(2)) A->>K: warn + workarounds β€” before any patch exists (Art 14(8)) A->>C: ⏱ ≀72 h β€” full notification C-->>A: may demand intermediate status reports (Art 14(6)) else not exploited Note over A: embargo β€” nothing filed, nothing published
disclosure date agreed with whoever else knows end opt flaw in supplier code A->>U: notify under NDA (unless they told us first) + share our fix code (Art 13(6)) U-->>A: advisory Β· fixed module Β· CVE ID from their CNA end Note over A: our code? request the CVE ID from MITRE/CNA
build + sign the fix Β· refresh SBOM A-->>K: optional pre-notification of the patch under NDA (Annex I Pt II Β§4) A->>K: advisory β€” email to ALL registered contacts + CSAF 2.0 at /.well-known/csaf (+ VEX) A->>C: EUVD publication on request (BSI Β§4.4.10) opt exploited rail only A->>C: ⏱ ≀14 d after the fix β€” final report (Art 14(2)(c)) end A-->>S: CVD complete β€” thank & credit the reporter ``` Reading it: `alt` = the either/or fork at the *exploited?* diamond; `opt` = only when the condition holds; dashed arrows = courtesy/quality-of-service messages, solid = duties. ## 8. πŸ› ADLINK positions (settled) ### 8.1 Entities **ADLINK Taipei / Shanghai = component-level manufacturers** β€” full CRA manufacturer duties, but at *component* level (each board/module/BIOS is its own product, Β§1). **ATG (Germany) = importer (Art 19) + EU authorised representative (Art 18)**. The CSIRT endpoint is German (BSI) β€” but the Art 14 filing itself is a manufacturer duty and can be done from Taipei (Β§7). Who is manufacturer of the *end product*: whoever brands it β†’ Β§9. ### 8.2 OS/BSP baseline **BSPs and OS images are not sold β€” no CRA manufacturer duty is assumed for them** (C. Lutz, Jul 2026). What ADLINK stands behind is **its in-house binaries** (ADLINK-authored drivers, firmware, tools): SBOM + security updates through the product's support period. The BSP is a **reference/template** β€” an example integration, not a maintained product: the kernel, bootloader and upstream OSS inside it are the **customer's to maintain** in their end product, as its manufacturer. Commercial OS (Windows/Ubuntu): the OS vendor's long-term support. Beyond the baseline, maintenance is negotiable **case by case for big projects, by contract** (paid LTS). ```mermaid flowchart LR A{who supplies
the OS layer?} -->|"commercial OS
Windows / Ubuntu"| C["ADLINK: SBOM + vuln monitoring
OS vendor: long-term support"] A -->|"ADLINK BSP
= reference/template"| D["ADLINK: in-house binaries only
drivers/firmware: SBOM + updates
customer maintains the rest
kernel Β· bootloader Β· upstream OSS
paid LTS by contract, case by case"] A -->|"customer's own
OS / image"| G["no ADLINK duty on the OS layer
documented exclusion, Β§6c row 4"] ``` Two caveats keep the baseline defensible: **(a)** an OS image **pre-installed on a sold product** is legally part of that product (the Readiness Statement's scope even says "device drivers, and pre-installed operating system images") β€” there the exclusion must be carried by the documented risk assessment + declared intended purpose (Β§6c row 4), and our in-house binaries in the image stay ours to patch; **(b)** "free" doesn't exempt β€” supplying software in the course of a commercial activity is "making available" even free of charge (Art 3(22)) β€” so the BSP must ship **explicitly labelled as a reference design without support commitment**, never as a maintained product. Supersedes the earlier "ADLINK BSP: full CRA duty" tree ([[engineering/regulations/cra/adlink-os-and-bsp-responsability.png]]) β€” message alignment tracked in Β§13. ### 8.3 The evidence package β€” what the OEM gets from us The deliverables that let the **OEM certify their branded end product** with our component inside β€” each mapped to the OEM duty it serves (this is the same package AMI promises us one level down, Β§8.6): 1. **CE marking + EU DoC of the component** (post-2027) β†’ the OEM's **Art 13(5) due-diligence** evidence. ⚠ Our DoC never *transfers* β€” the OEM still runs their own conformity assessment; ours is an input. 2. **SBOM per release** (CycloneDX, Β§6a) β†’ direct input to the OEM's product-level SBOM (Annex I Pt II Β§1). 3. **Declared support-period end date** per component β†’ feeds the OEM's own support-period declaration (Art 13(19)); blocked upstream today for some silicon (Β§13a). 4. **Security advisories + vulnerability feed + VEX** (Β§6d) β†’ the OEM's vulnerability handling; on an actively exploited vulnerability we notify affected OEMs **in time for their own Art 14 clocks**. 5. **Integrator information** (Annex II): secure-integration instructions, intended purpose, known integration-relevant risks β†’ the OEM's user documentation and risk assessment. 6. **Technical-documentation input under NDA** on request β†’ the OEM's Annex VII file / notified-body evidence. 7. **Process & product certificates** β€” 62443-4-1 ML2 today, 62443-4-2 targeted (Β§8.5) β†’ reusable third-party evidence in the OEM's file. Integrating our Class I component (e.g. BIOS) does **not** drag the OEM's product into Class I (core-functionality rule, FAQ 3.4). ### 8.4 Silicon support β€” position as of *CPU and CRA support* v1.7 (17 Jul 2026) Intel's **"Post EU CRA Support" program, effective 11 Dec 2027** β€” free baseline security updates "as required by CRA", optional paid **LTSC Extended / Premium Support** on top, and the intention to **publish CRA Declarations of Conformity incl. security-update durations**. ⚠ Scope per Intel's own slide: standard support = Core/Entry launched **after Q3'2021**, plus exactly three named legacy exceptions β€” **Tiger Lake, Comet Lake, Elkhart Lake (Atom x6000E / Pentium & Celeron N+J)**. - **Core families keep "FREE Baseline Security Updates (CRA)"**: Coffee/Whiskey/Comet, Tiger (+UP3), Alder, Raptor (+R), Bartlett; Atom: Elkhart, Alder-N, Amston, Twin, Moon Lake. - **Apollo Lake β€” REVERSED in v1.7: "CRA support is unknown today".** v1.5's free-baseline-to-2030 claim is retracted; Apollo Lake (2016) sits outside Intel's after-Q3'2021 scope and is not a named exception. The 2030 date on the availability table is **Last Time Ship (supply), not security updates** β€” the two must never be conflated (Β§13a's date discipline). - **Bay Trail, Braswell**: no CRA support; EOS announcement lets them **sell until 12/2027** only; PDN to be issued. **Broadwell DE, Denverton (+R)**: stop before Dec 2027. **Ice Lake D (+R)**: undefined. **V2000 (AMD)**: "????" β€” inquiry running (Β§13a). Migration path: Alder Lake-N / Amston / Twin Lake. Intel remains the *only* vendor with a written position β€” non-Intel status in Β§13a. Commercial angle: an integrator who gets no vulnerability support on a legacy component is expected to **"switch out the affected component"** (FAQ 4.3.6) β€” supplier cooperation is a design-win lever. ### 8.5 Certification lever IEC 62443-4-1 ML2 (cert FR_Cyber10248, LCIE, 25 Nov 2025) + ISO/IEC 27001:2022 position us for the future harmonised ENs that keep Class I products in **self-assessment** β€” but see the Β§4 nuance: 4-1 is not itself a harmonised standard yet. Next step: **62443-4-2 (product level)** β€” per the Β§9 doctrine the component-manufacturer certification target; coverage map in Β§4. ### 8.6 AMI (BIOS codebase upstream) Per the Legal Memo (security@ami.com): PSIRT advisories **incl. confirmation of active exploitation** (feeds our Art 14 clock) with prompt customer notification; SBOM per firmware release (SPDX/CycloneDX); CE-marking + EU DoC per applicable firmware line before Dec 2027; integrator information package; a **declared support period per firmware product**. On extended support the memo says only: *"Customers requiring extended support periods … should discuss this with their AMI account representative"* β€” **no program name, scope, price or dates**. The "paid Extended Support from Jul 2026 (Apollo-era AptioV)" circulating in customer questions is **not in our records β€” unverified** (Β§13a). **Why paid extended support is CRA-legal** (expect the sales question): the free-of-charge duty (Annex I Pt II Β§8) runs only **inside the declared support period** β€” beyond it there is *no* update duty at all, so support past that date is ordinary commercial business. And Apollo-era firmware placed before 11 Dec 2027 is **legacy (Art 69(2))** β€” no Annex I Pt II duties bind it in the first place. The guardrail sits on the other side: the declared period itself can't be gamed short β€” β‰₯5 y and "reflective of expected use" (Art 13(8), Recital 60 expects longer for industrial); AMI's memo mirrors that wording. ⚠ The memo is the *only* reliable AMI input: the BIOS department has produced nothing usable, so **per-platform support-period end dates are still open** β€” legal request running (Β§13a). ### 8.7 Open source Non-commercial projects are largely out of scope (Recitals 18–19; Art 24 creates only a light "steward" regime) β€” the CRA duties for integrated OSS fall on the commercial manufacturer integrating it: under the Β§8.2 baseline that is the **customer** for BSP content. ⚠ Sales Q&A Q12 still pitches "ADLINK-maintained BSPs" as the differentiator β€” needs realignment to the baseline (Β§13). ## 9. 🎭 Which hat is ADLINK wearing? β€” roles & deliverables **Doctrine: whoever applies the final branding is the PRODUCT manufacturer.** ADLINK Taipei/Shanghai are **component-level manufacturers** β€” they carry the CRA manufacturer duties *for the component* (each board/module/BIOS is its own product, Β§1: CE+DoC, SBOM, support period, Art 14 reporting, 62443-4-2 as the target evidence) and hand the OEM the **Β§8.3 evidence package so the OEM can legally certify the branded end product**. ADLINK Germany is the **importer**. We never certify the customer's product β€” we make it certifiable. > **Art 21:** "An importer or distributor shall be considered to be a manufacturer … where that importer or distributor places a product with digital elements on the market **under its name or trademark** or carries out a **substantial modification** of a product with digital elements already placed on the market." | ADLINK's role | CRA manufacturer is | ADLINK delivers | | --- | --- | --- | | **Component supplier** (the default) β€” ADLINK-brand board/module/BIOS into the customer's branded product | **ADLINK** for the component Β· **the OEM** for the end product | full component-level Art 13/14 duties + the **Β§8.3 evidence package** for the OEM's certification | | **ODM** β€” customer's brand on an ADLINK-built product | **Customer**, even for the board (Art 3(13): "has … manufactured, and markets them under its name or trademark") | deliverables **by contract only** (SBOM, tech-file input, vulnerability feed β€” a negotiated subset of Β§8.3). **Escalate to legal.** | | **Upstream of a rebrander** β€” partner relabels a bought ADLINK product | **Partner** (Art 21) | nothing new β€” our DoC does not transfer; the partner needs own conformity, our Β§8.3 package is their input | | **Upstream of a modifier** β€” partner changes the product | **substantial** change (Art 3(30)) β†’ partner becomes manufacturer of the modified product; minor change β†’ duties stay with ADLINK | assess case by case, **document the boundary** in writing | | **Importer** β€” ATG brings ADTW components into the EU | ADTW stays component manufacturer | ATG: Art 19 checks (CE/DoC present, docs complete), cooperation with authorities | ## 10. 🚫 Sales guardrails β€” never say 1. ~~"CRA certified"~~ β†’ there is no CRA certificate; say "designed to meet CRA requirements / self-assessed conformity". 2. ~~"Our module makes your product compliant"~~ β†’ the end-product manufacturer always keeps own obligations. 3. ~~"B2B / industrial products are exempt"~~ β†’ they are not. 4. Escalate: risk classification, contractual SLAs, ODM/rebrand deals β†’ M. GΓΌler / C. Lutz / legal. ## 11. πŸ’Ά Penalties (Art 64) - Essential requirements, Art 13/14 breaches: up to **€15 M or 2.5 %** worldwide turnover. - Other operator obligations (Arts 18–23, 28, …): up to **€10 M or 2 %**. - Incorrect/misleading info to authorities: up to **€5 M or 1 %**. ## 12. 🌍 Ecosystem snapshot (July 2026) - **Intel** β€” publicly quiet, but under CNDA (v1.7 deck, Intel slides May 2026 rev.): **Post-EU-CRA support program**, CRA DoCs with declared update durations, extended silicon availability β€” but Apollo Lake now outside the free program (Β§8.4). **NXP** β€” public page commits to CRA "as it applies to semiconductors"; SDK SBOMs, OEM app notes. **AMD** β€” public page "fully committed", aligning DoC/SBOM/support-period documentation. **Microchip** β€” dedicated CRA solutions line. ⚠ Read these as *marketing posture, not commitments*: what each vendor has actually given ADLINK in writing is tracked in Β§13a β€” and outside Intel, that is nothing. - **Kontron** (KontronOS + KontronGrid, sold as CRA enabler), **congatec** (aReady.COM, "ultimate responsibility rests on OEMs"), **Tria/Avnet** (modules + Witekio SBOM/CVE services), **Advantech** (**already holds product-level IEC 62443-4-2** on RSB-3810 with Bureau Veritas; Ubuntu Pro 10-y LTS bundle). - Takeaways: the "OEM owns end-product compliance, we enable" framing is industry standard; everyone monetises CRA via hardened-OS/LTS offers (mirrors the ADLINK LTS/BSP model); **62443-4-2 is the gap to close vs Advantech**; nobody claims "CRA certified". ## 13. ❓ Open items - **Driver responsibility** (Intel et al.) β€” undecided (ATGD leaves it "to be discussed"). - **OS/BSP message alignment** β€” the Β§8.2 baseline (BSP = unmaintained reference, in-house binaries only, no BSP/OS sold) contradicts four existing artefacts: the strategy doc's Yocto-LTS commitment, Sales Q&A Q12's "ADLINK-maintained BSP" pitch, the Readiness Statement's "pre-installed operating system images" scope, and the old full-CRA-duty decision tree (png). All need re-wording; plus **legal sign-off** on the "reference design, no support commitment" framing against the Art 3(22) free-distribution risk. - **SOP** ownership/roles (GM, QM, ATG↔ADTW split) β€” unresolved, WiP skeleton only. - **Spare-parts exemption (Art 2(6))** never analysed for our replacement-board business β€” potential relief, worth a formal position. - Intel-side gaps from the v1.7 roadmaps: **Apollo Lake** ("CRA support unknown today" β€” fallback would be AMI extended support, terms unverified, Β§8.6), **Ice Lake D (+Refresh)**, **Express-VR7** β€” CRA support status undefined. - ⚠ **`security.txt` not published** β€” the one-time prerequisite the whole Β§7 flow assumes. Art 13(17) demands a single point of contact; BSI TR-03183-3 Β§4.2 names RFC 9116 `security.txt` at `/.well-known/` as the mechanism, and requires **more than the RFC minimum**: `Canonical` reachable without redirects, contacts in fixed order (PSIRT β†’ CSIRT β†’ web form), OpenPGP `Encryption` keys, `en` in `Preferred-Languages`. Cheap to fix; until then a researcher has no machine-discoverable route to us and may simply publish. Owner unassigned. - **No CSAF publishing endpoint** β€” the outbound twin of `security.txt`: advisories today would go out as web pages/emails, not machine-readable **CSAF 2.0** at `/.well-known/csaf/` (Β§7 glossary). Until it exists, customers must hand-copy our advisories into their tracking tools. One-time infrastructure + per-advisory JSON authoring (Secvisogram); owner unassigned. ### 13a. πŸ”Œ Silicon & firmware support-period clarification β€” status (as of this revision) ⚠ **Say which date you mean.** Three different dates get called "EOS" in vendor mail and they diverge by years: **end of sale / Last Time Ship** (last date we may ship β€” the Β§8.4 Bay Trail / Broadwell DE markers) Β· **EOL** (vendor stops validation, microcode, fixes β€” Bay Trail, Apollo) Β· **support-period end date** (the CRA term, Art 13(19) β€” last date security updates are provided). Intel's program pointedly gives **5 y of free baseline updates *after* product EOL**, so EOL β‰  end of support. This section is about the **support-period end date** only; use that phrase in vendor requests. The **critical open risk**. Art 13(19) requires the **end date of the support period stated at time of purchase**, and Art 13(8) sets a **β‰₯5-year** floor. ADLINK cannot declare a support-period end date for a module when the silicon or BIOS vendor underneath it will not give us theirs. Every row below that is not "written" is a product we cannot yet lawfully sell into the EU after **11 Dec 2027**. | Vendor | What we actually have | Gap / next step | | ------------ | -------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Intel** | written, under CNDA: Post-EU-CRA program, free baseline updates, CRA DoCs, roadmap Last-Time-Ship dates (Β§8.4) | the only solid position β€” but scope-limited: **Apollo Lake fell out in v1.7** ("unknown today"), Ice Lake D / Express-VR7 undefined | | **AMD** | verbal only, re-confirmed 15 Jul 2026 | **oral** commitment expected in ~1–2 weeks, **paper** later; **V2000** support period undefined | | **NXP** | public CRA page only | **no per-product support-period dates**; inquiry running (Henri) since ~w/c 6 Jul 2026. Even **i.MX6** is unconfirmed β†’ decide whether **ADLINK declares its own support end date before Sep 2026** | | **MediaTek** | nothing | clarification request 13 Sep 2026, reminded β€” no reply | | **Qualcomm** | nothing | clarification request 13 Sep 2026 β€” no reply | | **AMI** | Legal Memo only (Β§8.6) | BIOS dept. information unusable β†’ **legal request issued** demanding support-period end dates for all Intel/AMD AptioV UEFI platforms Β· **verify the customer-reported "paid Extended Support from Jul 2026, Apollo-era AptioV"** β€” scope/price/dates not in our records | Two consequences worth acting on: (1) where a vendor stays silent, the fallback is an **ADLINK-declared** support period we can actually honour β€” or a **PDN/EOL of our own**, which is the live i.MX6 question; (2) vendor silence is itself the argument for the FAQ 4.3.6 "switch out the affected component" migration story (Β§8.4) β€” it turns a supply problem into a design-win pitch for Intel-based and ADLINK-BSP platforms. ## 14. πŸ“‡ Contacts & sources **PSIRT:** psirt@adlinktech.com Β· **Escalation:** mustafa.gueler@ / christophe.lutz@adlinktech.com Β· **Product Security:** fencer.kao@ Β· **InfoSec:** felix.ho@adlinktech.com Folder sources: [[engineering/regulations/cra/cra-regulation-eu-2024-2847]] Β· [[engineering/regulations/cra/faqs-on-the-cra-v12-6qbciptphhzxljscvbcere4yibo-122331|EU FAQ v1.2]] Β· [[adlink-cra-strategy]] Β· **[[engineering/regulations/cra/vulnerability-response-flow.xlsx]]** (intake scenarios, terms glossary, references β†’ Β§7) Β· ATGD_CRA_regulation_line_of_reasoning.pdf Β· ADLINK_CRA_Sales_QA.xlsx Β· [[implementation]] Β· AMI Legal Memo (PDF) Β· **CPU and CRA support-v1.7.pptx** (17 Jul 2026, "Apollo Lake update" β€” supersedes v1.5 and the June PDF) Β· ADLINK_CRA_EOL_Migration (PDF) Β· [[20-02-2026-adlink-eu-cyber-resilience-act-readiness-statement|Readiness Statement]] Β· [[engineering/regulations/cra/meteorlake-5-32-9aama-rc0d-e0-fd-30-5272-44-416-bios-cdx.json|MTL BIOS SBOM]] Β· [[engineering/regulations/cra/adlink-os-and-bsp-responsability.png|OS/BSP decision tree]] Β· [[x20-edge-cra-analysis-internal|B&R X20 Edge analysis (internal)]] Β· [[x20-edge-cra-responsibility-matrix-b-r|B&R X20 Edge matrix (customer-facing)]] Normative for Β§7: [BSI TR-03183-1](https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TR03183/BSI-TR-03183-1_v0_10_0.pdf) (general) Β· [-2](https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TR03183/BSI-TR-03183-2_v2_1_0.pdf) (SBOM) Β· [-3 v1.0.0](https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TR03183/BSI-TR-03183-3_v1_0_0.pdf) (CVD, security.txt, 90-day disclosure) Β· [ENISA SRP](https://www.enisa.europa.eu/topics/product-security-and-certification/single-reporting-platform-srp) Β· [EUVD](https://euvd.enisa.europa.eu/) Β· [EC CRA reporting](https://digital-strategy.ec.europa.eu/en/policies/cra-reporting) Β· [RFC 9116](https://www.rfc-editor.org/rfc/rfc9116) External: [NXP CRA](https://www.nxp.com/applications/technologies/security/eu-cyber-resilience-act-cra:CYBER-RESILIENCE-ACT) Β· [AMD CRA](https://www.amd.com/en/solutions/security/eu-cyber-resilience-act.html) Β· [Kontron CRA](https://www.kontron.com/en/landing-pages/cyber-resilience-act-solutions-for-embedded-and-edge-systems) Β· [congatec blog](https://blog.congatec.com/en/lifting-the-fog-the-eu-cyber-resilience-act-and-its-impact-on-embedded-systems) Β· [Tria CRA](https://www.tria-technologies.com/cyber-resilience-act-tria/) Β· [Advantech 62443/CRA](https://www.advantech.com/en-us/resources/faq/things-you-need-to-know-about-iec-62443-and-the-cyber-resilience-act-cra) Β· [Microchip CRA](https://www.microchip.com/en-us/solutions/technologies/embedded-security/cyber-resilience-act)