CRA Signed SBOMs: Why the eSeal Is the Emerging Trust Anchor

The EU Cyber Resilience Act makes SBOMs mandatory for every product with digital elements from 11 December 2027; vulnerability reporting starts 11 September 2026. The CRA does not prescribe a signature method — but the qualified electronic seal (eSeal) under eIDAS 2 is emerging as the trust anchor that binds an SBOM to its manufacturer, cross-border and legally.

As of April 2026, zero Conformity Assessment Bodies have been designated for the Cyber Resilience Act (CRA Evidence — conformity assessment decision guide). The rules for designating them apply from 11 June 2026, and the first notified bodies are expected to be operational by 11 December 2026. Manufacturers of Important Class II and Critical products — network-security appliances, industrial controllers, password managers, identity management systems — cannot complete third-party conformity assessment today because there is nobody to assess them. And the vulnerability-reporting clock starts on 11 September 2026, five months from the date of this post. The infrastructure that every in-scope manufacturer needs to have in production by September — a machine-readable SBOM, a tamper-resistant signature, a legal declaration of conformity, and a 24-hour incident-reporting channel to ENISA — is the infrastructure that most manufacturers have not yet built.

What the CRA Actually Requires About Signatures

Regulation (EU) 2024/2847 — the Cyber Resilience Act — entered into force on 10 December 2024 (Cyber Resilience Act — EU digital strategy). Its text is explicit about three signature-adjacent requirements and silent about a fourth.

What is explicit:

• Article 28 — EU Declaration of Conformity, following the model structure in Annex V, must be drawn up and signed by the manufacturer before CE marking and market placement (CRA Article 28 text).
• Annex I essential requirements mandate a "Software Bill of Materials (SBOM) in a commonly used and machine-readable format" covering at least top-level dependencies.
• 10-year retention for security documentation including the SBOM, technical documentation, and vulnerability-handling records.

What is silent: the CRA does not specify the cryptographic format of the signature on the Declaration of Conformity, nor whether the SBOM itself must be signed, nor whether the signature must be recognised under eIDAS. That silence is not an oversight — the CRA is the product-regulation layer, not the trust-services layer. The manufacturer picks the signature format. The regulator picks which formats it will accept as evidence.

The Two Layers of Supply-Chain Attestation

The 2026 reality is that signed SBOMs have two distinct audiences with two different trust requirements. A developer-layer attestation answers "this build came from this source"; a legal-layer attestation answers "this organisation stands behind this artefact". Both are needed. Neither subsumes the other.

Developer layer — Sigstore, SLSA, in-toto

The open-source supply-chain stack has matured rapidly since 2022. Sigstore provides keyless signing via short-lived certificates bound to OIDC identity, with a public transparency log (Rekor) recording every signature (Sigstore — in-toto attestations). SLSA (Supply-chain Levels for Software Artifacts) defines build-integrity requirements, with Level 2 requiring signed, tamper-resistant provenance and Levels 3 and 4 adding verified source control and hermetic builds (SLSA and in-toto). in-toto provides the attestation framework for expressing and verifying supply-chain claims as structured, signed metadata.

This stack answers real questions. Was this binary built from the source I think it was? Was the build environment compromised? Did the expected steps run in the expected order? SLSA Level 3 + Sigstore + in-toto is a genuinely strong developer-provenance answer, widely adopted across the cloud-native ecosystem.

What it does not answer: which legal entity takes responsibility for this attestation? Sigstore's identity binding is to an OIDC issuer (typically GitHub, Google, a workload identity provider) — not to a legally-identifiable organisation. A transparency-log entry is not an EU Declaration of Conformity.

Legal layer — qualified electronic seal under eIDAS 2

Under Regulation (EU) 2024/1183 — the revised eIDAS — a qualified electronic seal is the organisation-level cryptographic counterpart to a qualified electronic signature (QES, which binds a natural person). An eSeal binds data to a legal entity via a qualified certificate issued by a Qualified Trust Service Provider (DigiCert — What is an electronic seal). Inside the EU, a qualified eSeal carries a legal presumption of integrity and of correct origin. Outside the EU, it remains the format EU regulators expect to see when a foreign manufacturer places a product with digital elements on the EU market and signs a Declaration of Conformity.

The two layers compose. A machine-readable SBOM + SLSA provenance + Sigstore signature answers the developer-trust question. A qualified eSeal over the SBOM bundle and the Declaration of Conformity answers the legal-trust question. Neither alone is sufficient for an audit-defensible 2027 position.

Why the eSeal Is Emerging Without Being Mandated

Three pressures push manufacturers toward qualified eSeals even though the CRA does not name them.

First, cross-border recognition. A US or UK software vendor selling into the EU needs a signature format that every national market-surveillance authority in 27 Member States will accept without debate. Qualified eSeal certificates issued by an EU Qualified Trust Service Provider are explicitly recognised under Article 35(2) of eIDAS across all Member States. A Sigstore-signed attestation referencing a GitHub OIDC identity is not. For the non-EU manufacturer, the eSeal is the lowest-friction legal signature for a product entering the single market.

