Security

Built for the people who secure everything else.

ShadowLatch holds sensitive records about your network. Here's how access to them is controlled and how they're protected.

Design philosophy

Never less secure or private than before.

ShadowLatch only ever keeps a device's security and privacy where they were, or makes them better. When the safe way isn't available, the answer is to stop, never to fall back to something weaker.

Your DNS stays yours. The built-in resolver keeps the DNS servers each device already uses and adds encryption where those servers support it.
No switching behind your back. ShadowLatch never moves a device to a different DNS provider on its own; a provider is used only when you choose it.
Encryption is never taken away. A browser's own encrypted DNS is turned off only when that costs nothing: ShadowLatch then sends the browser's lookups to the same encrypted provider.
Leaving is clean. Uninstalling undoes everything ShadowLatch changed on the device: DNS settings, firewall rules and network settings go back to how they were.
Your names stay yours. Program, site, user and device names are encrypted on the device so only your team's console can read them. We can't.

The same rule decides what we build next. When devices can switch between DNS providers, they will only ever move to an equally or more secure one; if every secure option fails, lookups stop, just as they would without ShadowLatch.

Zero access

Can ShadowLatch decrypt your data? No.

Not for support, not from a backup, not for a court order. The design makes it impossible rather than merely against the rules.

What our servers hold

Encrypted names, users, paths, destinations and policy targets, sealed on your devices and in your browsers before they are sent.
Your account key, wrapped to each administrator's own key. A wrapped key is ciphertext to us.
For a second-factor key: a random share and the sealed private half. The share is one of two inputs; the other is derived from a password we only ever see as a one-way hash.
Metadata: addresses, ports, times, counts and bytes, which the console needs to work while names are locked.

What they never hold

Your password, or anything derived from it. Sign-in sends a one-way hash; the half of a key that comes from your password is computed in your browser and stays there.
A passkey, Windows Hello or security-key private key. Those live in the device's security chip or passkey store and only ever sign a challenge; they never leave.
Your passphrase. It derives a key in the browser; the server stores only the salt and the ciphertext.
The account key in the clear, at any moment, on any machine of ours. Unwrapped, it exists only inside an unlocked administrator's browser.

What that means in practice: support cannot read your data. If every administrator loses every key, the ways back are another key holder approving them or the recovery kit you saved at setup; the owner's "Reset protected data" destroys the sealed data rather than revealing it. A full copy of our databases and binaries shows metadata only. The one thing our servers can do is refuse to release a share or a wrapped key, which locks you out of that path until you use another key or the kit. That is a lock, not a read.

The threat model, situation by situation

Roles and user control

Owner, admin, analyst and viewer roles decide who can see records and who can change policies. Owners can invite, lock, sign out or remove any user, and removed users lose access immediately. Companies give a client's administrator a login that sees only their devices.

MFA and passkeys

Sign in with an authenticator app or a passkey. Owners can require MFA for every administrator, and sensitive actions such as changing roles, encryption keys or intruder blocking ask you to confirm it's you again.

Audit log

Changes to policies, devices, users and settings are recorded with who made them and when, so you can answer "who changed this?" without guessing.

End-to-end encryption

Paths, user names, hostnames, command lines, device and group names and other identifying fields are encrypted on the device and decrypted only in your administrators' browsers. ShadowLatch holds no key that can open them: nobody here can read that content unless one of your administrators unlocks it.

Names stay yours

Each device resolves its own names through the agent, so browsers stay on the system resolver and every connection keeps its name. Public names can go to Cloudflare, Quad9 or Google over encrypted DNS while internal names never leave your network; other encrypted-DNS services can be refused so nothing leaves unseen.

Devices defend themselves

Any managed device that sees repeated failed logons or a port sweep blocks the address on the device within seconds, without waiting for the cloud. Blocks are temporary and escalate; your own addresses are never blocked; every device in the account learns from each block.

An agent built for the job

Purpose-built for Windows, it sees every connection the moment it opens, ties it to the process and user behind it, and enforces your policies on the device itself, online or off. It answers only to ShadowLatch, over HTTPS, with a token you create.

Encrypted in transit

Every connection between devices, browsers and ShadowLatch uses HTTPS. Payment details are handled by our payment provider and never touch our servers.

End-to-end encryption

Only your team holds the keys. You choose how tightly.

Your organization gets its own encryption key. It never sits on our servers in readable form: each administrator holds a wrapped copy that only they can open, and nobody at ShadowLatch can read the identifying content of your traffic until one of your administrators unlocks it. There's no master key, so we can't read your data, and we can't be made to.

How administrators unlock is your call. There are three protection levels, the same three described on the Data & controls page and in the threat model. A password alone never opens the data at any of them.

Second factor (default). Any passkey the administrator holds (Windows Hello, a phone, a passkey synced through Apple, Google or a password manager, a security key), or their sign-in password after signing in with their authenticator code or passkey. One MFA, asked at sign-in, is the same second factor that opens protected data; a stolen password alone opens nothing.
Hardware-bound (strongest). Only device-bound passkeys on approved computers. The key lives in that computer's security chip; a stolen password or session can't open it, and neither can a phone.
Passphrase. Everything above, plus a passphrase of at least 14 characters with a special character, typed in the browser. Works anywhere with nothing to set up; a guessed or phished passphrase would open your data, which makes it the least protected level we offer.

Whatever you choose, you save a recovery kit at setup, a second administrator can approve a replacement, and the owner can tighten the level later. Devices share one set of pseudonyms, so a search reaches encrypted names across the whole fleet once you unlock, and when nobody can unlock any more the owner can reset protected data and start again.

What's encrypted and what isn't Read the threat model: what an attacker gets in each situation

On the deviceThe agent encrypts sensitive fields before upload.
On our serversEncrypted data is stored and moved, never opened.
In your browserAn administrator unlocks it for display, the way you chose.

Status: live for every account. Agents from version 2.0.13 encrypt on the device, the service refuses unencrypted uploads, and no server-held key remains. Since then: one set of pseudonyms across devices, search that reaches encrypted names after you unlock, a protected-data reset for when nobody can unlock, and since September 30, 2026 the names administrators type (devices, groups, companies, policy groups, notes and audit comments) sealed to your key as well. Since October 1, 2026 the second factor you sign in with is the one that opens protected data, so there is no second authenticator to set up; see details.

Report a security issue

If you think you've found a vulnerability, email support@shadowlatch.com with "Security report" in the subject. We'll acknowledge it and keep you updated. Please don't test against accounts that aren't yours.

Questions from your security team?

We're happy to walk through how ShadowLatch fits your requirements.

Request beta access Email support@shadowlatch.com