CRA Comic Classroom: From EU Law and Product Classes to CE Compliance

CRA is the law; CE is the outcome of conformity work

The first plate gives us the essential distinction. Regulation (EU) 2024/2847, the Cyber Resilience Act, is a binding EU legal framework for products with digital elements. It is not a stand-alone certificate that a vendor can buy. A product in scope must satisfy the applicable requirements, complete the appropriate conformity-assessment procedure, maintain technical documentation, and be covered by an EU Declaration of Conformity before the manufacturer affixes the CE marking.

CE is also not an approval badge issued by a central EU authority. By affixing it, the manufacturer declares that the product complies with all applicable EU harmonisation legislation. If LVD, EMC, RED, CRA, or another act applies to the same product, the manufacturer must handle the combined legal set; the product does not receive a separate CE mark for each act.

For semiconductor and security-IP teams, the first question is commercial and architectural: Is the chip, module, firmware, or software component placed on the EU market as a product in its own right, or is it supplied only for integration? Who places the final product on the market under its name or trademark? That manufacturer carries the ultimate product obligations, while upstream suppliers must provide evidence that supports secure integration and lifecycle maintenance.

The engineering translation is clear: define the product boundary, responsible economic operator, intended purpose, foreseeable use, interfaces, and support model before treating compliance as a test project.

Responsibility begins before the 2027 full-application date

Manufacturers carry the main CRA obligations: cybersecurity risk assessment, secure product development, vulnerability handling, security updates, user information, technical documentation, conformity assessment, and incident reporting. Importers and distributors also have verification and cooperation duties; they cannot treat the CE logo as the only compliance check.

The timeline contains the most urgent management point. The CRA applies in full from 11 December 2027, but Article 14 reporting obligations apply from 11 September 2026. Manufacturers must report actively exploited vulnerabilities and severe incidents affecting product security through the CRA Single Reporting Platform. An early warning is due within 24 hours and a full notification within 72 hours.

The final-report deadline depends on the event type. For an actively exploited vulnerability, the final report is due no later than 14 days after a corrective or mitigating measure becomes available. For a severe incident, the final report is due within one month after the 72-hour notification. The comic's single 14-day label is therefore a useful mnemonic but not the complete rule.

Meeting a 24-hour deadline requires an organisational architecture. Product inventory, PSIRT ownership, escalation criteria, logs, version identity, legal review, supplier notification, and reporting authority all have to exist before an incident begins.

Classify the product before selecting the conformity route

The third plate visualises four risk tiers: the default category, important products Class I, important products Class II, and critical products. These are legal product categories, not a score for chip performance. Classification depends on the product's core functionality and the technical descriptions associated with Annexes III and IV.

A memory chip does not become an important product merely because it is a semiconductor. Operating systems, routers, and microprocessors or microcontrollers with security-related functionality can appear in Annex III categories. The team must compare the real marketed functionality, intended purpose, and legal product description, not a convenient marketing label.

Classification changes the conformity route. Default products can generally use Module A internal production control. Important Class I products may use self-assessment only when the manufacturer correctly applies the available harmonised standards, common specifications, or applicable European cybersecurity certification scheme; otherwise third-party assessment is required. Class II is stricter and generally requires notified-body involvement. The plate's suggestion that every Annex IV product follows one fixed EUCC route is a teaching shortcut, not a universal legal rule; the precise route depends on the applicable CRA acts and available schemes.

Create a signed classification decision record: product and version, route to market, manufacturer, direct or indirect connectivity, Annex comparison, exclusions, intended and reasonably foreseeable use, legal rationale, and approving owners. That record becomes the root of the compliance plan.

Annex I defines outcomes that must be traceable to evidence

Annex I contains product-security properties and vulnerability-handling requirements. Secure-by-default configuration, appropriate access control, confidentiality, integrity, availability, data minimisation, reduced attack surface, secure updates, vulnerability identification and remediation, coordinated disclosure, and component inventory all belong to the product lifecycle.

The plate is a helpful map, but not a substitute for the legal text. Build a requirement-to-evidence matrix: requirement, threat, control, implementation location, verification method, result, owner, version, and residual risk. This turns an abstract obligation into an auditable engineering claim.

For example, 'no known exploitable vulnerabilities' needs component inventory, monitoring sources, triage rules, risk decisions, remediation targets, regression tests, and release records. 'Secure by default' needs factory configuration, first-boot flow, least privilege, disabled unnecessary services, and secret-management rules.

An SBOM is not a static spreadsheet delivered once. It must correspond to the shipped build, support queries about affected versions, and connect supplier advisories, CVE analysis, VEX statements where useful, patch releases, and the end-of-support policy.

Self-assessment is still assessment; third parties do not take over lifecycle duty

Module A internal production control means the manufacturer performs the assessment and accepts legal responsibility. It does not mean that no one can inspect the product. Market-surveillance authorities can request the product, EU Declaration of Conformity, and technical documentation and can require corrective action, restriction, withdrawal, or recall.

A notified-body route adds independent review under the applicable conformity modules. It can provide stronger assurance, but the manufacturer still owns configuration control, vulnerability handling, support, reporting, and post-certification changes. Firmware, BOM, open-source dependencies, cloud services, or manufacturing changes cannot be treated as invisible after one assessment.

Teams should select the route early by examining product class, available standards, evidence coverage, gaps, lab capacity, design dependencies, budget, and schedule. Late route selection often reveals that debug lifecycle, update mechanisms, logs, secure boot, supplier contracts, or test interfaces were never designed to produce evidence.

