Product security commitments and the responsible-disclosure process.
Send the report to the security address below.
A report is triaged and remediation is coordinated from that channel. Include what is needed to reproduce it.
Which product, which surface, and which version or deployment shape.
The steps, inputs, and conditions needed to observe the issue.
How to reach you to coordinate remediation and disclosure.
Do not send credentials, private keys, regulated health information, payment-card data, or confidential corpora through the general contact channel. Use the security or legal review path so a suitable NDA, transfer channel, and retention policy can be established first.
Offline evidence verification and offline operation of the whole product are different capabilities. Review the exact product, release, and deployment.
| Product | Signing and key custody | Evidence verification scope |
|---|---|---|
| HX-SDP | ML-DSA-65 exact-result receipts. Customer-controlled Private Appliance. | Delivered exact-result and release evidence have documented offline verification procedures. Confirm the supplied release and expected issuer key. |
| HX-Provenance | ML-DSA-65. In-tenant appliances generate per-instance keys at first boot; customers control custody. A separately agreed hosted API onramp uses issuer-held keys. | Use the supplied verifier, receipt or bundle, and expected issuer public key. Marketplace and private-appliance boundaries differ from any hosted API evaluation. |
| HX-PQC | ML-DSA-65 for signed lifecycle artifacts within the agreed appliance or pilot boundary. | Local verification is described for lifecycle evidence. Offline evidence checks do not establish full air-gapped operation of a future edition. |
| HX-AIFactoryTwin | Ed25519 evidence certificates; a labeled HMAC fallback requires shared-secret verification. Confirm the supplied mode and expected issuer material. | Local artifact checks are product- and mode-specific. HMAC uses shared-secret verification and must not be described as independent public-key verification. |
| HX-MDAO-TP | ML-DSA at commit boundaries in the scoped engineering deployment. | Review validity and acceptance evidence for the agreed pilot. Formal certificates apply to specified invariants, not every model or result. |
| HX-AEIR | Customer-local ML-DSA-65. First boot is keyless; deliberate customer initialization creates the signing identity. | Use the standalone verifier, complete package, independently pinned public key, and required linked material. |
HX-SDP publishes release-verification procedures for its signed deployment bundles. HX-Provenance supplies a release dossier and a customer-runnable appliance validation harness, described below. Select the instructions and verification material for the delivered product version.
SDP release verification · Provenance delivery and control · Offline verification guide
The documented HX-Provenance Private Appliance includes signed release manifests, offline verification and a validation harness that the customer security team can run independently. Its release dossier identifies the supplied version and supporting security artifacts.
The local verifier checks receipts and evidence bundles without a network connection or a HolonomiX endpoint. Verification uses the matching tool, complete evidence and expected issuer public key; retaining those materials supports checks after an outage or issuer change.
Read offline verification instructionsFor the documented HX-Provenance Private Appliance, signing keys are generated on the appliance at first boot, stored under customer-controlled permissions and retained in the customer environment. Receipt persistence and the storage backend are also customer-controlled.
HX-AEIR uses deliberate customer initialization instead of first-boot generation; the product matrix above preserves that distinction.
The documented HX-Provenance appliance supports customer-controlled air-gapped deployment without outbound connectivity. Its signed-JWT license can be installed, verified and rotated offline.
Review the appliance deployment boundaryEvery shipped file in the documented HX-Provenance appliance release is hashed, and the manifest is signed with an offline release key. The appliance checks its manifest at first boot and refuses to start if verification fails.
The HX-Provenance release-blocking validation script covers fourteen gates, including DNS and TLS posture, health, the authentication boundary, public verification, receipt issuance and verification, tamper rejection, schema compatibility, bundle export, workspace quota, rate limiting, persistence, backup status and metrics. The customer security team can run the supplied harness independently.
The documented HX-Provenance release dossier includes a CycloneDX SBOM, vulnerability scan report, build provenance, validation summary, signed release attestation and offline verification instructions. These are product-specific delivery commitments; the dossier and validation results apply to the supplied release.
Read the delivery specification · Request the release dossier
HX-Provenance cryptographic primitives.
The HX-Provenance cryptographic module is built to FIPS 140-3 architecture, addressing the eleven security requirement areas defined by ISO/IEC 19790. CAVP algorithm validation and CMVP module validation are on the enterprise roadmap, gated by buyer commitment; the module is built to the standard, and the certificate path runs against an enterprise contract.
Elsewhere in the portfolio, including the HX-PQC Lifecycle Platform, the claim is that HolonomiX uses NIST-standardized algorithms where implemented. No FIPS 140-3 or CMVP validation is claimed unless a validated module certificate supports the exact deployment.
