INTYGIOBuild it. Sign it. Ship the proof. Who signed what shipped?
sign(artifact_hash) → proof verify(proof) → authentic // offline, forever
Cryptographic signing for software artifacts, SBOMs, and release pipelines. EU Cyber Resilience Act compliance from one API call.
The build pipeline is the
new attack surface.
SolarWinds was a build system compromise. XZ Utils was a supply chain compromise. The common thread: no cryptographic proof of what actually went into the artifact.
Unsigned artifacts
No cryptographic way to prove a binary wasn't tampered post-build. SolarWinds, XZ Utils: the attack vector is always the same. The artifact reaches production with no chain of custody.
no integrity proofNo SBOM attestation
Listing dependencies is not the same as proving they're authentic. A CycloneDX file with no signature is just a text document. Anyone can edit it. Nothing prevents a post-build substitution.
unverifiable manifestsCRA compliance gap
EU Cyber Resilience Act requires verifiable software integrity for CE-marked products from 2027. Most pipelines have zero cryptographic provenance. A SBOM in a README does not satisfy Art. 13.
regulatory exposureSupply chain opacity
Who built this? From which commit? With which dependencies? Without signed provenance, these are claims, not facts. SLSA exists precisely because the industry finally admitted this was a problem.
unverifiable claimssign(artifact_hash) → proof verify(proof) → authentic
eIDAS-aligned seal · sealed key custody · offline verification
Three primitives. One API call.
The same cryptographic infrastructure used across EU trust services, applied to every artifact that leaves your build system.
Hash
A cryptographic digest of the artifact: binary, container image, SBOM, config file, WASM module. The digest is the artifact's identity. One bit changes, the hash changes.
Sign
An advanced electronic seal over the digest, built to eIDAS and engineered for QSealC. Signing keys are sealed at rest, never exposed in plaintext. One API call from any CI/CD environment.
Verify
Anyone, offline. The verifier has the artifact and the signature, so checking it is arithmetic rather than a request to a server. An RFC 3161 timestamp fixes the moment of signing, so the proof outlives the certificate that made it.
Built for pipelines
that need to prove themselves.
Five capability clusters. One API. CRA Art. 13 covered.
Sign any file type: compiled binary, WASM module, container image, APK, config archive. The signature binds to the content digest of the exact bytes that left your build.
- Any artifact type: binary, WASM, container, APK
- Content digest
- eIDAS-aligned electronic seal
- Detached or bundled proof
Sign CycloneDX or SPDX SBOMs at build time. A signed SBOM is a tamper-evident record of what went into the artifact. An unsigned one is a text file that proves nothing.
- Sign any SBOM file your toolchain produces
- CRA Art. 13 compliance path
- Tamper-evident dependency manifest
- Proof survives handoff to any auditor
REST API callable from any CI/CD environment. GitHub Actions, GitLab CI, Jenkins, Tekton: if it can run a curl, it can sign. No agents. No sidecars. No registry.
- REST API: sign and verify endpoints
- One curl call from any CI environment
- No agents, no sidecars, no registry
- Sign at build, verify at deploy gate
Who built it, when, from which commit, with which toolchain: cryptographically bound to the artifact. SLSA-compatible provenance metadata. Not a claim. A proof.
- Builder identity and timestamp
- Commit SHA and branch provenance
- Cryptographically bound to the artifact
- Immutable provenance record
CRA mandates that manufacturers of CE-marked products with digital elements provide verifiable software integrity from October 2027. Art. 13 is specific: the obligation is on the manufacturer, not the distributor. The signing infrastructure has to exist before the products ship.
- CRA Art. 13: software integrity obligations
- CE-marked products with digital elements
- SBOM disclosure obligation (Art. 13.3)
- Signed provenance as compliance evidence
The stack is auditable
by design.
Intygio didn't invent the cryptography, the SBOM formats, or the compliance framework. Intygio assembled them correctly and wired them into a pipeline that ships. Every standard listed here is public, open, and independently verifiable.
EU Cyber Resilience Act
Regulation (EU) 2024/2847. Software integrity and SBOM obligations for manufacturers of CE-marked products with digital elements. Deadline: October 2027.
Supply-chain Levels for Software Artifacts
CNCF / OpenSSF framework for software supply chain integrity. Build L2 requires signed provenance from the build platform. L3 adds isolated build environments.
SBOM Standard
OWASP-managed SBOM standard. Supports BOM for software, hardware, services, and formulas. Native attestation support in CycloneDX 1.5 for signed component provenance.
Software Package Data Exchange
ISO-ratified SBOM format. Native tooling in most build ecosystems. SPDX 3.0 introduces a first-class security profile aligned with CRA disclosure requirements.
Secure Software Development Framework
NIST guidance referenced in US Executive Order 14028 and aligned with CRA Annex I technical requirements. Defines producer responsibilities for verifiable integrity.
QSeal Trust Chain
Qualified Electronic Seals under Regulation (EU) No 910/2014. Intygio signs eIDAS-aligned advanced seals today, engineered to root in the EU Trusted List via a contracted QSealC. Cross-border by default.
The signing infrastructure
ships before the deadline.
The Cyber Resilience Act takes effect 2027. The signing infrastructure is being built now. Products that ship without signed provenance won't become compliant by patching a README.
For the Chief Sustainability Officer at a connected-device manufacturer, the CRA compliance plan looked solid until the first customer security questionnaire asked for a signed bill of materials. A README is not a signature.
Every release is logged, timestamped, and tied to the exact build that shipped. The software supply chain is observable, not assumed. The next customer security questionnaire asks for a signed bill of materials. The answer takes three minutes, not three weeks.