Evidence-layer evaluations spend disproportionate time on the chain — Polygon vs Ethereum vs private chain, finality, gas, vendor neutrality. These questions matter, but they are not the load-bearing security question. The load-bearing question is: who controls the keys that sign records before they are hashed and anchored? A KMS — Key Management Service, the system that holds and uses cryptographic keys on your behalf, with AWS KMS, Azure Key Vault, and HashiCorp Vault as the common products — is what answers that question. If the KMS is compromised, the strongest blockchain in the world will faithfully anchor records that are already wrong. The chain is a witness; the KMS is the author. This post is for security architects who need to think clearly about where the actual trust boundary lives.
Why the chain is not the security boundary
The job of an anchored Merkle root is to prove that a specific batch of records existed at a specific moment and has not changed since. It is excellent at that job. What it cannot do is prove that the records were correct at the moment they were authored. Anchoring is integrity over time, not authenticity at origin.
The authenticity-at-origin question is answered by signing — typically a record is signed with a private key controlled by the system or person that authored it, and the signed record is what gets hashed and anchored. If the signing key is compromised, anything that gets signed is provably authored by the holder of the key, regardless of whether the holder is who they claim to be. The chain does not see this distinction. It anchors what it is given.
Three failure modes that the chain does not catch
If the KMS is the security boundary, the question becomes which KMS-related failures result in anchored-but-wrong records. Three modes show up consistently in security reviews:
- Key compromise — an attacker obtains the signing key and authors records that look legitimate. The chain anchors them faithfully. Forensic recovery requires identifying the compromise window and revoking all anchored records signed during that window. The integrity anchor proves they existed; it does not prove they were authentic.
- Key custody migration — your team rotates from one KMS to another, or migrates between cloud providers, and the rotation does not preserve the chain of attestations linking old keys to new keys. Records signed under the old key are still verifiable, but the audit narrative requires explicit key-lineage documentation. Without it, the gap is exploitable in litigation.
- Insider key extraction — a privileged operator extracts the key material itself, not just the ability to sign. Subsequent records authored with the extracted key are indistinguishable from authentic ones at the chain layer. The defense is HSM-backed keys that cannot be extracted, not detection after the fact.
Why self-hosted with your KMS is structurally different
The architectural choice between managed and self-hosted evidence layers is often framed as an operational question: who runs the cluster. The KMS lens reframes it as a security question: who controls the keys. In a managed evidence service, the vendor's KMS signs records on your behalf. The vendor cannot read the records, but the vendor's compromise is your compromise. In a self-hosted deployment, the keys live in your KMS — AWS KMS in your account, Azure Key Vault in your tenant, HashiCorp Vault in your cluster, or an HSM in your data center. A vendor compromise is not your compromise.
This is not an abstract preference. For workloads regulated under HIPAA, PCI-DSS, FedRAMP, or any framework that defines key custody as a control objective, the question of whose KMS is the answer to a compliance requirement, not a deployment preference. The self-hosted SKU exists because the audit answer of "my keys are in my KMS" is materially different from "my vendor's KMS signs records on my behalf."
How Certyo integrates with the KMS you already run
The operational reality is that most regulated organizations already have a KMS strategy and do not want a new one. Certyo is designed to integrate with the standard options rather than introduce its own. The integration points are well-defined regardless of which KMS the organization runs:
AWS KMS, Azure Key Vault, GCP Cloud KMS, and HashiCorp Vault are all supported via standard signing APIs. HSM-backed keys are supported via PKCS#11 for environments that require physical key custody. The integration is configurable per-tenant, so different workloads inside the same Certyo deployment can use different signing strategies — a routine workflow can use software-backed keys while a high-stakes workflow uses HSM-backed keys, and the chain anchors both indistinguishably.
Three workloads where KMS choice is decisive
KMS choice matters more for some workloads than others. The pattern is consistent: the higher the assurance requirement on authenticity, the more the KMS dominates the security analysis:
- Healthcare clinical records — When a clinical record is later disputed — was the allergy noted before the prescription, or backdated after the adverse event — the question is who authored it and whether the authoring identity can be impersonated. HSM-backed keys with hardware-attested provenance are the cleanest defense. The chain anchor proves the record existed at the timestamp; the HSM-signed signature proves the identity.
- High-stakes financial transactions — Wire transfers, settlement events, and dispute-prone payment records benefit from segregation-of-duty enforced at the key layer. Two-key signing with separate custody chains makes insider compromise materially harder. The chain anchors the result; the multi-key signing schema is what makes the result trustworthy.
- Defense and classified operations — Workloads that cannot accept any vendor in the key custody path require fully air-gapped HSMs with no remote management interfaces. Self-hosted Certyo with an on-prem HSM is one of the few evidence-layer architectures that supports this posture. The keys never leave hardware controlled by the operating organization; the chain anchor is the only artifact that crosses the boundary.
How to evaluate a vendor on KMS strategy
When reviewing any evidence-layer vendor, the right questions are not about the chain. They are about the keys. Where do signing keys live by default? Can the vendor be required to use the buyer's KMS instead? Is HSM custody available, and via which standard? What happens to anchored records if a key is compromised — can specific records be marked-revoked without invalidating the rest? A vendor that answers these questions clearly understands what their evidence layer actually is. A vendor that pivots back to chain selection is selling a witness without an author. For the deployment topologies that preserve KMS sovereignty, see /en/about. For the records-on-chain misconception, see /en/blog/records-not-on-blockchain. For concentration risk in the chain layer, see /en/blog/evidence-layer-concentration-risk.
The chain is a witness; the KMS is the author. If the author is compromised, the witness still tells a faithful story — and the story is wrong. Evidence-layer security lives in the KMS, not in the chain.