How we protect your reports

Your inspection reports: the findings, narratives and photo captions you write, and the report that ties them together. They’re encrypted on your device before they reach our servers, and we don’t hold the keys to decrypt them. Our servers only ever store the encrypted version.

Report PDFs are never stored. A PDF is generated on the reader’s own device from the decrypted report.

Photos are the exception. They are not end-to-end encrypted. Each photo is stored at a random, unguessable address under standard server-side encryption at rest. Our server knows which inspection a photo belongs to, and so which property. What you wrote about it, the finding and the caption, is in the encrypted report. A photo that shows a house number or a piece of mail also identifies itself.

Alongside each photo we store its size and type, its order, and which checklist item it belongs to. That last part means we can tell which checklist items have photos, a weak hint at which items were flagged. A photo’s caption is part of the encrypted report, not stored with the photo.

Your account details, schedule, client and agent directory, billing and automations are standard business data. They’re encrypted in transit and at rest, but readable to us, because we need them to run the service. So is the basic record of your work: who inspected which address on which day.

When you sign up you get a 12-word recovery phrase. It creates your vault’s keys on your device. The phrase is never sent to us, never stored on our servers, and never visible to us.

If you lose it, we can’t recover it. There’s no “forgot my phrase” reset, because a reset we controlled would be a back door.

On each of your devices, your keys are stored locked to a passkey: your fingerprint, face or screen lock. Inspectors always use a passkey, because their vault signs their reports. A client receiving reports can choose a device password instead. It never leaves their device, and a forgotten one is reset with their 12 words.

Every report you send is signed with a key that comes from your recovery phrase. The signature covers the encrypted report and a fingerprint (a hash) of every photo in it. Your client’s browser checks the signature, the report and every photo before it shows anything, and your browser checks the signature when you reopen a report you’ve sent. So our servers, or anyone who breaks into them, can’t forge a report, change one, or swap a photo without the browser refusing it.

Signing doesn’t stop everything. Whoever controls our servers could still withhold or delete a report or a photo, or show an older genuine version of a report and hide a newer one. A photo taken on a different device from the one that sends the report is signed as our server held it at the time of sending.

If you replace your recovery phrase, you’ll be asked why. A report signed with your old key opens again for a client, with a note, only if their browser recorded opening it before the change, or if you signed with your new key that the old phrase was lost rather than possibly seen by someone else. Otherwise your client is warned and chooses, report by report.

Reports go to your client’s account, not to a link. Your client has their own account and their own recovery phrase. Your browser encrypts the report’s key to your client’s registered key, and our server releases the delivery only to that signed-in client or to you. No link carries a key.

Your client’s browser remembers your signing key the first time it opens one of your reports. If a later report is signed with a different key, it holds that report back until your client accepts the new key.

Your client’s key comes from our server, so your browser doesn’t take it on trust. It shows you a fingerprint of the key, a 32-character code, and remembers which key you delivered to for each client.

The first time you send to a client, ask them to read you the fingerprint on their Your reports page. On that first delivery, that spoken check is the only thing that can tell whether the key really is your client’s. After that, if the key ever changes, Sign & Send stops until you press Use the new key, and it tells you not to do that before checking with your client. Your browser can’t tell whether that check happened. That part is up to you.

Your record of checked keys is encrypted under your own key and synced between your devices through our servers. A brand-new device relies on our servers returning those records. A device that already has them doesn’t.

How to do the fingerprint check

You can revoke a delivery, and our server stops serving it. Because our server enforces it, revoking controls your client’s access. It isn’t a protection against us. A copy your client has already opened stays readable to them.

A copy of our data doesn’t make your inspection content readable, because we never hold the keys that decrypt it. That covers a breach of our database or file storage, a backup, a subpoena, or the stored data a future acquirer inherits.

Someone who controls our servers from some point on, such as a hostile operator or acquirer, or someone with stolen credentials, is in a stronger position. They still can’t decrypt stored reports, or forge or alter one without the browser refusing it. But we also serve the web app you use. Whoever controls our servers can change the code that runs in your browser, and code running in the page while your vault is unlocked can read that vault’s keys and every report it opens, old or new. The cryptography doesn’t rule that out. It rests on who can change and deploy our code.

If we’re ever compelled to hand over data, we can only produce what we have: encrypted reports, operational data and metadata, and photo files. Reading your reports would mean going to you or your client, who hold the keys.

• No server-side search of report content. If we could search your reports, so could someone who breached us.
• No “forgot my phrase” reset. A reset we controlled would be a back door.
• No copy protection on opened reports. Once your client opens a report on their device, that copy is theirs.

As of October 13, 2026:

• Home Inspection Vault has no production deployment yet. An external cryptographic audit gates our production launch. We don’t consider the design final until a third-party security firm has reviewed and signed off on the building blocks, the protocol and the implementation.
• The server side of report signing runs on our staging environment, not yet in production. That covers storing each report’s signature, registering your signing key, and returning signed key-replacement records. The app won’t send a report until our server has confirmed your signing key, and won’t show a report that carries no signature. If our server returns no signed record for a replaced key, the app treats the replacement as unexplained, so your client is warned and chooses.
• Our encryption uses the audited @noble family of cryptography libraries, pinned to exact versions, and is checked against frozen test vectors automatically whenever the app’s code changes.

If a client’s fingerprint doesn’t match what they read you, or you think you’ve found a security problem, don’t send the report. Contact us instead.

For how we handle your account data, see our Privacy Policy.