Security
The threat model, in plain words.
What ShadowLatch can and cannot see, what an attacker gets in each bad situation, and what your choices change.
Written for the person who has to sign off on us. It describes the product as built; when the design changes, this page changes with it.
Who can read what
Your administrators can. We can't.
Every identifying field a device records (application paths and names, command lines, Windows user names, hostnames and DNS names, local addresses, free text) is encrypted on the device to your organization's key before upload. The names your administrators type (devices, groups, companies, policy groups, notes, audit comments) are sealed to the same key in the browser before they're sent. The private half of that key exists only in your administrators' browsers and in the recovery kit you saved. ShadowLatch's servers store and move ciphertext and never hold a key that opens it.
| Party | Sees |
|---|---|
| Your administrator, unlocked | Everything, in the console, on the computer where they unlocked. |
| Your administrator, not unlocked (or on another computer) | Metadata only; names show as "Protected". |
| ShadowLatch staff, our servers, our backups, anyone who takes them | Metadata only (the list below). No key material that opens customer data exists on our side. |
| Someone with one of your devices' local database | That device's own records and pseudonym dictionary. Not other devices' values, and not the account key. |
If something goes wrong
What an attacker gets, situation by situation.
| Situation | Outcome |
|---|---|
| An administrator's password is phished | Sign-in still needs MFA. Even with MFA, the attacker gets a session, not the key: at the hardware-bound level the key needs the passkey on the registered device. At the second-factor level the attacker also needs a passkey or the authenticator code. At the passphrase level a phished passphrase as well would open the data; a password alone never does. |
| A session token is stolen (malware, a leaked browser profile) | Metadata until the session ends. The key is never in the token. If the administrator chose "stay unlocked on this device" on that same browser profile, the profile also holds the unlock secret, so the data is exposed on that computer until they lock or the profile is revoked. |
| An administrator's computer is stolen | The workstation key lives in the computer's security chip behind Windows Hello (hardware-bound level) or in the platform's passkey store. Revoke it from another workstation; then rotate the account key so nothing the thief could later obtain still opens new data. Old data they already had access to was never on the disk in readable form. |
| An administrator leaves the company | The owner revokes their workstation keys and rotates the account key. Devices switch to the new key on their next sync; older data stays readable to the remaining administrators. |
| Our servers or backups are fully compromised | Metadata is exposed; identifying content is not. The attacker also cannot push a substitute key to your devices: devices accept a new key only through a rotation record signed by the key they already trust. |
| A legal demand reaches ShadowLatch | We can produce what we hold: ciphertext and metadata. We cannot produce plaintext because we cannot create it, and we cannot be made to. |
| Every workstation and the recovery kit are lost | The data is unrecoverable, by you or by us. This is the price of the guarantee above; treat the recovery kit like a master password. |
| A device itself is compromised | The agent on that device sees its own activity by necessity, so an attacker with administrator rights on that device sees what that device sees. Other devices and the console are unaffected. |
Protection levels
You decide how strict.
The account owner picks how administrators unlock. The level is a floor: a looser level keeps the stronger methods available, and existing keys keep working when it changes. Two rules hold at every level: keys belong to an administrator's account, never to a computer, so two administrators on the same PC each need their own key and their own one-time approval; and an administrator may register several devices (desktop, laptop, phone), each approved once and revocable alone, while any device they have not registered shows names as protected.
- Second factor (default, recommended)
- The administrator's sign-in password derives one half of the unlock key in the browser (PBKDF2-SHA256, 600,000 rounds, per-key salt); the other half is a random share the service holds and releases only to a sign-in session that proved its second factor recently (the authenticator code or passkey used to sign in, or a later confirmation), for a window the owner sets (12 hours by default). Neither half opens anything alone: the service never has the password half, a stolen browser profile has no share, and a database copy is useless without the password. Works from any browser with nothing to register.
- Hardware-bound (strongest)
- Device-bound passkeys only (Windows Hello, Touch ID) on registered computers. The key lives in that computer's security chip and cannot leave it; a stolen password or session cannot open it. Synced passkeys and phones are excluded.
- Passphrase
- A long passphrase typed in the browser derives the unlock key (PBKDF2-SHA256, 600,000 rounds, per-key salt; the server stores only ciphertext and the salt). Works anywhere with nothing to set up. A guessed or phished passphrase opens the data, and the ciphertext could be attacked offline by whoever obtains it, which is why unlock is rate-limited and needs a recent MFA check.
What stays readable
The metadata we keep, and why.
Remote IP address, port and protocol; allowed, blocked or would-block; bytes sent and received; timestamps; device and account identifiers; agent version and health counters; the pseudonyms themselves (one set per account, non-reversible without your key); your account's email, name and billing details; and what each policy targets (the site, address or application typed into it), because the service compiles and signs the policies it sends to your devices. These let the service draw the Flow map, spot new destinations for Review, look up owners and locations of remote addresses, and account for traffic. Remote addresses do reveal who each device talks to. Accounts that need more can turn on Maximum privacy: devices encrypt remote addresses as well, the service keeps only a placeholder, and administrators still see the real addresses after unlocking. The cost, stated in the switch: Review stops flagging new destinations, the Flow map collapses destinations, and location lookups are off.
What this doesn't cover
Honest limits.
Encryption doesn't protect a device from itself: the agent must see local activity to enforce policy. Metadata can still be sensitive (a device that talks to a particular address at particular times says something). Your browser is trusted while unlocked, so a compromised browser on an unlocked workstation reads what the administrator reads. And a bug in our client-side code could weaken these guarantees; we mitigate that with tests that fail the build when a new field would leave a device unencrypted. We'll publish the result of an independent review when one has been done.
Cryptography
Standard pieces, no invention.
P-256 ECDH for key agreement, HKDF-SHA256 for key derivation, AES-256-GCM for encryption with the context bound as associated data; ECDSA P-256 for rotation records; WebAuthn passkeys with the PRF extension for workstation keys; PBKDF2-SHA256 for passphrase keys; HMAC-SHA256 for per-device pseudonyms. All of it is standard browser WebCrypto and audited Rust crates. The as-built design document is available to customers and reviewers on request.
How to check us
Don't take our word for it.
Ask for the as-built design document and the source of the browser key code. Point a security reviewer at the product and have them try to make the server read a name. Report anything you find to support@shadowlatch.com. What's encrypted and what isn't lists the fields; Security covers accounts, roles and audit.