← Home

ArmoredLedger

The Audit Trail You Can't Tamper With — and Don't Have to Trust

A technical whitepaper for CISOs, compliance officers, auditors, and technical buyers in regulated enterprise and government.

Executive summary

Every compliance regime on earth rests on a single assumption: that the record of what happened is true. Yet the records most organizations rely on — application logs, audit trails, release histories, AI decision logs — are mutable, vendor-controlled, and unverifiable by the very people who need them most: auditors, regulators, and courts. When the evidence lives in a database the vendor can edit, "trust us" is the whole security model. That is not evidence. That is a promise.

ArmoredLedger replaces the promise with proof. It records what happened, who or what did it, on whose authority, and when — cryptographically. Every record is content-addressed and hash-chained. Every attestation is signed against a trust-anchor allowlist. Every day, the ledger's Merkle root is committed to the Bitcoin blockchain via OpenTimestamps — a third-party-verifiable proof that a record existed at a point in time, backed by the most expensive-to-forge ledger on earth. And anyone can verify any record themselves, in a browser, without trusting Armored Gate at all.

The thesis in four words: trust no one, verify everyone.

The problem: "trust us" is not evidence

Audit logs today are broken as evidence for three reasons. They are mutable — a log in a database, object store, or SIEM is only as trustworthy as the administrator who controls it. They are vendor-controlled — verification means asking the vendor; the auditor cannot independently confirm the record shown today is the record written six months ago. They are unverifiable by the people who need them — an auditor cannot recompute a proprietary log's integrity; a court cannot distinguish a genuine timestamp from a plausible one. The gap is not a lack of logging. It is verifiable integrity.

How ArmoredLedger works

  1. Content addressing. Every record is identified by the SHA-256 digest of its canonical content. Change one byte and the address changes.
  2. Hash chaining. Each attestation carries the digest of the record before it, so any excision or reordering is mathematically detectable.
  3. Signed attestations. Each is signed (Ed25519, or HSM-backed P-384 for production releases) and verified against a trust-anchor allowlist.
  4. Merkle root → OpenTimestamps → Bitcoin. The daily root is committed to Bitcoin — proof of existence anchored to a public ledger no vendor controls.
  5. Public, in-browser verification. At trust.armoredgate.com/verify, anyone verifies signature, Merkle inclusion, and Bitcoin anchor — no login, plus offline-verifiable proof bundles.
  6. A fail-closed Policy Decision Point. Through /v1/authorize, the server-side PDP can prevent restricted activity before it happens.

Regulatory coverage matrix

Nearly every modern control framework demands the same capability: a tamper-evident, attributable, time-stamped record of security-relevant events. ArmoredLedger is the substrate that satisfies those requirements. It is the control and the evidence; certification belongs to the customer's system and assessor.

FrameworkStrongest ArmoredLedger fitHonest boundary
SOX (§302/§404/§802)§802 records anti-tampering + change-management provenance as tamper-evident ITGC evidenceITGC evidence, not a financial-reporting control
EU AI ActAttested AI-action logging + Art. 50 labeling + Art. 14 oversight + model cardsRecord-keeping layer, not a conformity assessment
NIST 800-53AU family (audit generation, protection, non-repudiation) via signed, anchored, append-only recordsValidated-module consumer; control selection is the system owner's
NIST SSDF / 800-161 / EO 14028Build + supply-chain provenance, SBOM linkage, Bitcoin-anchoredDocumented crosswalk; pipeline wiring for full coverage
CMMC / 800-171AU + non-repudiation for CUI environmentsNot an assessment; doesn't encrypt CUI at rest
SLSAEmits SLSA v1.0 provenance; exceeds transparency-log immutability via BitcoinNo numbered level claimed (an orthogonal maturity axis)
FedRAMPAU controls + continuous-monitoring evidenceAudit substrate, not an ATO
FIPS 140Signing in a FIPS 140-2 Level 3 HSMNot a CMVP-certified module of ours
GDPRAccountability + integrity; Art. 17 via salted hashes/pointers (never PII) + audited erasureCorrect usage (hash/pointer only) is a customer responsibility
HIPAAAudit controls + a mechanism to corroborate ePHI integrityNot the ePHI store; doesn't encrypt ePHI at rest
PCI-DSS v4.0Protect audit logs from modification + tamper/change detection; PDP prevents unauthorized changeCDE must emit the events
ISO 27001:2022Tamper-protected logging + trustworthy monitoring substrate + crypto integrityAn Annex-A control, not the ISMS
21 CFR Part 11Secure, time-stamped audit trails + signatures cryptographically bound to recordsSystem validation (CSV/CSA) is the customer's
DORA / SEC cyberTamper-evident, time-anchored incident evidence; external "when did you know" timestampEvidentiary backbone, not the disclosure decision

The differentiator: verify without trusting us

Vendor logs ask you to trust the vendor. Transparency-log approaches still anchor trust in the operator's signed tree heads. ArmoredLedger anchors to Bitcoin — a public chain we don't run, can't edit, and can't take down — and puts verification in your hands. The moat is not "our logs are better," but "you don't have to believe us at all."

Honest posture

See a live verification → Talk to us

Trust no one. Verify everyone. — ArmoredLedger, by Armored Gate. Signing performed with a FIPS 140-2 Level 3 HSM; ArmoredLedger is the tamper-evident control and evidence, not a certification.