Firmware · Compliance QA
Protected Firmware Asset Management and Download Service.
Verified and documented Software Bill of Materials for the Shopify ecosystem. Your firmware is never a file at a URL: it is vaulted under per-image encryption, every upload is certified, every download is granted, and every event lands in a tamper-evident ledger — the evidence chain the EU Cyber Resilience Act assumes you already have.
What it is
Firmware distribution today is mostly a signed installer behind a storage link — a URL that, once shared, is shared forever, with no record of who fetched it or when. This service replaces the link with a grant. A firmware image enters through an encrypted vault and only leaves through a two-step authorization gate. In between, three records outlive the transaction: a registry row (product, version, size, full SHA-256, linked SBOM), an upload certificate (Ed25519-signed proof of what was vaulted, by whom, when), and a hash-chained access ledger — every grant, every denial, every served byte-stream, each row sealing the one before it.
We are Shopify platform native — purchase, receipt, and order records ride your existing store checkout, not a parallel billing stack — and we work upstream with your software systems: SBOMs flow in from your firmware build (Yocto, Zephyr) or binary analysis (EMBA, cve-bin-tool), certificates verify in any stack against a public JWKS endpoint, and every function here is an API your CI can call.
Rule-based security · order of execution
Two pipelines. Every step must pass.
Upload — how an image is vaulted:
- Authorization — platform key or a signed-in account holding the Firmware Security capability. No capability, no vault: the request ends with a purchase path, not a partial upload.
- Digest — full SHA-256 of every byte; the image's identity for life.
- Encrypt — AES-256-GCM under a random content key generated for this image alone.
- Wrap — the content key is itself encrypted under a versioned derived key; ciphertext and wrapped key are stored apart, useless alone.
- Ledger — the upload event seals into the hash chain.
- Certify — an Ed25519 attestation binds product, version, digest, uploader, and the linked SBOM.
- Register — the registry row lands in the system of record.
- Publish provenance — digest + certificate + chain tip go public. No key material, no download path.
Download — the verification order:
- Grant check against the image's capability — denials are recorded too.
- Single-use window — a 120-second signed token bound to this image, key version, and a per-fetch serial.
- Token verification — right image, right key version; a rotation kills every earlier token instantly.
- Server-side decrypt — the key never leaves the server; ciphertext, URL, or an expired token yields nothing.
- Serve + ledger — who, when, how many bytes, which serial.
-
Client verification — hash what arrived, compare to provenance, verify the certificate against
/.well-known/jwks.json. No account, no trust in us required.
Healing: a suspected leak is answered by key rotation — ciphertext untouched, every previously issued wrapped key and token dead at once.
Why we are secure
Most “secure delivery” is a promise about infrastructure. Ours is a property of the data path. The image is encrypted before it is stored, so storage compromise yields ciphertext. The decryption key is wrapped and versioned, so exposure heals with one rotation instead of a re-upload. Access is a capability held by a subject — a person, a teammate, an agent — not a link, so it is granted, audited, and revoked per subject in real time. Identity itself rides a double-key system: PKCE proves the human at sign-in with no client secret to steal, and JWE seals the actor's identity so it is only ever read server-side; logout revokes the session token immediately, everywhere. And every one of these decisions writes a ledger row whose hash includes the row before it — the history cannot be quietly edited, only visibly broken.
Where each layer lands in CRA reporting
SBOM per image
Identify and document components; SBOM available to authorities on request — Annex I Part II; BSI TR-03183-2
Upload certificate
Integrity and provenance evidence for the product placed on the market — Annex I secure-by-design documentation
Hash-chained ledger
“Who accessed what while vulnerable” — the factual basis of Article 14 reporting: 24-hour early warning / 72-hour notification / 14-day final report, in force 11 September 2026
Grant-gated download
Control of the distribution channel; a secure update mechanism you can attest — Annex I secure updates, access control
Key rotation
Vulnerability handling: remediate without recall — leaked credentials die server-side (Annex I Part II)
Register + receipts
Demonstrable conformity trail for market surveillance — Articles 13–14; groundwork for the Declaration of Conformity by 11 December 2027 (Commission overview)
Receipt of transaction
Purchase
Native Shopify checkout; the order is your commercial record. Payment mints the entitlement automatically — no manual provisioning.
Upload
The Ed25519 certificate arrives by email with a public verify link — the same proof-of-record notifications the attestation demos send.
Download
Each serve carries a serial in the response headers and a matching ledger row; the verification register is the chain of custody per certificate.
Verification
Anyone verifies any certificate at /license/verify against the published public key. No account. No trust in the platform required.
Upload panel
Checking your access…
Products
$250 · one-time
$49 / mo
$90 · license
$900 · engagement
Practical guidance, not legal advice. CRA scope — especially whether your device is default category or Class I/II — is confirmed with counsel as part of the CRA Readiness Assessment.