We have huge respect for the AICPA, ISO/IEC, and HHS teams who built four decades of careful rules into those tests. The Hive stack does not skip them. It beats them, and as a side effect of every transaction, it also gives you evidence that is stronger and more checkable than any sample-based audit can produce.
Sample-based checks over 6 to 12 months turn into a signed receipt on every transaction.
An annual surveillance audit turns into checkable evidence on every API call.
An OCR sample audit on demand turns into a CRE on every single PHI access event.
We did not go through formal SOC 2 or ISO 27001 certification, and we want to be clear about why. We have huge respect for the work the AICPA, ISO/IEC, and HHS teams have put in over four decades to make those tests strict and careful.
The Hive stack does not skip those tests. It beats those tests, and as a side effect of every transaction, it produces evidence that is stronger than any sample-based audit can produce, by a margin you can measure. Here is how.
A SOC 2 Type II report says controls worked well over a window of time, usually 6 to 12 months, based on a sample of evidence a CPA looked at. Under AICPA guidance, that sample is usually 25 to 60 instances per control per year. ISO 27001 surveillance audits sample at a similar rate. HIPAA OCR audits check a small slice of records on demand.
Evidence instances per control per year. The auditor pulls from a set of records the CPA defines, applies AICPA sampling rules, and gives a 95% confidence opinion on whether the control worked.
Evidence instances per control per year, at 10,000 transactions a day. Every transaction gets a signed envelope. No sampling. No guessing. Either you have the receipt or you don't.
| Profile | Per-day events | Per-year events | Multiplier vs SOC 2 sample (60/yr) |
|---|---|---|---|
| High-volume API platform | 10,000 | 3,650,000 | 60,833× |
| Mid-volume SaaS / fintech | 1,000 | 365,000 | 6,083× |
| Hospital: PHI access events | 250 | 91,250 | 1,520× |
| Low-volume regulated entity | 100 | 36,500 | 608× |
In any real deployment, the multiplier never falls below 100×. That's the floor. Your transaction volume sets the ceiling, not how strict the audit is.
A SOC 2 sample of 60 says the control was probably working in the 60 cases the auditor checked. Sampling math lets you guess beyond that, at a confidence level that depends on how big and how similar the full set of records is. A real auditor would give you 95% confidence, with a margin of error of a few percent.
A CRE on every transaction says the control either worked or it did not, on this exact transaction, and here is the signed record from the moment it ran. There is no guessing. There is no confidence interval. There is the receipt, or there is no receipt.
SOC 2 is a review done by a CPA firm under AICPA SSAE 18 rules. A Type II report covers a window of 6 to 12 months. Controls get checked against five categories: Security (the common criteria CC1 to CC9, always required), Availability (A1), Confidentiality (C1), Processing Integrity (PI1), and Privacy (P1 to P9). The auditor samples evidence from each control group and gives an opinion on whether it worked.
| SOC 2 control area | Sample-based attestation | CRE per-transaction equivalent |
|---|---|---|
| CC6.1 | Logical access: auditor pulls 25 to 60 access-control samples a year | Ed25519 + ML-DSA-65 dual signature on every API call, bound to tenant ID |
| CC6.6 | Encryption in transit: sampled TLS setup evidence | ML-KEM-768 / Classic-McEliece-6688128f hybrid KEM on every payload |
| CC7.2 | Anomaly detection: sampled monitoring records and tickets | MMR root commitment: any change breaks the inclusion proof |
| CC7.3 | Incident response: sampled incident tickets and post-mortems | Tombstone receipt for every revoked or rotated credential, MMR-witnessed |
| A1.2 | Availability: sampled uptime reports and SLA tickets | /v1/cre/health endpoint feed signed and committed to MMR |
| PI1.1 | Processing integrity: sampled data-processing records | 4-family hash cascade (SHA3-256 + BLAKE3 + KangarooTwelve + cSHAKE128) |
| C1.1 | Confidentiality: sampled access logs and encryption settings | Per-envelope confidentiality classification + epoch-bound key |
| P1 to P9 | Privacy series: sampled DSAR responses and consent records | PII-class envelope field + forward-secure key epoch (deletion-by-key) |
ISO/IEC 27001:2022 spells out an Information Security Management System, and an accredited body certifies it through a yearly surveillance audit. Annex A 2022 folded the old 114 controls down into 93 controls across 4 themes: Organizational (37), People (8), Physical (14), and Technological (34). The auditor samples how well selected controls are set up.
| ISO Annex A control | Surveillance audit cadence | CRE machine-verifiable evidence |
|---|---|---|
| A.5.15 | Access control: sampled once a year | Ed25519 signature on every API call, tenant-bound |
| A.5.34 | Privacy and protection of PII: sampled once a year | PHI-class envelope field + per-record epoch label |
| A.6.7 | Remote working: sampled policy plus interview | Endpoint posture committed to envelope at session open |
| A.8.5 | Secure authentication: sampled MFA setup | ML-DSA-65 (FIPS 204) co-signature on every auth event |
| A.8.10 | Information deletion: sampled deletion runbooks | Forward-secure key epoch (Bellare-Miner): deletion-by-key |
| A.8.16 | Monitoring activities: sampled SIEM records | MMR append-only log, root publishable any time |
| A.8.24 | Use of cryptography: sampled key-management evidence | 5-Assumption Stack (PentaPQ) + Triad-Bound Receipt all-of-3 |
| A.8.28 | Secure coding: sampled code-review tickets | 4-family hash cascade integrity check on every artifact |
HIPAA is the Health Insurance Portability and Accountability Act of 1996. It has the Privacy Rule (45 CFR Part 160 and Subparts A and E of Part 164), the Security Rule (Subpart C of Part 164, covering technical, physical, and administrative safeguards), and the Breach Notification Rule (Subpart D). HHS Office for Civil Rights enforces it. OCR audits check a sampled slice of records on demand. A typical hospital creates roughly 250 PHI access events a day per active service line.
Hive runs a HIPAA-focused product at /hipaa-hive/ that applies the CRE envelope directly to PHI access events. This section explains the framework. That page is where you use the product.
| HIPAA Security Rule section | Compliance evidence as practiced today | CRE per-transaction equivalent |
|---|---|---|
| §164.312(a)(1) | Access control: access logs sampled on OCR request | Ed25519 signature, tenant ID, and role on every PHI access event |
| §164.312(a)(2)(iii) | Automatic logoff: sampled setup screenshots | Session epoch label expires; envelope refuses to reissue after that |
| §164.312(b) | Audit controls: audit logs sampled on demand | MMR append-only log, with a publishable bagged-peaks root |
| §164.312(c)(1) | Integrity: sampled integrity-check runbooks | 4-family hash cascade per envelope (SHA3-256 plus BLAKE3 plus K12 plus cSHAKE128) |
| §164.312(d) | Person-or-entity auth: sampled auth setups | Triad-Bound Receipt: Ed25519 plus ML-DSA-65 plus SLH-DSA-SHAKE-256f |
| §164.312(e)(1) | Transmission security: sampled TLS setup | ML-KEM-768 / Classic-McEliece-6688128f hybrid KEM (TBR-grade) |
| §164.308(a)(1)(ii)(D) | Information system activity review: sampled reports | Per-envelope inclusion proof checked against the published MMR root |
| §164.530(j) | Documentation: six-year retention sampled by OCR | Forward-secure key epoch tag per envelope, kept by class |
We won't hide the parts that are still roadmap instead of shipped. Rows marked Not held stand out on purpose, because the whole point of this page is telling apart what we hope to do from what we've actually built. If a number changes, the table changes. We will never move a row from “Not held” to “Held” without the real letter or certificate behind it.
| Capability | Status today | Path |
|---|---|---|
| Per-transaction CRE issuance + verification | Shipped: /v1/cre/issue, /v1/cre/verify | n/a |
| 4-family hash cascade (SHA3-256 + BLAKE3 + KangarooTwelve + cSHAKE128) | Shipped, all four channels native | n/a |
| Append-only MMR with bagged-peaks root | Shipped, file-backed | Public timestamping anchor: Q3 |
| Ed25519 + ML-DSA-65 dual signature | Shipped (FIPS 204 final standard) | n/a |
| Triad-Bound Receipt (TBR): Ed25519 plus ML-DSA-65 plus SLH-DSA-SHAKE-256f all three, ML-KEM-768 / Classic-McEliece-6688128f hybrid KEM | Shipped, /v1/cre/tbr/* (Build #41) | n/a |
| Forward-secure key epoch annotation (Bellare-Miner) | Shipped: daily rotation, label-only | Full key-erasure ratchet: Q3 |
| Side-channel measurement (TVLA, 5 classes claimed) | 2 of 5 measured today (timing plus power-trace), 3 on roadmap | Full ISO/IEC 17825 reporting: Q4 |
| Cross-framework control mapping | 225 controls, 13 frameworks, a checked count published per envelope | Expanding to PCI DSS v4 plus FedRAMP Rev 5: Q3 |
| Formal SOC 2 Type II letter from a CPA firm | Not held: we did not go through formal channels | On request, we will help a customer's auditor |
| Formal ISO 27001:2022 certificate from an accredited body | Not held: we did not go through formal channels | On request, we will support a customer's auditor |
| Independent third-party MMR-root publication | Not yet | Public timestamping anchor: Q3 |
No, not through formal AICPA channels. We have the deepest admiration for the framers and we exceed those tests. Every Hive transaction issues a Compliance Receipt Envelope signed under Ed25519 and ML-DSA-65: machine-checkable evidence that gives 100× to 60,833× more coverage per control than a SOC 2 sample.
A customer who needs a paper SOC 2 letter can still get one from a CPA firm; we support their auditor with the CRE log and MMR root. The auditor's job becomes verifying envelopes rather than sampling files.
No, not through an accredited body. Same posture as SOC 2: deepest admiration for the ISO/IEC framers, and we exceed those tests with per-envelope machine-verifiable evidence mapped to Annex A 2022. A customer who needs a certificate can still get one; we support their auditor.
We do not use the regulator-quoted phrase “HIPAA compliant” for ourselves because compliant is a determination made by the covered entity and (when audited) by OCR. The Hive HIPAA-Hive vertical applies the CRE envelope to PHI access events and produces per-record receipts mapped to the HIPAA Security Rule (45 CFR §164.312). See /hipaa-hive/.
A typical hospital generating 250 PHI access events per day gets 1,520× more evidence than an OCR sample audit can review.
Yes. The auditor's job becomes verifying envelopes against the published MMR root rather than sampling files. The CRE log contains every transaction; the MMR root is publishable; per-envelope verification is yes-or-no. Auditor work is faster and the underlying evidence is stronger.
MMR is the Append-Only Witness Merkle Mountain Range. Every CRE envelope is committed to it as it is issued. The bagged-peaks root is a single hash that proves the entire log existed at a given moment.
We expose it on /v1/cre/health and /v1/cre/mmr/root. Public timestamping anchor publication is on the Q3 roadmap and will be added to the disclosure table when it ships.
Use /v1/cre/export with a date range and tenant ID. The endpoint returns a JSON Lines bundle of every CRE envelope in the range plus the MMR inclusion proofs and the period root. Hand the bundle and root to your auditor; they verify with /v1/cre/verify or any client that implements the CRE spec.
Get one. The CRE log makes that engagement faster and the underlying evidence is stronger than a sample-based pull. We support your auditor or accredited body by providing the CRE log, the MMR root, and the framework reduction map (225 controls, 13 frameworks). The certificate sits on top of forensic evidence rather than inferential evidence.
Yes. The CRE issuer and verifier are stateless given a key and an MMR file. On-prem deployments keep their MMR file local and publish only the period root. The 4-family cascade hash, Ed25519 + ML-DSA-65 signatures, and Epoch Ladder forward-secure key rotation all run without a Hive network dependency.
A CRE is a signed JSON record issued for every transaction. It contains the canonical hash of the transaction (4-family cascade), the Ed25519 + ML-DSA-65 dual signature, the epoch label, the MMR position and inclusion proof, and the tenant + framework annotations. It is Per-Transaction Audit Evidence in a single self-contained envelope. Architecture details: /cre/.
Triad-Bound Receipt (TBR) is the all-of-three signature mode shipped in Build #41: Ed25519 (classical) plus ML-DSA-65 (FIPS 204 lattice) plus SLH-DSA-SHAKE-256f (FIPS 205 hash-based), with payload confidentiality under a ML-KEM-768 / Classic-McEliece-6688128f hybrid KEM. Three independent hardness families must all break to forge a TBR. Endpoints: /v1/cre/tbr/issue, /v1/cre/tbr/verify. See /cre/#triad.
Every CRE envelope maps to specific controls in 13 frameworks: SOC 2, ISO/IEC 27001:2022, HIPAA, GDPR (Articles 5 to 35), EU AI Act (Articles 9 to 17, 50), CCPA, NIST CSF, NIST SP 800-53, NIST SP 800-171, FFIEC, NYDFS Part 500, ISO 42001, and SOX. PCI DSS v4 and FedRAMP Rev 5 expansion is on the Q3 roadmap.
Dashboards show you control state over time and are an excellent monitoring layer. On their own, they are not audit evidence. An auditor still has to pull raw records and sample them. The CRE envelope is the record, signed the moment the control ran, and the MMR root proves that record existed and wasn't changed. Dashboards read from CRE. CRE is the source.
The doctrine is on this page. The receipt is on /cre/. The Triad-Bound Receipt is at /cre/#triad. If you have an auditor question we did not answer, write to us directly.
Every Hive surface signs its own evidence with the same primitives: SHA3-256 canonical hashing, Ed25519 + ML-DSA-65 dual signatures, and a published Merkle Mountain Range root. The receipt is the audit evidence. This same envelope works everywhere: every transaction, every framework, every surface.