The CRA's essential requirements describe a product. Several of them can only be true if the environment that produced that product was itself intact — and the regulation asks you to document those production processes and their validation. This is a walk through which requirements reach that far, what each actually asks for, and, for each, how far host attestation reaches and where it stops.
Not legal advice. Requirement text below is paraphrased, not quoted, and article and annex references point at Regulation (EU) 2024/2847 for you to read yourself. Whether the CRA applies to your product, which class it falls into, and what conformity route follows are questions for your own counsel — not questions any tool answers.
The Cyber Resilience Act binds manufacturers who make a product with digital elements available on the EU market. That phrase is broader than most first readings of it: it is not limited to consumer devices, not limited to things with a screen, and not limited to software sold as a licence. If you place it on the EU market and it has digital elements, you are likely in scope.
The free-and-open-source carve-out is narrower than it is often reported to be. It reaches software that is open source and not monetised. Free of charge is not by itself sufficient, and neither is a permissive licence on part of the codebase. Most commercial arrangements around otherwise-open software fall outside the carve-out.
The obligations do not all land at once. Four dates matter:
| 2024-12-10 | The regulation entered into force. Nothing was required of anyone yet. |
| 2026-06-11 | Conformity-assessment bodies notified — relevant only if your product's class requires third-party assessment rather than self-assessment. |
| 2026-09-11 | Article 14 reporting obligations begin. Actively exploited vulnerabilities and severe incidents, reported to ENISA and your coordinating CSIRT on 24-hour and 72-hour clocks. This is the first hard deadline, and it is weeks away. |
| 2027-12-11 | Everything else: the essential requirements, CE marking, the EU Declaration of Conformity, and the technical documentation. |
Nowhere. This section is about legal scope, and legal scope is not a technical property of anything.
Whether the CRA applies to you, which class your product falls in, and which conformity route follows. Those are determinations you make and record, with the reasoning, in your technical documentation.
Annex I Part I lists the essential cybersecurity requirements — thirteen of them, lettered (a) through (m). They read as properties of the thing you ship: no known exploitable vulnerabilities at the time of release, a secure-by-default configuration, protection of confidentiality and integrity, a minimised attack surface, the ability to record and monitor relevant internal activity, secure deletion of data at end of life.
Almost all of these are satisfied by design decisions inside your codebase, and the evidence for them is architectural. But look closely at (a). Shipping with no known exploitable vulnerabilities is a claim about the artifact you actually released — not about the source you reviewed, and not about the build you intended. Those are the same thing only if the machine in between behaved.
This is the seam that most CRA readings step over. The requirements describe the product; the product is whatever came out of the build. If a build host was compromised and injected something into the output, requirement (a) is false about your release, your review process never had a chance to catch it, and — this is the part that matters for the rest of the article — nothing in your documentation would say so. You would hold an accurate description of a process that did not happen.
The state of the build host itself: which executables ran and which files were read, measured by the kernel into a TPM register the host cannot rewind, with the judgement made on a separate machine. That is evidence about the machine in between.
Whether your source is what you think it is, whether your code is correct, whether your review caught anything, or whether a dependency you deliberately included carries a vulnerability. Attestation reports what a host ran. It has no opinion on whether that was a good idea.
Annex I Part II covers vulnerability handling — eight requirements. They ask you to identify and document the components in your product in a machine-readable software bill of materials covering at least the top-level dependencies; to remediate vulnerabilities without delay; to test and review regularly; to disclose fixed vulnerabilities publicly; to run a coordinated disclosure policy with a published contact address; and to distribute updates securely and without delay.
An SBOM is generated, not observed. Some tool in your pipeline walks a dependency graph and writes down what it found. That document is a faithful record of what the build believed it was using — which is the same as what the build actually used, provided the environment doing the believing was intact. There is nothing inside the SBOM format that establishes this. A CycloneDX document produced on a compromised host is well-formed, complete, machine-readable, and wrong, and it will pass every validator you point at it.
The same structure applies to Part II's secure-distribution requirement. Signing an artifact proves the signature was made with your key. It does not say anything about the state of the host that held the key at the moment it signed — and a signature applied by a compromised release host is a valid signature over the wrong bytes. The cryptography works perfectly; it is simply answering a narrower question than people read it as answering.
Whether the host that generated the SBOM, and the host that held the signing key, matched their approved state at the time they did it — evidenced by hardware the host cannot forge and recorded off the host.
SBOM completeness, format quality, or metadata fields; VEX statements; whether a listed component has a known vulnerability; your remediation timelines; your disclosure policy. All of Part II except the state of the machines is untouched by this.
Annex VII sets out the technical documentation: eight items, to be drawn up before the product is placed on the market and retained for ten years afterwards, or for the support period, whichever is longer. Item 1 is the general description. Item 2(a) is design and architecture. Item 2(b) is the vulnerability-handling process. Item 3 is the Article 13 risk assessment. Item 6 is test reports. Item 8 is the SBOM, on reasoned request from market surveillance.
Item 2(c) is the one worth sitting with: production and monitoring processes, and their validation. Most organisations satisfy the first half comfortably. You have a pipeline, it is defined in a file, you can print that file and put it in the dossier. That is a description of how the process is supposed to work.
Validation is the other half, and it asks a different question: what shows that it worked that way? Not what the pipeline is configured to do, but what happened on the runs that produced the releases you are declaring conformity for. A build log answers this only if you trust the host that wrote the log — which is the host under discussion. An auditor is entitled to notice the circularity.
There is a related item worth flagging while you are in Annex VII. Item 5 asks which harmonised standards you applied and, where none are available, which solutions you adopted to meet the essential requirements. At the time of writing there are no CRA harmonised standards published. Conformity therefore has to be argued directly against Annex I, in your own words, with your own evidence. That raises the value of evidence that was produced independently of the thing it describes.
Per-run, signed, dated evidence that a named build host matched its approved state — held on a separate machine, so the record does not depend on the honesty of the host it describes. That is the literal shape of "validation" as distinct from "description".
The design of your pipeline, access control to your version control, the correctness of your CI configuration, your test coverage, or any of the other seven Annex VII items. It contributes evidence to one half of one item.
From 11 September 2026, two triggers oblige a manufacturer to report: an actively exploited vulnerability contained in the product, and a severe incident having an impact on the security of the product. Either one starts the same clocks — an early warning within 24 hours, a fuller notification within 72 hours, and a final report later (14 days after a corrective measure is available for an exploited vulnerability; one month after the notification for a severe incident). Separately, you must inform affected users, along with any corrective measures they can take.
Read the definition of a severe incident carefully. It covers an incident that negatively affects, or can negatively affect, the product's ability to protect the availability, authenticity, integrity or confidentiality of important data or functions — or that has led, or can lead, to the introduction or execution of malicious code in the product or in a user's systems.
A compromised build host sits squarely inside that second limb. It is an incident that can lead to the introduction of malicious code into the product, and through the product into users' systems. That is a 24-hour clock.
The clock starts when a responsible person has enough information to reasonably conclude a trigger is met — not when the investigation finishes. So the operative question is not whether you would report; it is whether you would know, and when. And by 72 hours the notification wants scope: which releases, over what period, in what state. Reconstructing that after the fact from logs written by the host in question is exactly the position the reporting duty is least forgiving of.
A dated, signed history, kept off the host, of when each build and signing host was last in its approved state and when that stopped being true. A scope statement is assembled out of exactly that: the boundary between the runs you can still stand behind and the ones you cannot.
Whether your product is being exploited in the field; whether a trigger is legally met, which is a judgement call for a named person; who your coordinating CSIRT is; and the reporting itself. None of that is automatable, and no evidence trail substitutes for having named the person who owns the clock.
Set against the whole regulation, the fit is narrow and specific. Etminan produces continuous evidence about the state of particular Linux hosts: the kernel's IMA subsystem measures executables and files into a TPM register that only extends and never rewinds, the host returns a hardware-signed quote over that register together with the measurement log, and a separate verifier replays the log, recomputes the register, and compares. The host reports; it never judges. Where your build and signing estate is Linux with a TPM, that turns "we document our build process" into "we hold signed, per-run evidence that this host matched its approved state, kept somewhere the host cannot reach."
That evidence is relevant to one half of Annex VII item 2(c), supports the honesty of the artifact claim behind Annex I Part I(a), says something about the conditions under which your SBOM and your signatures were produced, and gives an Article 14 scope statement something to be built from. Four narrow contributions. The core attestation loop and its hash-chained audit log are in the Standard edition, which is free of charge — though, worth noting given the carve-out discussed above, deliberately not open source. SIEM export, RBAC, dual control and air-gapped operation are Enterprise capabilities.
Everything else on the CRA's list is yours and stays yours. Etminan does not produce your SBOM, write your technical documentation, classify your product, assess your risk, run your disclosure process, or file your reports. It does not watch your source repository, review your code, or have any view on your dependencies. It is not a compliance product and treating it as one would be a category error: it is an evidence source that a small number of CRA obligations happen to be short of.
And the mechanism has its own boundary, which is worth stating in the same breath — the more so because most build estates are virtualised. A vTPM is a first-class TPM here: the same device node, the same PCR, the same quote. What changes between deployment classes is not whether attestation works, but how far down the stack the proof reaches. On a VM with a vTPM on a hypervisor you own, a quote proves the guest was not tampered with from the inside, including by guest root — and your trust perimeter is unchanged, because the hypervisor is already yours to administer. What the guest's quote does not prove is that the TPM is silicon; a compromised hypervisor could emulate one.
That is an argument for attesting the hypervisor, not for treating it as a hole. A hypervisor is a Linux host in its own right — Proxmox VE is Debian — with a physical TPM of its own, so it runs an agent and is attested like any other machine in the estate, and being bare metal it can additionally be enrolled against a manufacturer EK-certificate root, which a vTPM by definition cannot offer. The guest's evidence does not need to reach downwards, because the hypervisor produces its own. Public cloud is the genuinely different case: there the hypervisor is not yours to attest, and that belongs in your risk assessment as a named dependency rather than an assumption.
Physical attacks and compromise below the TPM boundary — firmware, UEFI, the SPI bus — stay out of scope on every host, hypervisor included. And silence from an agent means "fine, or already flagged unreachable" — never "definitely fine." Any evidence trail you put in front of an auditor should come with those limits attached, because they will hold up better stated than discovered.
One last thing, in the interest of not writing from outside the problem: the CRA applies to Etminan too. It is a product with digital elements placed on the EU market, and Standard being free of charge does not exempt it, precisely because the carve-out requires open source as well as non-monetisation. The dossier, the risk assessment, the Annex VII index and the Article 14 runbook are work we are doing on ourselves, against the same deadlines, with the same open items. That is the position this article is written from.
If the evidence question is the one you care about, the architecture pages describe how the measurement, the quote and the off-host replay actually work — including the threat model and what it explicitly does not cover.
etminan