Technical documentation is a maintained product asset. It must remain aligned with the marketed version and be kept available to market-surveillance authorities for at least ten years after the product is placed on the market.

The exam-score metaphor is memorable, but standards are not interchangeable

CC-based evaluation and EUCC, SESIP, FIPS 140-3, and NIST publications solve different problems. EUCC is an EU cybersecurity certification scheme based on Common Criteria. SESIP is commonly used to assess security capabilities in connected platforms and SoCs. FIPS 140-3 validates a cryptographic module. A NIST publication may be a standard, guideline, or reference. These are not different grades of the same examination.

Existing certificates and reports can support CRA evidence, but reuse depends on four alignments: scope, shipped version, covered CRA requirement, and assurance depth. A cryptographic-module certificate rarely proves the final product's support period, incident reporting, user information, update process, or complete vulnerability lifecycle.

European harmonised standards can create a presumption of conformity for the requirements they cover when the standard is formally cited and correctly applied. The Commission's M/606 request covers 41 horizontal and vertical standards, but development and formal harmonisation status must be tracked. This is not an 'exemption list'. A draft, industry standard, or certificate does not automatically have the same legal effect.

The plate's statement that FIPS is 'not accepted in the EU' is too absolute. FIPS 140-3 can still be useful technical evidence for a cryptographic module, but it is not by itself a CRA harmonised standard or proof that the final product satisfies the CRA.

The practical strategy is to perform an Annex I gap analysis now, use mature security standards as structured evidence where relevant, and update the traceability matrix as CRA harmonised standards become available.

Evidence may travel downstream, but legal responsibility cannot be outsourced

The seventh plate shows a healthy evidence chain. An IP supplier can provide security claims, design documentation, test reports, known limitations, integration guidance, SBOM or signed manifests, and vulnerability-notification commitments. The chip maker combines these with SoC threat modelling, system tests, secure lifecycle, and its own integration evidence. The device maker adds firmware, OS, application, backend, default configuration, and field-update evidence.

Reuse requires configuration identity: supplier, component, version, build hash, evaluation scope, assumptions, validity, limitations, and change notices. Enabling an unevaluated debug mode, replacing an entropy source, changing the boot chain, or ignoring the secure-integration guide can invalidate upstream evidence.

The downstream manufacturer must still decide whether the final product meets CRA obligations. A supplier report is evidence input, not a transfer of accountability.

Supplier contracts should therefore cover vulnerability-notification timing, support period, patch delivery, SBOM format, CVE or VEX information, material-change notice, audit rights, and end-of-supply responsibilities. CRA turns these technical needs into procurement requirements.

Replace four myths with a five-step action plan

Myth one is 'we have FIPS, CC, or SESIP, so CRA is solved'. Replace it with evidence mapping that separates reusable assurance from remaining obligations. Myth two is '2027 is far away'. Replace it with a product inventory, PSIRT, event criteria, and a reporting exercise before September 2026.

Myth three is 'we need to buy a CRA certificate'. Replace it with product classification, route selection, technical documentation, EU Declaration of Conformity, and the applicable CE process. Myth four is 'we cannot start until every standard is finished'. Replace it with Annex I risk engineering and continuous standards tracking.

The five steps are: inventory EU-market products and identify the legal manufacturer; classify every product and version; map Annex I requirements to controls and evidence; establish the 24-hour, 72-hour, and final-report workflow; select self-assessment or notified-body involvement and maintain versioned technical documentation.

The highest-value deliverable is not a slide deck. It is a live compliance backlog with owners, dates, evidence links, open risks, and release gates tied to the exact product configuration.

Treat CRA as product engineering, not pre-launch paperwork

CRA turns cybersecurity from recommended practice into a condition of placing products with digital elements on the EU market. Security must be designed, maintained, updated, reported, and evidenced across the support period. CE is the visible outcome of that system, not the beginning of it.

For an RD director, five connected chains matter: product classification, requirement traceability, component and SBOM identity, incident reporting, and supply-chain evidence. Each chain should lead from the shipped version to an owner, decision, and auditable record.

For semiconductor suppliers, this is also a market opportunity. Secure-by-design components, clear security claims, reusable assessment evidence, durable vulnerability handling, and credible update support reduce customer integration risk and accelerate trust.

The final rule is simple: build the evidence while building the product. When architecture, verification, firmware, quality, legal, and supply-chain teams share one traceability model, CRA becomes a forcing function for better engineering rather than a last-minute document exercise.

References

1. Regulation (EU) 2024/2847 ??Cyber Resilience Act: The official legal text, including scope, economic-operator duties, Annexes I, III and IV, conformity assessment, and application dates.
2. European Commission ??CRA legislative summary: Official chapter-by-chapter explanation of scope, manufacturer obligations, product classes, documentation, and conformity routes.
3. European Commission ??CRA reporting obligations: Official guidance on the 11 September 2026 reporting start date and the 24-hour, 72-hour, and final-report stages.
4. ENISA ??CRA Single Reporting Platform: Official platform, routing, reporting-scope, and deadline FAQ.
5. European Commission ??CRA implementation FAQ: Official implementation questions and answers for applying Regulation (EU) 2024/2847.
6. European Commission ??CRA standardisation: Official status and role of M/606, harmonised standards, and presumption of conformity.
7. European Commission ??CE marking: Official explanation of manufacturer responsibility and why CE is not an EU safety approval certificate.