Compliance · Cyber Resilience Act — Regulation (EU) 2024/2847

What Stella Ops produces for the CRA today

The Cyber Resilience Act requires manufacturers of products with digital elements to maintain a software bill of materials, handle vulnerabilities across the support period, keep technical documentation, and report actively exploited vulnerabilities and severe incidents. Reporting obligations start 11 September 2026; the regulation applies in full from 11 December 2027.

Claim boundary

Enabling starts evidence collection in conservative evidence-only mode; it does not claim regulatory compliance.

Stella Ops helps an obligated manufacturer or operator assemble and sign the artefacts a regulator wants. It never files, never certifies, and never makes you compliant — the operator always remains the regulated decision-maker.

Two dates that matter

11 September 2026

Reporting obligations begin

Actively exploited vulnerabilities and severe incidents must be reported: early warning within 24 hours, notification within 72 hours, final report within 14 days.

11 December 2027

Full application

The remaining CRA obligations apply, including technical documentation and conformity assessment before a product is placed on the market.

Shipped artefacts

Everything below is in the product now — v1.0-RC1, release candidate. Each artefact is generated from collected evidence; where evidence is absent, the artefact records the gap.

Annex VII technical documentation

Generates the Annex VII technical file: 11 sections, deterministic output, signed. If a source artefact is missing or has been tampered with, generation fails closed instead of papering over the gap.

Conformity dossier generator

Assembles the conformity-assessment dossier for the Module A, Module B+C, and Module H routes. The dossier feeds your assessment; the assessment decision is not Stella's to make.

Signed product update channel

Product updates ship behind a DSSE-signed manifest with an offline verifier. End-of-life dates are enforced by the channel, not left as advisory text. DSSEDead Simple Signing Envelope - a simple, flexible standard for signing arbitrary data with cryptographic signatures

Coordinated disclosure surface

RFC 9116 security.txt plus a DSSE-signed CSAF advisory feed, so researchers and machines find the same disclosure channel and can verify who signed each advisory.

Support-lifecycle evidence

A signed manifest records the support commitment for each product — at least five years of vulnerability handling, with the dates held as evidence rather than in a policy PDF.

Incident-timeline state machine

Tracks the 24-hour early warning, 72-hour notification, and 14-day final report as explicit states, and builds the ENISA submission envelope for each stage.

Machine-readable SBOM

CycloneDX 1.6/1.7 and SPDX 3.0.1, attached to the OCI image so the SBOM travels with the exact digest it describes. CycloneDXAn open standard format for software bill of materials (SBOM) used across the industry SPDXSoftware Package Data Exchange - another open standard format for SBOMs, widely used in open source

What Stella Ops does not do

The gap list is part of the product. These are the current limits.

No ENISA auto-submission yet

Automatic submission to ENISA waits on the official reporting schema. Today the envelope is written to a filesystem location you control, and you submit it. The deadline clock in the incident timeline runs regardless.

The Declaration of Conformity stays yours

The EU Declaration of Conformity is the manufacturer's own legal act. Stella Ops assembles the dossier behind it; you review it and you sign the DoC.

Enabling a pack proves nothing by itself

A pack collects, orders, and signs evidence. Whether that evidence satisfies the CRA is an assessment only the regulated party — or its assessor — can make.

Two CRA packs, two obligations

The ownership label on each pack names who holds the regulatory obligation. Enabling a pack never transfers it.

CRA Product Security

manufacturer-self

Stella Ops is itself a product with digital elements, so this pack is its own CRA evidence: the coordinated disclosure process, RFC 9116 security.txt, and DSSE-signed advisory feed for Stella Ops as a product.

The obligation covered here is Stella Ops' own, as manufacturer of Stella Ops.

CRA Technical Documentation

manufacturer-customer-support

Annex VII exports, conformity dossiers, and support-lifecycle evidence for your products. Stella Ops supports your documentation duty; the duty stays with you.

The obligation covered here is yours, as manufacturer of your products; Stella Ops supports it.

Stella Ops Compliance workspace listing NIS2, DORA, and CRA evidence packs with retention settings and a priority queue.
The Compliance workspace in the Stella Ops console, shown with demo data. Enabling starts evidence collection in conservative evidence-only mode; it does not claim regulatory compliance.

How it lands operationally

  1. 1

    Enable the pack

    One decision per pack, recorded like any other. Collection starts in conservative evidence-only mode.

  2. 2

    Evidence-only collection

    SBOMs, custody events, advisory state, and incident timelines accumulate against your releases. What has not arrived yet stays visibly outstanding.

  3. 3

    Review workspace

    A reviewer works the priority queue: coverage first, gaps next. Every item carries its state — MISSING, RECORDED, or SIGNED.

  4. 4

    Signed export

    Export the Annex VII file or conformity dossier as a signed bundle. Deterministic: the same evidence yields the same document, so a verifier can re-run it.

How evidence is signed and replayed | SBOM and VEX in depth