Why we cannot read your panel codes

You hold the keys to buildings you do not own.

Reader controllers. Camera estates. Intruder panels. Licence platforms. A security or fire contractor of any size is carrying credentials for dozens of premises belonging to other people, and every one of those clients is trusting you with something they would struggle to replace.

So when we built the Vault, there was one question worth getting right.

Who holds the key

Every credential store answers this, whether or not it says so out loud.

Most answer: the vendor does. Your data is encrypted, the vendor holds the key, and the vendor decrypts it for you on request. It is simple, it supports every convenience feature anyone asks for, and it sounds fine right up until you say it plainly — the company hosting your clients’ door controller passwords can read your clients’ door controller passwords.

A key the vendor holds is a key the vendor can lose. It is also a key the vendor can be compelled to produce, and one that a single misconfigured environment variable exposes for every customer at once.

We answered it the other way. You hold the key. We hold nothing that can open it.

How it works

Your passphrase never leaves your device. It derives your key locally using Argon2id at 64 MiB of memory, three time iterations and parallelism of one. Argon2id is memory-hard by design, which is the property that matters: GPU farms can parallelise raw hashing almost for free, but they cannot cheaply parallelise something that demands 64 MiB per guess.

Where the WebAssembly module is not available on an older device, it falls back to PBKDF2-HMAC-SHA256 at exactly 600,000 iterations. The algorithm used is recorded against your keypair, so the right one is always applied when you unlock.

Those are numbers most password managers will not publish. We are publishing both.

Your PIN is a second factor, and it works differently. It is verified on our servers, because that is what lets us enforce a lockout after repeated failed attempts. Only a bcrypt hash of it is stored — never the PIN itself. Your passphrase, by contrast, never reaches us in any form at all.

Every entry has its own key. Each credential is encrypted with a unique key of its own, using AES-256-GCM with a fresh nonce and an authentication tag verified on every read. Tampered data fails loudly rather than returning something plausible and wrong.

Sharing means wrapping, not telling. When you give an engineer access, that entry’s key is wrapped for their identity — in your browser, on your device. They can open that entry. They learn nothing about you, and nothing about any entry you have not shared. Revoke it and the wrapping is destroyed.

What reaches us is ciphertext. Encrypted values and wrapped keys. Nothing else. There is no master key, no per-organisation key, and no support tool that turns any of it back into a password.

The recovery problem

The obvious objection is the practical one. If you cannot read it, what happens when somebody forgets their passphrase?

Most vendors solve this by quietly keeping a copy of the key — and that single decision undoes everything above it.

So the recovery key belongs to your organisation, not to us. Your owner generates it in their own browser and protects it with a passphrase they set. Every entry is additionally wrapped for that key. When somebody forgets their passphrase, an administrator unlocks the recovery key on their own device and re-wraps that member’s entries back to them — restoring access without Graftix being involved at any point in the chain.

If your organisation loses the recovery passphrase as well, the entries are gone. We are saying that plainly because it is the direct consequence of the guarantee. Anyone promising both zero knowledge and unconditional recovery is misleading you about one of them.

Who opened what, and when

Fourteen actions are recorded: creating, revealing, rotating and deleting an entry, granting and revoking access, every PIN and passphrase change, and every use of the organisation recovery key. Who, what, and when. Metadata only — we never log values, because we could not log them if we wanted to.

The log cannot be edited, including by us. Append-only is enforced by the database itself rather than by our application code. A trigger rejects any attempt to update or delete an audit row outright, and it is reapplied to both regional databases every time the server starts, so it cannot quietly drift out of place.

On top of that, a monthly job seals the log into a SHA-256 hash chain. Removing or altering a historical row breaks that chain, and a verification pass detects it.

That distinction matters more than it sounds. An audit log an administrator can quietly edit is evidence of good intent. One the database itself refuses to alter, and that would visibly break if it had been, is a control.

When a client asks who accessed their credentials, you answer with a record instead of a recollection — and the record can be trusted precisely because nobody, at any level, could have tidied it up first.

Why this matters for your trade

Nobody in construction carries more of other people’s secrets than fire and security contractors, and nobody gets asked about it more directly.

When a client asks how their credentials are protected, “our software provider encrypts them” is a hope. “They are encrypted before they reach our provider, and our provider cannot read them” is a control — and it is the kind of answer that ends the conversation rather than starting a longer one.

How the Vault works · Security at Graftix