Security and privacy
Your secrets are encrypted where you are, not where we are.
Passwords, sign-in keys, vault items, and server credentials are encrypted in your browser or on your endpoint before they reach us. The platform stores and moves ciphertext, so the vendor running it is not a party that can read them. Lavawall® is built and run by ThreeShield, a Calgary audit firm.
The principle
Most platforms encrypt your data on their servers, which means the vendor still holds the key. Lavawall is built the other way for the things that matter most. The secret is encrypted where you are, and only the party that needs it, you, your endpoint, or your server, holds what opens it. An administrator with full access to our database, logs, and disks reads ciphertext.
That is not one feature. It runs through the password vault, the server secret manager, the way credentials reach an endpoint, and the way we handle your account password and your sign-in keys. Here is each one, in plain terms.
Where each secret is protected
Your account password
The console never receives your password. Your browser proves it and sends only a verifier, and we store a hash of that. The password itself never crosses the network.
Your sign-in keys
Passkeys and security keys keep their private half on the device. You can require a FIPS 140-3 validated key, the YubiKey 5 FIPS Series (CMVP #5291), checked at registration and every login.
The password vault
Every item is encrypted in your browser, down to the website addresses and the folder names. We store ciphertext. See the password manager.
Server credentials
The server secret manager lets a Linux or Windows server pull the credential it needs, unwrapped on that server, never on our platform.
Secrets sent to an endpoint
When a secret has to reach a device, it is sealed in your browser and opened only on that device. This is how WireGuard deployment handles the keys it sets up.
Remote sessions
A remote desktop session is protected in transit by a FIPS 140-3 validated cryptographic module, CMVP #5247. See remote support.
The server secret manager
Every automation needs a credential somewhere: a database password, an API key, a service account. Too often they end up in the clear, hard-coded in a script, sitting in an environment variable, or pasted into a config file. Lavawall’s server secret manager lets a Linux or Windows server pull exactly the secret it needs from the vault, with no one at the keyboard and nothing left lying around.
The server is enrolled as a member of the vault and holds its own key, so the secret is unwrapped on the server that needs it, never on our platform. Rotate a credential once in the console, and every server that uses it picks up the change. Your scripts reach it from Go, PHP, or bash over a local socket, and you decide whether the plaintext is cached for a few seconds or not at all, per company, per server, or per secret.
How this works
The server is a vault member with its own ECDH P-256 key, and the collection key is sealed to its public half, so the platform stores and moves ciphertext. Host key custody prefers a TPM 2.0, then a systemd credential, then a locked file. The Linux client is built on the Go Cryptographic Module, FIPS 140-3, CMVP #5247. Retrieval and refusal are written to the audit trail.
Validated modules, and approved algorithms
There is a real difference between using FIPS-approved algorithms and running through a module that NIST has validated and given a certificate number. We keep the two straight, and we name the validated modules.
| Where it applies | Module or algorithms | Standard |
|---|---|---|
| Agents, relay, and the server secret client | Go Cryptographic Module v1.0.0, CMVP certificate #5247 | FIPS 140-3 validated module |
| FIPS-grade sign-in keys | YubiKey 5 FIPS Series, CMVP certificate #5291 | FIPS 140-3 validated module |
| In-browser encryption: vault, secret sealing, password derivation | AES-256-GCM, ECDH P-256, HKDF-SHA-256, PBKDF2-HMAC-SHA-256 | FIPS 140-3 approved algorithms |
For how this maps to CJIS, HIPAA, PCI DSS, and NIST 800-171, see FIPS 140-3 support.
What we deliberately do not do
Some conveniences other platforms ship are only possible because the vendor can read something it should not. We left them out, and that is the point.
We do not scan the passwords in your vault on our servers. Health checks run in your browser, against your own vault.
No administrator has a button to open a user’s vault item or read a server’s secret. There is nothing to build, because the platform holds no key.
We do not keep a plaintext index of the sites you hold credentials for. Matching happens on your device.
Data residency and accountability
Your data and its AI processing run in Canada by default, on AWS in Montréal and Calgary. United States residency is available on AWS in Oregon, with AWS GovCloud and Microsoft GCC High for public-sector and regulated workloads, and other regions on request. See data residency.
Sensitive actions across the platform are written to a tamper-evident audit trail, so “who did this, and when” has an answer an assessor accepts. The compliance record lands in the same console through the GRC module.
Frequently asked
- Can Lavawall staff read my passwords, vault items, or server credentials?
- No. Those secrets are encrypted where you are, in your browser or on your endpoint, before they reach us, so the platform stores and moves ciphertext. The vendor running the platform is not a party that can read them.
- Does Lavawall use FIPS 140-3 cryptography?
- The agents, the relay, and the server secret client run on the Go Cryptographic Module, NIST CMVP certificate #5247 (FIPS 140-3), and sign-in can be required on a FIPS 140-3 validated key, the YubiKey 5 FIPS Series, certificate #5291. In-browser encryption uses the FIPS 140-3 approved set of algorithms. See FIPS 140-3 support for how each piece fits.
- Where does my data live?
- In Canada by default, on AWS in Montréal and Calgary. United States residency on AWS in Oregon, with AWS GovCloud and Microsoft GCC High for public-sector and regulated workloads, and other regions on request. See data residency for the detail.
- Who built Lavawall?
- ThreeShield Information Security Corporation, a Calgary audit firm with CISSP- and CISA-credentialled staff. The security controls an assessor asks for are the defaults, because the people who built the platform sit on the assessor’s side of the table.