Cyber Resilience Act: The Product Baseline You Justify

Most CRA writing points at two clocks: the Article 14 reporting duty for actively exploited vulnerabilities, and the software bill of materials in Annex I Part II. Both are process obligations, discharged by a team with an incident channel and a build pipeline. Part I is different: thirteen properties your product either has or does not — plus a record of which you decided you owe, and why.

That record is the part teams skip, and the part the Regulation is most explicit about. What follows treats the applicability decision as a build artefact, not a document written before an audit. It assumes scope is settled; if not, start with the CRA scope piece and its manufacturer-versus-steward split.

What Annex I Part I Actually Says

Part I of Annex I to Regulation (EU) 2024/2847 covers "[c]ybersecurity requirements relating to the properties of products with digital elements". It opens with one sentence, numbered (1): "Products with digital elements shall be designed, developed and produced in such a way that they ensure an appropriate level of cybersecurity based on the risks."

The next line carries the whole structure. Point (2) begins: "On the basis of the cybersecurity risk assessment referred to in Article 13(2) and where applicable, products with digital elements shall:" — then runs (a) to (m). Point (1) has no such preamble, and nothing in Annex I lets a risk assessment switch it off.

Unconditional does not mean outside the assessment. Article 13(3) is precise: the assessment "shall indicate whether and, if so in what manner, the security requirements set out in Part I, point (2), of Annex I are applicable", and "[i]t shall also indicate how the manufacturer is to apply Part I, point (1)". Whether is asked only of point (2); how is asked of both. The Commission's non-binding implementation guidance treats point (1) as residual — satisfied where the applicable point (2) requirements already cover the identified risks, demanding more where they do not.

The thirteen are more specific than a summary admits. Point (2)(b) requires "a secure by default configuration" and, in the same breath, "the possibility to reset the product to its original state" — two obligations, one a mechanism rather than a setting. Point (2)(c) requires automatic updates, where applicable, "enabled as a default setting, with a clear and easy-to-use opt-out mechanism". Point (2)(l) requires recording "the access to or modification of data, services or functions" — "with an opt-out mechanism for the user".

Click to zoom

The Risk Assessment Is the Gate, Not the Checklist

If the Article 13 assessment decides applicability, it is the load-bearing artefact; the checklist is downstream. Article 13(3) says what it must contain: "at least an analysis of cybersecurity risks based on the intended purpose and reasonably foreseeable use, as well as the conditions of use", naming "the operational environment or the assets to be protected", and "taking into account the length of time the product is expected to be in use".

Three of those inputs shape (a) to (m) for a platform component. Intended purpose is the yardstick (g) is measured against: it fixes what data, personal or other, the product processes, and what (m) must remove permanently — data and settings alike — rather than deciding whether either applies. Conditions of use settle whether an external interface exists, driving (j). Expected time in use feeds the support period, across which (c) must keep working.

The maintenance duty has a limit. Article 13(3) requires the assessment to be "documented and updated as appropriate during a support period" — as appropriate, not on a fixed cadence. Reading that as continuous rewriting invents work the Regulation does not ask for; a material change to product or threat picture is what makes the decisions stale.

Article 13(5) reaches past your own code. Manufacturers "shall exercise due diligence when integrating components sourced from third parties" — "including when integrating components of free and open-source software that have not been made available on the market in the course of a commercial activity". An upstream maintainer with no commercial nexus is outside the Regulation; the dependency they wrote is inside your product. That is the asymmetry the OSS supply-chain piece works through with SBOMs, Sigstore and SLSA — here a legal duty, not hygiene.

When a Platform Team Is the Manufacturer

The Commission's CRA summary states that products "not made available on the market, i.e. not supplied in the course of a commercial activity, are not subject to the CRA". For open source the test is monetisation: financial support from manufacturers "should not in itself determine that the activity is of commercial nature" (recital 18). Recital 15 names what does — charging for the product, or for technical support "where this does not serve only the recuperation of actual costs". Sustained support for someone else's product is instead the Article 24 steward branch, which recital 19 bars from the CE marking.

