This page describes the architecture's resilience posture. Several mechanisms are still in active development; the design is locked and the threats are real. If you want the implementation status by item, reach out — we'll share the current progress under NDA.
Infrastructure
Engineered to keep working when something doesn't.
Every part of Clavitor's infrastructure was designed by asking the same question for each dependency, each vendor, each layer: what happens when this fails? We worked through that question across the entire stack and engineered the architecture so the answer is always the same one: the vault keeps serving.
This page lists what we thought about. The specific mechanisms — how we solve each one — stay private; sophisticated customers can receive that detail under NDA. Publishing the threat list is honesty about the engineering. Publishing the defences is a free diagram for adversaries.
What we engineered for
Hyperscale cloud outages
The major cloud providers go down. Not often, but visibly, and when they do they take large parts of the internet with them. We designed on the assumption that any single hyperscaler will eventually have a globally bad day. Clavitor continues to serve credentials when that happens.
Regional disasters and kinetic events
A regional event — a drone strike on a data centre, an undersea cable cut, a natural disaster, a regional war — can take an entire cloud region offline. On March 1, 2026, both AWS Middle East regions went dark in the same incident. We took that as a lesson, not a hypothetical. The architecture treats a regional event as a routine failure mode that customers don't notice.
DNS provider outages
If the company that hosts your DNS goes down, your service goes dark even if every other part of your stack is healthy. This is true for Cloudflare, Route 53, every major DNS provider. We considered what happens when our DNS provider has a bad day.
Certificate authority outages
If your certificate authority is unreachable when your cert needs to renew, your TLS goes dark. If a certificate authority is compromised, every cert it issued goes invalid. We considered what happens to TLS when the CA infrastructure misbehaves.
Domain registrar issues
If your registrar suspends your account or gets compromised, your domain disappears or gets redirected regardless of where DNS is hosted. We considered what happens if our registrar fails.
TLD operator issues
The organisation that runs a top-level domain (.com, .ai, .io) is itself a single point of failure. Smaller TLDs are operated by smaller organisations with less operational depth. We considered what happens if a TLD operator has a bad week.
Email provider outages
If your email provider is down, account-recovery codes don't arrive, signup confirmations don't arrive, the customer-support inbox is dark. We considered what happens to authentication and recovery when our email provider is unreachable — and crucially, what happens to the rest of the product while email is down.
SMS / phone-number dependence
Many services fall back to SMS for verification when email is down. We considered this and decided not to. Asking for a phone number adds a category of personal data that we don't want to collect, exposes customers to SIM-swap attacks, and adds another vendor dependency. We chose a better path.
Operational control-plane outages
The tools we use to manage our own infrastructure can themselves go down: the orchestration mesh, the coordination layer, the deployment pipeline. Each is a vendor relationship that can fail. We considered the consequences of each and progressively reduced our dependence on vendor-operated control planes.
Software bugs
The single most likely cause of a uniform outage is a bug in our own software, deployed everywhere at once. No amount of geographic distribution helps when every running copy crashes the same way. We considered this and engineered our deployment practices — canary rollouts, fast rollback, kill switches — accordingly.
Account-level vendor actions
Account suspension, billing disputes, regulatory holds, and ToS enforcement can disable any single vendor relationship in one stroke. We considered the consequences of every critical vendor relationship being unilaterally terminated, and designed against single-vendor lock-in at every layer.
Correlated failures
Some events take down multiple things at once — a major cable cut affecting several routes, a coordinated attack across services, a natural disaster that hits both a primary and what was supposed to be its backup. We considered correlated failure modes specifically: the failure of "the backup" right when the primary is also down. The architecture is designed so that no single event takes down both a primary and its fail-over.
Catastrophic personal-data dependencies
Vault customers shouldn't have to choose between security and the recoverability of their own data. We considered every place where the user's vault depends on something else they could lose: their phone number, their email account, a single device, a single password. Each of those was either eliminated or engineered around.
Operational team reachability
A vault company needs to be reachable by its own team during an incident. We considered what happens to our ability to respond when the internet around our own operators degrades.
Cryptographic horizon
Cryptography is not static. We considered the long-term migration path for every cryptographic primitive we depend on, including post-quantum.
What we don't claim to protect against
We're explicit about the limits of what infrastructure engineering can achieve.
Would take down the global internet for days. Nothing infrastructure can do helps; customers can't reach anything anyway.
A class of event no commercial infrastructure can defend against unilaterally.
We're honest about these — and we design everything else to be resilient on the assumption that they won't happen.
Architecture detail under NDA.
The list above is what we considered. The detail of how each defence is engineered — the specific topology, the vendor choices, the cutover procedures, the cryptographic protocols — is shared with enterprise customers under NDA, with their security teams, in their procurement process.