Reading in standalone mode. Open this treatise in the complete 2-Column Sovereign Research Wiki Engine:Open Wiki Dashboard (117 Treatises) →
BIDDING MARKETPLACEProduct Assurance and Conformance

The Conformity Assessment Bidding Marketplace and VEX Falsification Protocol

100% Complete & Untruncated 10 min read
Return to Research Tracks

J. McKenney

This is the fourth of six papers on the Transparent Product Assurance Network, registered in Eigenia working group WG-06-SC, Product Assurance and Conformance, under the identifiers WG-10-AN-01 to WG-10-AN-06. It covers the testing itself: who does it, how the work is awarded, and what counts as having proved a security claim. The first paper gives the economic charter, the second the data contract in which a product is described, the third the statutory index a product is tested against. The fifth gives the interface through which a buyer queries the result, and the sixth follows five supply chain cases from manufacturer to operator.

Licence: CC BY 4.0. 11 September 2026.

Executive Abstract#

Assurance that rests only on a manufacturer's word about its own product is not assurance. The usual alternative, independent certification, has its own troubles: unpublished prices, queues of unpredictable length, and technical files that arrive in whatever shape the manufacturer kept them. This paper addresses both the commercial and the technical half.

The commercial half is a clearinghouse. A manufacturer posts a tender naming the regulatory scopes it needs; the network broadcasts it only to laboratories whose accreditation covers those domains, checked against the official registers. Those laboratories bid a fixed fee, a location, and a completion date; the manufacturer picks one and deposits the fee into escrow, guarding the laboratory against non-payment and itself against unexplained delay. Five states, each with a defined entry and exit, are all there is to it. Because the law now decides which products need which examination, the marketplace carries three routes: the design and prototype with the vulnerability-handling process; each production unit bound to the examined prototype by firmware fingerprint; and the development process certified whole.

The technical half concerns a common dishonesty. When a defect appears in a widely used library, a manufacturer may declare its product unaffected because the faulty code cannot be reached, a machine-readable claim treated as authoritative and rarely checked. The protocol makes it testable. The laboratory traces whether any path runs through the compiled firmware, from a network port or fieldbus frame, to the faulty code, hands a feasible path to an automated solver, and feeds a satisfying input to a physical sample; a device that misbehaves has falsified the claim, one with no reachable path has verified it. Physical claims are treated alike, pressure proven hydrostatically and fail-safe travel confirmed with power and air cut at full flow. What survives is signed with a hardware-held key, written to a public transparency log, and indexed so a buyer sees it at once.

Abstract#

Credible supply chain assurance needs independent testing; qualification left to manufacturer self-attestation degenerates into an unverified paper exercise. Yet third-party certification carries commercial opacity and unpredictable SLAs. This treatise defines the Conformity Assessment Bidding Marketplace and the Vulnerability Exploitability eXchange (VEX) Falsification Protocol within the Product Assurance Network (PAN). Accredited Conformity Assessment Bodies (such as Bureau Veritas, TUV Rheinland, TUV SUD, DNV, DEKRA, and UL Solutions) bid on manufacturer tenders through a defined state machine. We specify the Cyber Resilience Act procedures (Modules B, C, and H under Regulation (EU) 2024/2847) and a protocol that uses binary symbolic execution and hardware-in-the-loop stress testing to validate or falsify vendor security claims.

1. The Decentralized Qualification Bidding Protocol#

To prevent monopolistic pricing and minimize testing latency, PAN structures testing services as a transparent two-sided clearinghouse.

ARCHITECTURAL MAP← Swipe horizontally to inspect →
rendering diagram

1.1 The Tender Lifecycle State Machine#

A qualification tender progresses through five deterministic states:

  1. TENDER_DRAFT: The manufacturer packages the product's Schema G_CPDT model (DEXPI 2.0 XML, CycloneDX 1.6+ JSON under ECMA-424, and IEC 61970 CIM), selects target regulatory scopes (e.g., EU CRA Important Class II, RED Delegated Regulation 2022/30, IEC 62443-4-2 SL-2), and specifies testing delivery constraints.
  2. BIDDING_OPEN: The PAN Bidding Engine broadcasts the tender to accredited CABs whose scope of accreditation (verified via the European Commission NANDO database or IECEE CB Scheme) covers the requested technical domains. CABs submit sealed cryptographic bids detailing fixed testing fees, laboratory locations, and guaranteed completion timelines.
  3. ESCROW_LOCKED: The manufacturer evaluates bids based on cost, turnaround time, and CAB reputation score. Upon bid selection, the manufacturer deposits the testing fee into a neutral financial escrow. This guarantees payment to the laboratory upon milestone completion while protecting the manufacturer against unexplained project delays.
  4. AUDIT_ACTIVE: The selected CAB receives the complete digital twin file, cryptographic hashes, and physical equipment samples. The laboratory executes formal technical file reviews and empirical testing.
  5. SETTLED_QUALIFIED or SETTLED_REJECTED: Upon test completion, the CAB uploads a verifiable test report and signed in-toto attestation. The escrow contract releases payment to the CAB, and the PAN Registry publishes the qualification status to global buyers.