Second, convergence with NIS2 and DORA. The same manufacturer producing a product with digital elements for an EU bank is often also a third-party under DORA's Register of Information and a supplier under NIS2 Article 21(2)(d). Each of those regimes increasingly expects cryptographic evidence that survives supervisory walk-back. A common legal-layer attestation format — the qualified eSeal — reduces the compliance surface across all three.

Third, NIS2 Article 21(2)(h) cryptography audit expectations. Essential entities now face Article 21 evidence requirements for their own cryptography policies. When the entity is consuming signed SBOMs from suppliers, the question "is the signature from a recognised EU trust service?" becomes part of the audit trail. eSeal answers yes by default.

What Needs to Be in Production by 11 September 2026

The September 2026 deadline is for vulnerability and severe-incident reporting — not full CRA conformity. But the infrastructure a manufacturer needs to meet the 24-hour ENISA reporting window is the same infrastructure that will later serve the full 2027 conformity regime. A minimum stack by September:

• A machine-readable SBOM for every product version shipped, stored in a retrievable location with version history.
• A developer-layer signature over each SBOM (Sigstore cosign or equivalent), with transparency-log entries.
• A legal-layer attestation — ideally a qualified eSeal — over the SBOM bundle and the Declaration of Conformity draft.
• A vulnerability-handling process that can produce a signed incident notification within 24 hours of becoming aware of an actively exploited vulnerability.
• A 10-year archival plan for the above.

Of these five, the fourth (24-hour incident notification) is the binding constraint in September 2026. The remaining four are the infrastructure the incident notification depends on.

What Needs to Be in Production by 11 December 2027

By the full-compliance date, the above stack must be complete enough to pass conformity assessment. For non-critical products that is a manufacturer self-declaration (Module A). For Important Class II and Critical products it is a third-party notified-body assessment — which brings us back to the zero-notified-bodies reality of April 2026. Manufacturers of affected products should not wait for NB designations to start their technical documentation. The documentation that a notified body will eventually read is the documentation that supports the 11 September 2026 incident-reporting obligation, plus product-category-specific additions drawn from Annex I.

The cryptographic decisions made now will be read by auditors for a decade. Post-quantum transition under the EU Coordinated Implementation Roadmap runs on the same 2030-2035 timeline as long-lived CRA technical documentation. Manufacturers choosing their SBOM signing stack in 2026 should choose one that will survive that transition.

Practical Recommendations for In-Scope Manufacturers

• Do not wait for notified-body designations. The September 2026 reporting deadline applies regardless of conformity-assessment capacity. Start the documentation now.
• Build the two-layer stack, not one. Developer-layer provenance (Sigstore/SLSA/in-toto) is not a substitute for legal-layer attestation (qualified eSeal). Plan for both.
• Pick an EU-based Qualified Trust Service Provider for eSeal issuance. Cross-border legal recognition under eIDAS 2 is the whole point of the qualified tier.
• Design for crypto-agility. The PQC transition overlaps with CRA long-term retention. Your 2026 eSeal certificate chain will need to be re-signed or re-timestamped with post-quantum algorithms before 2035.
• Align with NIS2 and DORA cryptography expectations. A single eSeal approach that satisfies CRA, NIS2(h), and DORA third-party evidence requirements is substantially cheaper than three separate approaches.

The CRA does not mandate the eSeal. It also does not mandate Sigstore. What it mandates is a machine-readable SBOM, a signed Declaration of Conformity, a 10-year evidence trail, and a 24-hour incident-reporting capability. The legal format that makes all four of those reconstructable for an EU regulator, in any Member State, a decade from now, is the qualified eSeal. That is why, without being named in the text of the regulation, it is the trust anchor that is emerging under it.

Sources

CRA regulation and timeline

• Cyber Resilience Act — European Commission digital strategy
• CRA implementation — European Commission
• CRA Article 28 — EU Declaration of Conformity
• CRA conformity assessment — European Commission
• CRA Evidence — conformity assessment decision guide (2026)

SBOM under CRA

• OPSWAT — CRA roadmap to software supply chain and SBOM compliance
• FOSSA — SBOM requirements in the EU CRA
• SafeDep — SBOM and the EU Cyber Resilience Act
• DigiCert — Why signed SBOMs are essential

Developer-layer attestation

• Sigstore — in-toto attestations documentation
• SLSA and in-toto — SLSA.dev
• OpenSSF — Sigstore

eSeal under eIDAS 2

• DigiCert — What is an Electronic Seal (eSeal)
• Regulation (EU) 2024/1183 on eIDAS 2 — EUR-Lex

About the author

Mairi Kutberg is co-founder of IdentiGate, where she runs operations and content. She works at the intersection of EU regulation (eIDAS, NIS2, AMLR, eFTI), cross-border digital identity, and the practical compliance angles of advanced electronic signatures.