CRA-oriented evidence

The EU Cyber Resilience Act (CRA, Regulation (EU) 2024/2847) is the one requirement regime SBOMFlow offers today, and the cra goal in Goals. When a run chooses it, SBOMFlow helps you see and assemble the engineering evidence that CRA-related obligations concern.

What SBOMFlow maps#

• Annex I (essential requirements): SBOMFlow reports which requirement areas have observed evidence and which have gaps, for the declared product class. Gaps mean evidence not observed, not requirement unmet.
• Annex VII (technical documentation): SBOMFlow can assemble supporting technical-documentation inputs into an evidence index. Completing and judging the documentation is a human task.
• Article 14 (reporting): SBOMFlow can produce unsigned draft early-warning / notification / final-report documents for a human to review and file. SBOMFlow never submits them and never contacts a reporting platform.

What changed in v0.5.0 for Article 14 drafts#

• The draft-only boundary is stricter. A document whose status merely contained the letters "draft" used to satisfy the check; three validators were substring-matching. A status must now actually be a draft status. This is the boundary that keeps every Article 14 output unsigned, so a false pass here was the highest-consequence failure available in the product.
• The pinned Single Reporting Platform field-table extract is current again, so a draft you prepare against it matches the field table the platform publishes. The platform's own availability is a regulator's timetable and is outside SBOMFlow's control; confirm it against the official sources below. Nothing about this changes the boundary: SBOMFlow never files, transmits or signs a report, and never contacts a CSIRT, ENISA or a reporting platform.

Article 14 drafts name the model they were built from#

• Each stage draft records its model. A draft (schema 1.1) carries the Article 14 model version, the model's content digest and, for every source the model pins, its URL, retrieval date and sha256 — so two drafts built from two model editions can be told apart on the page. The Markdown draft shows the same under "Model provenance". The watermark, unsigned: true and submitted: false are unchanged.
• ENISA's statement about an API is quoted with its date. The Single Reporting Platform notes quote the sentence the model pins and say when it was read ("ENISA SRP FAQ as retrieved 2026-09-25: …" since model v4, below), rather than presenting it as what ENISA says today. ENISA revises its FAQ; confirm current behaviour against the official sources below.

Article 14 model v4: the Single Reporting Platform field table as it launched#

After the platform launched, ENISA moved the per-stage field table from its FAQ to the CRA SRP Glossary. The Article 14 model v4 carries the Glossary's table — 40 numbered fields, each marked per stage Required, Required if such information available, By default copied from previous step, or updated, Optional or N/A — and the model it replaces is archived byte for byte, with its older 39-field extract kept as history. What changes for you:

• The SRP-order drafts follow the Glossary's numbering. Each cra-article14-*.SRP-ORDER.DRAFT.md is the re-keying worksheet for its stage: every form field in the form's order, the value SBOMFlow observed where it has one (to check before typing), and a named empty cell where it has none. It also carries ENISA's footnotes to the table and names the two Particular Exceptional Circumstances fields as the manufacturer's legal judgement, never pre-filled.
• sbomflow validate-article14-model reconciles against the new table and lists the three form fields SBOMFlow already records a value for (Product Version, Component name, End of support indicator) with the file that holds each. That is where to look, not a statement about any report.
• The API sentence is the current one, dated: ENISA's FAQ (updated 17 September 2026) says no Application Programming Interface will be provided at the platform's initial release.
• A re-verification tool for the next change. When ENISA updates the table, save the page and run scripts/srp_extract_diff.py from a source checkout: it renders the saved page to a structural extract and compares two extracts field by field, by name, with both retrieval dates. It never fetches anything.

None of this moves the boundary: every Article 14 output is an UNSIGNED DRAFT with submitted: false, and SBOMFlow never files, transmits or submits a report and never contacts ENISA, a CSIRT or the Single Reporting Platform.

Conformity assessment is out of scope#

CRA conformity-assessment routes (self-assessment vs a notified body) depend on product classification and applicable harmonised standards. SBOMFlow records the class you declare and does not choose a route for you.

The disclaimer check is positive, not an absence check#

sbomflow validate checks the disclaimers inside the technical-documentation pack (techdoc-index.json, both the pack disclaimer and the guided-completion one). It requires the denial to be present: the text must exist, must name the boundary it disclaims (conformity or conformant), and must say it does not assert it. Wherever the text names conformity again, the denial has to be there too: a claim joined on by a comma, a bracket, a dash, and or but is refused just as one in its own sentence is.

Stating the rule this way matters. A guard phrased only as "must not contain a claim" is satisfied by deleting the disclaimer, which makes the sentence optional exactly when somebody wants it gone. Here, deleting or watering down the disclaimer fails validation.

The accepted wording is not a fixed pair of phrases, but it is deliberately narrow: the denial must negate the verb of assertion, so "does not assert conformity" and "never asserts ... conformant" are equally acceptable and no site can drift into refusing a wording another site ships. Anything else is refused, including phrasings that read as denials to a person:

The narrowness is the point. Row four negates the object rather than the verb, and a check loose enough to accept it would also accept rows eight and nine — where a stray no elsewhere in the sentence supplies the denial for a claim standing right beside it. A second mention of conformity, joined on by punctuation or by a conjunction, needs a denial of its own. A list continuation ("complete, adequate, or conformant") and a denial whose complement has its own subject ("never asserts a section is conformant") are both still governed by the denial that opened the sentence, and both stay accepted.

What the check is, and is not: it is a positive structural check on the disclaimer text. It requires a present denial of conformity and refuses a claim joined to it; it is not a proof that a document makes no conformity claim anywhere, and it never replaces human review of the pack. One deliberate cost: a line break ends a sentence here, so a denial wrapped across two lines mid-phrase is refused — of the two ways to be wrong, that is the one that fails safe. The accepted forms are documented in the private-review pack.

Every row of that table is executed against the real check by SBOMFlow's own test suite, so this page cannot drift from the code it describes.

EN 18031 view (provisional, thematic only)#

sbomflow standards-view <output-dir> reorganises a run's CRA coverage by EN 18031 section (writing standards-view.json) for reviewers who speak that vocabulary. It is provisional thematic context only: EN 18031 is harmonised under the Radio Equipment Directive (RED), not the CRA — harmonised standards giving a presumption of conformity with the CRA are still being developed and are not yet listed in the Official Journal. This view is not a conformity route, confers no presumption of conformity, and asserts no adequacy; the full disclaimer is carried verbatim inside the artifact.

The packaged mapping also records two dated facts about its own context, as data, without interpreting them:

• Commission Delegated Regulation (EU) 2026/339 repeals Delegated Regulation (EU) 2022/30 — the Radio Equipment Directive act the EN 18031 references rest on — with effect from 11 December 2027. Each EN 18031 entry carries that date on its legal basis; the mapping itself is unchanged and stays provisional and thematic.
• ETSI has 17 draft EN 304 standards supporting the CRA under public enquiry. They are not cited in the Official Journal and give no presumption of conformity, so none appears in this view or in any requirement's references.

Official sources#

Verify all dates and obligations against the primary sources:

• European Commission — Cyber Resilience Act
• European Commission — CRA reporting obligations
• European Commission — CRA conformity assessment
• EUR-Lex — Regulation (EU) 2024/2847
• ENISA — CRA Single Reporting Platform FAQ
• ENISA — CRA SRP Glossary (the per-stage field table)
• EUR-Lex — Delegated Regulation (EU) 2026/339