The classification question is separate, and more often wrong. Article 7(1) makes the trigger core functionality: products "which have the core functionality of a product category set out in Annex III shall be considered to be important products". Annex III Class II lists "[h]ypervisors and container runtime systems that support virtualised execution of operating systems and similar environments" — the line that produces the panic. Commission Implementing Regulation (EU) 2025/2392 of 28 November 2025 supplies the operative technical descriptions; its container runtime entry is narrow: software managing "the execution and lifecycle of containers running on a single host operating system as isolated processes". Applying that to containerd or CRI-O rather than a chart that installs one is interpretation, not text — but recital 5 backs the limit: a product able to perform a category's functions "but whose core functionality itself is different from that of such product category is not to be considered to meet the technical description".

Mapping (a) to (m) Onto What You Ship

Annex VII point 3 requires the technical documentation to carry the risk assessment "including how the essential cybersecurity requirements set out in Part I of Annex I are applicable". Nothing says it has to be prose. Put it in the repository as data, one record per requirement, and the decision becomes reviewable in a pull request and checkable by script.

The keys below use ENISA's identifiers from its Secure by Design and Default Playbook v1.0, published 30 July 2026, whose Annex C maps its 22 principles onto Annex I. ENISA labels that mapping "indicative", the identifiers are its notation rather than the Regulation's, and satisfying a playbook principle establishes nothing about conformity. The register format is Stribog's construction: the CRA defines no such artefact, and neither do CEN-CENELEC or ENISA.

# Illustrative format. Not defined by Regulation (EU) 2024/2847,
# by CEN-CENELEC or ENISA. Keys follow ENISA's Annex B notation;
# the .reset and .auto suffixes are this register's own.
product: platform-operator
support_period_end: "2031-11-30"   # Annex II point 7: an end-date
risk_assessment: cra/risk-assessment-2026-09.md

requirements:
  - id: ANNEX-1.PT1.2.a
    text: "no known exploitable vulnerabilities at release"
    applicable: true
    control: "Release blocks on any fixed-and-available CVE"
    evidence: evidence/a/trivy-release-scan.json

  - id: ANNEX-1.PT1.2.b
    text: "secure by default configuration"
    applicable: true
    control: "Shipped values.yaml; no default credential, admin API opt-in"
    evidence: evidence/b/values-defaults.yaml

  - id: ANNEX-1.PT1.2.b.reset
    text: "possibility to reset the product to its original state"
    applicable: true
    control: "helm upgrade --reset-values re-applies the shipped defaults;
      mutated config CRs replaced from the shipped manifests, install intact"
    evidence: evidence/b/reset-to-defaults-test.txt

  - id: ANNEX-1.PT1.2.c
    text: "vulnerabilities addressable through security updates"
    applicable: true
    control: "Signed releases on a public channel; version notification"
    evidence: evidence/c/cosign-verify.txt

  - id: ANNEX-1.PT1.2.c.auto
    text: "automatic security updates enabled as a default setting"
    applicable: false
    justification: >-
      Point (2)(c) conditions this limb on "where applicable". The chart is
      upgraded by the cluster's own administrator through Helm or GitOps; no
      manufacturer channel installs into a user's cluster, so no such default
      can exist. The mechanism above stays applicable.

  - id: ANNEX-1.PT1.2.g
    text: "data minimisation - data, personal or other"
    applicable: true
    control: "Namespace-scoped RBAC limited to the CRD contract; no
      Secret values in status or logs"
    evidence: evidence/g/rbac-role.yaml

  - id: ANNEX-1.PT1.2.j
    text: "limit attack surfaces, including external interfaces"
    applicable: true
    control: "Distroless base; no shell; single mTLS listener"
    evidence: evidence/j/exposed-ports.txt

  - id: ANNEX-1.PT1.2.m
    text: "permanent, secure removal of all data and settings"
    applicable: true
    control: "Documented uninstall wiping owned PVCs, CRs and CRDs"
    evidence: evidence/m/uninstall-wipe-test.txt

