CRA information to the user

Regulation (EU) 2024/2847, the Cyber Resilience Act (CRA), has each product with digital elements “accompanied by the information and instructions to the user set out in Annex II, in paper or electronic form” (Art 13(18)). This page gives that information for FerroFED, point by point in the order of Annex II. Each point quotes what Annex II asks and answers it, or links the page that does.

The product is each tagged FerroFED release, in the forms on Forms placed on the market. Points 1 and 2, and the first half of point 7, are the same for every FerroHEALTH product, and the family book is their source (The information that accompanies each release). The Annex II checklist of this book is a different list: the essential requirements of Annex II of Regulation (EU) 2025/327, the EHDS Regulation.

Every quotation is from the Official Journal text, vendored at docs/specs/eu-cra/reg-eu-2024-2847-en.xhtml (http://data.europa.eu/eli/reg/2024/2847/oj). No conformity assessment has been carried out and no EU declaration of conformity exists. This page gives the information Annex II lists; it does not say that FerroFED, or a deployment of it, meets the Regulation.

Which copy to read

The information for a release is this page at that release’s tag, from FerroFED 0.0.11 on. Art 13(18) has information provided online kept “available online for at least 10 years after the product with digital elements has been placed on the market or for the support period, whichever is longer”. A v* tag cannot be moved or deleted, so the page’s source at each tag stays as it was (Keeping it for ten years). The page is written in English; a market surveillance authority that needs a translation asks the single point of contact of point 2.

1. The manufacturer

“the name, registered trade name or registered trademark of the manufacturer, and the postal address, the email address or other digital contact as well as, where available, the website at which the manufacturer can be contacted;”

Cadasto B.V. The details are on the family book’s The manufacturer page, and the information sheet repeats them. The running gateway names them in GET {base}/, OPTIONS {base}/, its startup banner and ferrofed --version.

2. The single point of contact for vulnerabilities

“the single point of contact where information about vulnerabilities of the product with digital elements can be reported and received, and where the manufacturer’s policy on coordinated vulnerability disclosure can be found;”

The policy and the routes are on the family book’s Security page. A vulnerability in FerroFED is reported through GitHub private vulnerability reporting, as SECURITY.md says, and the advisories are published on the repository’s security advisories.

3. Identification

“name and type and any additional information enabling the unique identification of the product with digital elements;”

• Name: FerroFED.
• Type: software, a federation gateway for openEHR clinical data repositories, run as a server process.
• Unique identification: the version, X.Y.Z, with the signed tag vX.Y.Z. ferrofed --version, the startup banner and GET {base}/ name the version a gateway runs. An image is identified by its digest, and a tarball by its .sha256sum and its attestations ((b) Name, version and date of release).

4. Intended purpose, security environment and properties

“the intended purpose of the product with digital elements, including the security environment provided by the manufacturer, as well as the product’s essential functionalities and information about the security properties;”

• Intended purpose: Intended purpose.
• Essential functionalities: the federated query, follow-up routing and definitions (How it works).
• The security environment: the reverse proxy, the issuers, the identity services and the Audit Record Repository a deployment supplies (What FerroFED runs beside), and the trust relationships between them (Trust and keys).
• Security properties: every caller is authenticated; no directly identifying patient identifier reaches a node (§5.4, N33, Where the patient identifier stops); each node is told who asks and decides for itself; every access to patient data is recorded. The threat model names each property with the test that holds it, and the cybersecurity risk assessment reads them against Annex I.

5. Circumstances that may lead to significant cybersecurity risks

“any known or foreseeable circumstance, related to the use of the product with digital elements in accordance with its intended purpose or under conditions of reasonably foreseeable misuse, which may lead to significant cybersecurity risks;”

The full list, each with its control, is the threat model’s Risks the deployment carries. The circumstances that lead to the most severe ones:

• running profile = "development" near real data (Hardening);
• leaving the hop between the proxy and the gateway in cleartext on a shared network (TLS on the listeners);
• trusting an issuer or an identity service that is compromised, or a member that ignores the caller the gateway conveys (Admitting a node);
• keeping the audit spool on an unencrypted volume (The audit spool);
• running a release that is not the newest, which receives no fix (point 7).

6. The EU declaration of conformity

“where applicable, the internet address at which the EU declaration of conformity can be accessed;”

None has been issued. Once the manufacturer issues one, it is attached to each release it covers at https://github.com/FerroHEALTH/FerroFED/releases/download/vX.Y.Z/ferrofed-vX.Y.Z-eu-declaration-of-conformity.md (The EU declaration of conformity).

7. Technical security support and the support period

“the type of technical security support offered by the manufacturer and the end-date of the support period during which users can expect vulnerabilities to be handled and to receive security updates;”

The type of support is the manufacturer’s, described on the family book’s How a fix reaches you. Only the newest release of FerroFED is supported. When a new release is published, every earlier release stops receiving fixes: there are no maintenance branches, no long-term-support line and no backports. A security fix ships in a new release, a patch release with no feature changes in it, and a user of an older release upgrades to the newest release, free of charge, to get the fix (SECURITY.md).

Cadasto B.V. keeps publishing security fixes, in new releases, for at least five years after each release (Art 13(8)), and ships them only in the newest release (Art 13(10)). The end date of each release is the date until which that commitment runs; the release itself is supported only while it is the newest. The end dates, as SECURITY.md lists them:

SECURITY.md is the record. The release cut adds each new row to it and copies the row here, and a guard, scripts/checks/support-periods.sh, fails every change and every release while the two tables differ. A gateway names its own end date in the startup banner and in OPTIONS {base}/, and says so once the date has passed.

8. Instructions

“detailed instructions or an internet address referring to such detailed instructions and information on:”

8(a) Secure use from commissioning on

“the necessary measures during initial commissioning and throughout the lifetime of the product with digital elements to ensure its secure use;”

Commission a deployment with A production deployment and check it against the Hardening checklist. The instructions for use give the order of the steps, and their maintenance table lists what keeps it secure through its lifetime: upgrades, config check, key rotation, certificate renewal and the alerts.

8(b) How changes affect the security of data

“how changes to the product with digital elements can affect the security of data;”

• Configuration. The configuration decides whom the gateway trusts and where it sends data. The development profile admits a static cross-reference and cleartext credentials; an issuer added to [auth] is trusted for every caller it vouches for; a member added to the registry receives queries once admitted. Run ferrofed config check before every start, reload and upgrade (Configuration, Admitting a node).
• Upgrades. A release’s upgrade notes list every key that became mandatory or a value now refused (Upgrading).
• Stored queries. A stored query an operator publishes runs against every member it reaches (Stored queries).
• Changes to the source. A binary or image built from modified source is not a Cadasto B.V. release: its provenance does not verify, and the cybersecurity risk assessment does not describe it.

8(c) Installing security updates

“how security-relevant updates can be installed;”

Hear of a release from the release feed, https://github.com/FerroHEALTH/FerroFED/releases.atom, and of a vulnerability from the repository’s security advisories (Hearing of an update). Verify the release with gh attestation verify (Kubernetes, The release binaries), then follow Upgrading; Rollback says how to go back.

8(d) Secure decommissioning

“the secure decommissioning of the product with digital elements, including information on how user data can be securely removed;”

Decommissioning takes a deployment out of service step by step: it lists what a deployment holds and where, moves what a replacement needs, lets the audit spools deliver, stops the replicas, keeps the access records for their retention period, retires the signing keys and the credentials, and removes the stores and the volumes.

8(e) Turning off automatic security updates

“how the default setting enabling the automatic installation of security updates, as required by Part I, point (2)(c), of Annex I, can be turned off;”

FerroFED installs no update by itself, so there is no such setting; the risk assessment says why (Automatic security updates).

8(f) Information for an integrator

“where the product with digital elements is intended for integration into other products with digital elements, the information necessary for the integrator to comply with the essential cybersecurity requirements set out in Annex I and the documentation requirements set out in Annex VII.”

This point does not apply: FerroFED is not intended for integration into another product, and its library crates reach a user only inside the release forms. Client applications connect to a running gateway over ITS-REST (The client contract).

9. The software bill of materials

“If the manufacturer decides to make available the software bill of materials to the user, information on where the software bill of materials can be accessed.”

Cadasto B.V. makes them available. Each release tarball on the releases page comes with a CycloneDX SBOM of the source graph (.cdx.json) and an SPDX SBOM of the shipped binary (.spdx.json), each attested (The release binaries). The gateway and console images carry an SPDX SBOM per platform as an attestation in the registry, which gh attestation verify reads (Kubernetes).