AWS shut QLDB down on July 31, 2025. Most coverage framed it as a migration problem — what to use instead, how to move data out, who got caught. The more uncomfortable lesson is structural. An evidence layer is not the same kind of dependency as a database or a cache. When your evidence layer's vendor goes dark, you lose more than a service: you lose the ability to defend records you have already produced. This post is for security and audit leaders who are building multi-year evidence strategies and need to think about vendor risk in the evidence layer itself.
Why evidence layers are different from other dependencies
If your application database goes away, you restore from backup and keep going. If your cache goes away, you take a brief performance hit. If your CI runner goes away, you re-run pipelines on a new one. None of these failures call into question records you have already produced or claims you have already made.
An evidence layer is different. Its job is to make a defensible statement about something that happened in the past. If the vendor disappears, the statement disappears with them — not because the records are gone, but because the cryptographic chain of trust is no longer reachable. You can show the auditor a record. You cannot show the auditor a way to verify it. That asymmetry is the structural problem.
What concentration risk looks like in this category
There are three concrete failure modes that compound when the evidence layer lives inside a single hyperscaler:
- Vendor sunset — the service is discontinued. AWS QLDB on July 31, 2025 is the canonical example. Your past proofs are technically still computable for a migration window, but the verification API is going away. Anything you anchored is now a self-signed claim, not a third-party-verifiable one.
- Vendor restriction — sanctions, export controls, or contractual disputes restrict your access. The evidence layer is still operational for someone else; for you, it has the same effect as a sunset. This is not hypothetical for cross-border financial operations.
- Vendor account compromise — your hyperscaler tenant is locked or breached. The audit log of the evidence layer is co-located with the rest of your account. You cannot use the evidence layer to disprove tampering of itself.
What survives a vendor going dark
The architectural property that matters here is whether the verification path requires the original vendor to be alive. With QLDB and Azure Confidential Ledger, it does. With public-chain anchoring, it does not. The Polygon mainnet contract that records a Merkle root is not owned by Certyo. If Certyo disappears tomorrow, the on-chain anchors persist, the verification math is unchanged, and any third party with the original record can still prove it was anchored at the original timestamp.
This is not a claim about Certyo's longevity. It is a claim about the design constraint. An evidence layer that can be shut down by its own vendor is structurally a worse evidence layer than one that cannot — independent of how good the vendor is. The audit function deserves a dependency that survives a single corporate decision.
How to assess your current evidence-layer concentration risk
If you are running an audit-trail or compliance evidence service today, the concentration question is answered by walking through five checkpoints. At each one, the question is the same: what happens to past proofs if this dependency goes away?
If your current architecture loses verifiability at any of the first four checkpoints, you have concentration risk. If verification only works while the vendor is alive and you have an account in good standing, the evidence is contingent on continued vendor relationship — which is not the same as durable evidence. The fifth checkpoint is the real bar: can a regulator, opposing counsel, or insurance adjuster verify your claim without your help and without the vendor's cooperation?
Three buyer profiles where this matters most
Concentration risk is not equally important to every team. It compounds in specific institutional contexts:
- Regulated multi-decade retention — Healthcare, government, and certain financial records have retention windows of 7 to 30 years. The probability that any single vendor remains operational and accessible for that horizon is not 100 percent. A multi-decade evidence strategy that depends on a single vendor is a strategy with a known weak point.
- Cross-border operations — Sanctions, data-residency law, and trade restrictions can change the access posture for a hyperscaler-hosted service overnight. Evidence that was verifiable yesterday may require legal action to verify today. Public-chain anchoring is not subject to this class of disruption.
- Litigation and insurance — When a record is disputed, the question is whether a third party — court, regulator, adjuster — can verify it independently. If verification requires cooperation from a specific vendor, the dispute has an extra dependency that opposing counsel will exploit. Independent verifiability is the bar.
What this means for evidence-layer architecture decisions
The QLDB shutdown is best read as a single instance of a class of risk that is intrinsic to vendor-hosted evidence layers. The strategic response is not to pick a vendor that is unlikely to be sunset. It is to pick an architecture where verification does not depend on any single vendor being alive. Certyo's anchors live on Polygon; the verification path does not require Certyo to operate the chain. That decoupling is the whole point. For the deployment topologies that preserve this guarantee, see /en/about. For the verification primitive in detail, see /en/blog/blockchain-without-crypto.
An evidence layer that can be shut down by its own vendor is structurally a worse evidence layer than one that cannot. The audit function deserves a dependency that survives a single corporate decision.