The (j) evidence path is a declared exposure list — what ENISA's playbook names as minimum evidence for attack-surface minimisation: "a maintained list of externally reachable interfaces (APIs, ports, protocols, admin interfaces, update channels) is stored in the repo or product documentation". Its illustrative example verifies that with a port audit gated against the declared list; a self-built distroless base image shortens the list rather than documenting it.

Two rows are keyed to a limb rather than a letter, because the Regulation conditions them that way. Point (2)(c) attaches its own "where applicable" to automatic updates specifically, so .c.auto is the row carrying an Article 13(4) justification — not a gap, but a discharged obligation. Point (2)(g) is no candidate for that treatment: it minimises "data, personal or other", and a controller reconciling API objects processes data whether or not any of it is personal.

Making the Register a Release Gate

A register nothing checks decays like a spreadsheet. The gate is deliberately dumb: applicable means a readable evidence file exists; not-applicable means a justification of at least a sentence; anything else is a defect. It checks drift between record and artefact, not whether the control is good.

#!/usr/bin/env bash
set -euo pipefail

REGISTER="${1:-cra/annex-i-part-1.yaml}"
fail=0
count=$(yq '.requirements | length' "$REGISTER")
for i in $(seq 0 $((count - 1))); do
  id=$(yq -r ".requirements[$i].id" "$REGISTER")
  applicable=$(yq -r ".requirements[$i].applicable" "$REGISTER")

  if [ "$applicable" = "true" ]; then
    path=$(yq -r ".requirements[$i].evidence // \"\"" "$REGISTER")
    if [ -z "$path" ] || [ ! -r "$path" ]; then
      echo "FAIL $id: applicable, but evidence missing: '${path}'"
      fail=1
    fi
  elif [ "$applicable" = "false" ]; then
    text=$(yq -r ".requirements[$i].justification // \"\"" "$REGISTER")
    if [ "${#text}" -lt 40 ]; then
      echo "FAIL $id: not applicable, but 13(4) justification absent or too short"
      fail=1
    fi
  else
    echo "FAIL $id: applicable must be true or false, got '${applicable}'"
    fail=1
  fi
done

exit "$fail"

The secure-by-default half of (2)(b) is where a values file earns its place: it is a claim about shipped defaults.

auth:
  # auth.existingSecret: absent on purpose. No default, none generated;
  # the template below requires it
  requireTLS: true
adminApi:
  enabled: false       # opt-in, not opt-out
audit:
  enabled: true        # (2)(l) default on
  optOut: "audit.enabled=false"
podSecurityContext:
  runAsNonRoot: true
  seccompProfile: { type: RuntimeDefault }
containerSecurityContext:
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true

# An unset auth.existingSecret is a hard stop, not a signal to generate
# a password. A values file cannot express that; this can.
env:
  - name: AUTH_SECRET_NAME
    value: {{ required "auth.existingSecret must name an existing Secret" .Values.auth.existingSecret | quote }}

One property makes the register re-checkable: record each evidence file's SHA-256 at the release that cited it, so an assessor re-derives the artefact rather than trusting the row.

Click to zoom

Conformity Assessment and the Open-Source Route

Article 32(1) lets an ordinary product demonstrate conformity through "the internal control procedure (based on module A)" — self-assessment, no notified body. Article 32(3) removes that option for Annex III Class II, leaving module B plus C, module H, or a certification scheme at assurance level "substantial". For Class I, module A survives only where harmonised standards, common specifications or such a scheme exist and are applied in full.