2. Conformity Assessment Procedures under the Cyber Resilience Act#

For products falling under the scope of Regulation (EU) 2024/2847 (CRA), the marketplace coordinates the formal conformity assessment routes specified in Article 24 and Annex VIII [1].

ARCHITECTURAL MAP← Swipe horizontally to inspect →
rendering diagram

2.1 Module B: EU-Type Examination by Notified Body#

Under Module B, the accredited CAB examines the technical design and development of the product with digital elements along with the manufacturer's vulnerability handling processes [2].

The CAB inspection team conducts three mandatory reviews:

  • Technical Documentation Audit: Verification that the software architecture, hardware bill of materials, and network interfaces satisfy the essential requirements of Annex I, Part I.
  • Vulnerability Handling Process Audit: Verification that the manufacturer maintains a functioning Coordinated Vulnerability Disclosure (CVD) program, automated internal triage systems, and capability to issue security patches within the 24-hour notification window mandated by Article 14.
  • Representative Type Testing: Direct physical and cyber examination of a sample unit representing the production run.

2.2 Module C#

Conformity to Type Based on Internal Production Control

Module C accompanies Module B. While Module B validates the engineering prototype ("the type"), Module C obligates the manufacturer to ensure that every manufactured physical unit conforms to the certified type. The PAN platform verifies Module C by cross-referencing factory firmware hash logs with the Module B certified binary digests.

2.3 Module H: Comprehensive Full Quality Assurance#

For large OEMs producing continuous product variants, Module H allows conformity assessment based on an audited quality management system. The CAB audits the manufacturer's entire secure development lifecycle (SDL) against standards such as IEC 62443-4-1. Once certified under Module H, the manufacturer can qualify individual derivative models without triggering individual Module B prototype examinations.

3. The Empirical VEX Falsification Protocol#

A critical vulnerability of modern software security is the prevalence of unverified Vulnerability Exploitability eXchange (VEX) statements. When a Common Vulnerability and Exposure (CVE) is discovered in an open-source library, manufacturers frequently mark the component as not_affected using the justification code_not_reachable without providing empirical proof [3].

The PAN VEX Falsification Protocol converts subjective vendor claims into falsifiable empirical tests.

ARCHITECTURAL MAP← Swipe horizontally to inspect →
rendering diagram

3.1 Mathematical Formulation of Reachability Falsification#

Let the firmware binary of the asset be represented as an executable interprocedural control flow graph (ICFG):

Gfirmware=(N,Ecall,nentry,Nvuln)G_{\text{firmware}} = (N, E_{\text{call}}, n_{\text{entry}}, N_{\text{vuln}})

where NN is the set of basic instruction blocks, EcallE_{\text{call}} represents control flow and branch transitions, nentryn_{\text{entry}} represents external network or bus ingress entry points (e.g., Modbus TCP frame parser, HTTP API endpoint), and NvulnN_{\text{vuln}} is the set of basic blocks containing the vulnerable library logic (e.g., buffer overflow in a legacy TLS parser).

The static reachability predicate Rstatic\mathcal{R}_{\text{static}} is defined as:

Rstatic=∃p=(nentry,n1,n2,…,nk)such thatnk∈Nvuln∧∀i,(ni,ni+1)∈Ecall\mathcal{R}_{\text{static}} = \exists p = (n_{\text{entry}}, n_1, n_2, \dots, n_k) \quad \text{such that} \quad n_k \in N_{\text{vuln}} \land \forall i, (n_i, n_{i+1}) \in E_{\text{call}}

If Rstatic=0\mathcal{R}_{\text{static}} = 0, the vulnerable function is dead code and was linked into the binary without being callable. The vendor's code_not_reachable claim is statically verified.

If Rstatic=1\mathcal{R}_{\text{static}} = 1, the CAB activates dynamic symbolic execution. Let x⃗\vec{x} represent the symbolic input vector entering nentryn_{\text{entry}}. Path constraints along path pp are collected as a first-order logic formula:

Φ(p,x⃗)=⋀j=1kψj(x⃗)\Phi(p, \vec{x}) = \bigwedge_{j=1}^k \psi_j(\vec{x})

The formula is submitted to an automated Satisfiability Modulo Theories (SMT) solver:

Result=Solve(Φ(p,x⃗))\text{Result} = \text{Solve}(\Phi(p, \vec{x}))
  • If Result=UNSAT\text{Result} = \text{UNSAT}, no combination of input network bytes can satisfy the branch conditions required to reach NvulnN_{\text{vuln}} under current configuration. The VEX claim stands.
  • If Result=SAT\text{Result} = \text{SAT}, the solver yields a concrete exploit input x⃗witness\vec{x}_{\text{witness}}. The laboratory injects x⃗witness\vec{x}_{\text{witness}} into a physical sample on the test bench. If memory corruption or unauthorized execution occurs, the vendor's VEX claim is formally falsified. The tender is suspended, and the non-conformance is logged to the PAN security ledger.

4. Physical and Hydraulic Boundary Falsification#

In accordance with Schema G_CPDT, physical parameters declared in DEXPI 2.0 files are subjected to physical testing by accredited laboratories:

  • Maximum Allowable Working Pressure (MAWP) Verification: The laboratory subjects valve bodies and heat exchanger shells to hydrostatic pressure testing at 1.5×MAWP1.5 \times \text{MAWP} in accordance with ASME Section VIII and EN 13445 [4].
  • Nozzle Mechanical Flange Stress Testing: External piping moment forces are applied to flange nozzles to verify that deflection does not compromise internal seal integrity or cause actuator binding.
  • Fail-Safe Dynamic Validation: Electrical power and pneumatic control air are severed simultaneously under maximum fluid flow to record whether the valve moves to its declared fail-safe state (fail-closed, fail-open) within the specified stroke time.

5. Cryptographic Dossier Issuance and Publication#

Upon successful validation of all physical and cybersecurity criteria, the CAB generates a standardized, tamper-evident attestation packet:

json
{
  "_type": "https://in-toto.io/Statement/v1",
  "subject": [
    {
      "name": "urn:eigenia:asset:actuator:rotork-iq3-cyber",
      "digest": {
        "sha256": "4a5c6d7e8f90123456789abcdef0123456789abcdef0123456789abcdef01234"
      }
    }
  ],
  "predicateType": "https://eigenia.org/attestation/cab-qualification/v1",
  "predicate": {
    "cabIdentifier": "urn:eigenia:cab:bureau-veritas-industrial-cyber",
    "nandoNotifiedBodyNumber": "0062",
    "evaluationModules": ["CRA-MODULE-B", "CRA-MODULE-C", "IEC-62443-4-2-SL2"],
    "certificateNumber": "BV-CRA-2026-09-8841",
    "vexFalsificationResults": {
      "totalCVEsEvaluated": 14,
      "falsifiedClaims": 0,
      "verifiedUnreachable": 12,
      "remediatedPatches": 2
    },
    "issueDate": "2026-09-11T14:45:00Z",
    "expirationDate": "2029-09-11T14:45:00Z"
  }
}

The document is cryptographically signed using the lead auditor's hardware-backed Ed25519 key and logged to the Sigstore transparency log. The PAN Registry indexes the certificate, instantly updating the asset's qualification status across all integrated buyer procurement portals.

6. Conclusion#

The Conformity Assessment Bidding Marketplace and VEX Falsification Protocol establish an objective, market-driven mechanism for industrial product assurance. By decoupling testing from proprietary bilateral relationships and introducing automated competitive bidding, PAN reduces certification turnaround times and lowers qualification costs. Concurrently, the rigorous application of binary symbolic execution and physical stress testing guarantees that verified assets withstand real-world operational and cyber threats across critical infrastructure.

7. References#

  • [1] European Parliament and Council, "Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act)," Official Journal of the European Union, vol. L, 2024.
  • [2] European Commission, "Blue Guide on the implementation of EU product rules 2022," Official Journal of the European Union, Notice 2022/C 247/01, 2022.
  • [3] Cybersecurity and Infrastructure Security Agency, "Vulnerability Exploitability eXchange (VEX) - Use Cases and Implementation Guidance," CISA Technical Report, Washington, DC, 2023.
  • [4] American Society of Mechanical Engineers, "ASME Boiler and Pressure Vessel Code, Section VIII: Rules for Construction of Pressure Vessels," ASME Standard BPVC-VIII, 2023.
  • [5] Ecma International, "CycloneDX Bill of Materials Specification," Standard ECMA-424, 1st ed., Geneva, Switzerland, 2024.
  • [6] in-toto Project, "in-toto Attestation Framework Specification v1.0," Linux Foundation, Tech. Rep. IN-TOTO-2023-01, 2023.
Eigenia Labs Open Scientific Publishing Standard
Licensed CC BY 4.0
Exact Verification Audit: 17,775 chars