AmberKeyTrust
Claims with receipts.
No logo wall. Each claim below states its precise strength, conforms to (testable, with public tests), aligned with (self-assessed, mapping published), or in progress (no claim yet), and links the artifact you can check it against. The words “certified,” “validated,” and “compliant” appear on this page only in the list of things we deliberately do not claim.
Last reviewed: July 11, 2026. If a claim and the code disagree, the code wins and this page is wrong, tell us.
Conformance you can test yourself
The strongest claims we make. Specification conformance with public tests. These are what make the exit guarantee real.
SLIP-39 (Shamir mnemonic shares)
Conforms to
In-house implementation gated on the complete official Trezor test-vector suite, run in CI on every commit. Any standard SLIP-39 tool reconstructs the card set's 32-byte master secret; our published format spec explains how to convert it into the age identity that decrypts the bundle.
age v1 encryption
Conforms to
Bundles are standard age v1 files (X25519 (RFC 7748, ChaCha20-Poly1305) RFC 8439) in a tar container. Decryptable with the stock age CLI; no proprietary format anywhere.
Reproducible + signed recovery tool
Verifiable build
CI builds recover.html twice and fails on any hash mismatch; releases are minisign-signed and the tool’s SHA-256 and signing-key fingerprint are printed on every physical card.
Framework alignments (self-assessed)
Self-assessments, published in the open-source repository so they can be checked against the code. No third party has audited these and we don’t imply one has.
NIST SP 800-63B (authentication)
Aligned with AAL2 authenticator requirements
Passkey-first (phishing-resistant), no passwords at all, no SMS as an authentication factor, single-use rate-limited TOTP fallback, step-up re-auth before sensitive changes. One deviation (30-day rolling sessions) is documented, with rationale, in the assessment.
NIST SP 800-218 (SSDF)
Aligned, self-assessed
Warnings-as-errors static analysis, dependency audits, reference-vector tests, deterministic CI rebuilds, and signed pinned releases. Mapped practice-by-practice to the SSDF, with the gaps named (including full third-party reproducibility).
NIST CSF 2.0
Self-assessed profile
A profile across all six functions that is honest about maturity. Detect (once the weakest function) now rests on managed threat detection, a validated account audit trail, and alarms where silence itself pages; Recover runs at RPO ~1s / RTO ~10min with an operator-held offline key AWS cannot read.
CIS Controls v8, IG1
Self-assessed, published verdict per control
12 of 18 controls in place, 3 partial (each gap named: operator MFA/account inventory, IR plan, pen test), 3 not applicable at this size. Production runs on managed containers (no server OS to patch) behind an edge WAF with account-level threat detection, KMS encryption at rest everywhere, and continuously replicated, cross-region backups.
OpenSSF Best Practices badge
Passing (100%), public, itemized self-certification
Scope: the open-source recovery components (the public repo. Crypto core, offline recovery tool, specs), not the hosted service. Every criterion answered on the record at bestpractices.dev: reporting, change control, quality gates, crypto practices, analysis. Self-certified by design, but itemized and public, so it reads as accountability, not marketing.
NIST SP 800-207 (Zero Trust)
Architecture described in its terms
The blind server is data-centric zero trust: no implicit trust in any network or in the server itself. Every request is authenticated; the most sensitive assets (vault contents, keys, shares) never reach the server in any form it can read.
In progress, not yet claimed
- OWASP ASVS 4.0 Level 2. Chapters V2/V3/V4 itemized and published (after two remediation rounds: 39 met, 7 partial, 0 gaps of 79 applicable) every outright gap found has been fixed, remaining partials queued openly. Remaining chapters underway; no claim until all are verified. status
- OpenSSF Scorecard. Runs weekly in the public repo's CI with published results; some process checks score low by construction (the repo is an assembled release mirror). Accepted and stated rather than gamed.
- SLSA-informed build provenance. CI now generates and signs an in-toto/SLSA v1 statement (image digests + recover.html + source commit) per release, from our self-hosted builder; the first release carrying it is next. Verification steps in the artifact. status
- CISA Secure by Design pledge. Goal-by-goal evidence published (all seven goals met or exceeded, one gap named); company signature pending. status
What we deliberately do not claim
A trust page is only as good as what it refuses to say. These are the badges we could decorate with and choose not to:
FIPS 140-3 “validated”
FIPS validation applies to specific modules tested under CMVP; nothing here has been submitted. Moreover, AmberKey deliberately uses IETF-standardized cryptography (X25519, ChaCha20-Poly1305) rather than FIPS-approved algorithms, so we skip FIPS language entirely instead of borrowing its authority.
SOC 2
Requires an independent CPA attestation over an observation period. We maintain a pre-audit hardening program with SOC 2 in view, and will pursue a Type II when a counterparty needs it. Until then we don’t say “SOC 2” next to our name.
ISO/IEC 27001 certification
Requires an accredited certification body. No certificate exists; we don’t imply one.
HIPAA / FedRAMP
Not relevant to this product; listing them would be decoration.
The infrastructure underneath
Production runs on AWS (us-east-1/us-east-2, backup replication to us-west-2). AWS holds its own certifications. SOC 1/2/3, ISO 27001, and more, published in AWS Artifact — and those attest to the physical data centers, hypervisor, and managed servicesunderneath us. Under the shared-responsibility model, everything above that line — our code, configuration, keys, and operations, is ours to secure and ours to prove, which is what the rest of this page does. We state the split rather than borrow the badge: “hosted on SOC 2 compliant infrastructure” is not a claim about AmberKey, and you won’t see us make it. What we do inherit and use: encryption at rest (KMS), managed network defense (WAF), account-level threat detection and audit trails, and a platform where no server OS of ours exists to go unpatched.
Privacy obligations
GDPR and CCPA/CPRA are obligations you meet, not certificates you hang. Our privacy policy is the artifact: it enumerates exactly what we store, the longer list of what we are structurally unable to see, every subprocessor, and your rights — and the blind-server design means the honest answer to most data-request categories is “we don’t have it.”
The escalation path
Self-attestation with receipts is the honest ceiling for a product at this stage, and it has a limit worth stating plainly: no outside firm has yet penetration-tested or audited the deployed application, the coordination backend, or the recovery ceremony API. The cryptographic core is open and vector-tested, but the hosted client and server are proprietary and, for now, self-assessed. The planned next rung is a paid, independent security review by a specialist firm covering both the open cryptographic core and the deployed browser application plus ceremony API, published in full. Followed, when a counterparty requires it, by a SOC 2 Type II. Neither will be claimed a day before it exists.
In the meantime, outside eyes are explicitly invited: a published vulnerability disclosure policy with safe harbor for good-faith research, a machine-readable security.txt (RFC 9116), and an open dev instance researchers may test against.
Independent security validation, live
Our publicly observable configuration — TLS, security headers, email authentication, DNS — is continuously testable by anyone, using the same independent scanners we use. These links run a fresh scan or live rating, not a snapshot we curated: if our configuration regresses, these pages will say so before we do.
- Qualys SSL Labs — TLS protocol, cipher, and certificate configuration
- MDN HTTP Observatory — security headers (CSP, HSTS, isolation policies)
- ImmuniWeb CyberScore — combined web, TLS, email (SPF/DKIM/DMARC/MTA-STS), and privacy posture
Honest scope: these tools verify the edge — transport security, headers, mail and DNS hygiene. They cannot see inside the application, and an A+ here is not an application audit. Authenticated application and API security remain self-assessed until the independent review described above exists; we won't dress configuration grades up as one.
See also: security & threat model ·open source & mirrors ·what happens if we shut down