Which makes Article 32(5) worth reading in full: a door open to open-source products. Manufacturers of products "qualifying as free and open-source software, which fall under the categories set out in Annex III, shall be able to demonstrate conformity … by using one of the procedures referred to in paragraph 1" — the module A procedures — "provided that the technical documentation referred to in Article 31 is made available to the public at the time of the placing on the market". The Commission's July 2026 implementation guidance reads it the same way; it is expressly non-binding, and applies only once all language versions are adopted. None of this is legal advice; whether a product qualifies is a judgement taken with counsel.

That is why the register belongs in the repository. The price of the 32(5) route is publishing the Article 31 technical documentation — Annex VII entire, not the register alone. But point 3 of that annex is the applicability record, the part hardest to reconstruct afterwards. A register already public was written to be read; a private wiki gets sanitised under time pressure.

One asymmetry underlies all of it. Article 27(1) grants a presumption of conformity only to products conforming to harmonised standards "the references of which have been published in the Official Journal", and only for what those standards cover. Standardisation request M/606 covers 41 standards and prioritises the Annex III and IV categories, but the Commission's harmonised-standards index carried no Cyber Resilience Act entry when this was written. So Annex VII point 5 is operative today: absent applied harmonised standards, the documentation must carry "descriptions of the solutions adopted". Not a fallback — the route.

Where This Goes Wrong

• A stale assessment. Applicability decisions inherit the date of the assessment behind them. Ship a listener into a product whose assessment said it had no external interface, and the (j) entry describes something else. Tie the register to the assessment version.
• Justification by omission. A blank entry is not a decision that the requirement does not apply — it is an absent record. Article 13(4) asks for "a clear justification"; silent rows are what the gate exists to catch.
• Secure-by-default that ships a credential. A chart with a baked-in default password fails the plain reading of (2)(b), however loudly the README says to change it. Ship none; require one.
• An optimistic support period. Article 13(8) sets a floor: "the support period shall be at least five years", shortened only where the product "is expected to be in use for less than five years". Annex II point 7 then requires an end-date, not a statement that support exists.
• Assuming harmonised standards arrive in time. Article 71(2) applies the Regulation from 11 December 2027. Planning around a presumption-of-conformity route with no published reference is planning around someone else's calendar.

A sixth: assuming a simplified path exists because the Regulation mentions one. Article 33(5) does let microenterprises and small enterprises supply the Annex VII elements "by using a simplified format" — but the same paragraph says the Commission "shall, by means of implementing acts, specify" that form. Until that act exists, 33(5) is a future route, not a form anyone can file.

Exit Ramps: Keeping the Evidence Portable

The register is deliberately boring: plain YAML in the product repository, evidence as files beside it, a shell script as the gate. The Regulation names no format, harmonised standards will name one, and a compliance platform will name its own. Whichever wins, a flat key-to-decision-to-evidence mapping is a remap; a register inside a vendor's data model is an extraction project.

Three properties are worth protecting. Evidence should be produced by the build, not uploaded by a person, so regenerating it is a pipeline run. Identifiers should be stable and yours: when a harmonised standard arrives with its own numbering, that mapping is a column, not a migration. And the technical documentation should be assembled from the register, not kept beside it: two hand-maintained copies of one decision diverge.

Where artefacts sit follows the same logic. Evidence bound to a registry you operate, with replication and signature verification, survives a change of CI vendor. Evidence living only in a hosted pipeline's store does not.

The Long Game: Five Years Is an Architectural Constraint

Article 13(8)'s five-year floor reads as a legal footnote and behaves as a design input: it fixes how long (2)(c)'s update mechanism has to keep working, which constrains what you can depend on. A dependency with an eighteen-month upstream support window is one you have promised to maintain yourself for three and a half more years — better decided at selection than discovered in year two. Five years of a signed update channel is infrastructure, not a release page.

This is the posture the CISA Secure by Design pledge asks for voluntarily, arriving here as a Regulation with dates on it. Teams that find December 2027 uneventful will be those treating Part I as thirteen engineering questions with recorded answers, asked once per release by a script.