Encryption & data protection

This page states, precisely, how Lockey protects data — what is encrypted, with what, and what we do not claim. It is written for the security questionnaire you have to fill in before integrating.

Read the exclusions

Every control below is followed by its limits. A statement of what a control does not cover is as load-bearing as the control itself — if we omitted those, this page would be marketing, not an attestation.

In transit

Property	Value
Protocol	TLS 1.2 minimum; TLS 1.3 preferred
Terminated at	The Cloudflare edge, in front of every Lockey surface
Scope	api.trylockey.com, app.trylockey.com, the partner and admin consoles, and every page-image fetch
Plaintext HTTP	Not served — requests are redirected to HTTPS

Every API call, every console session, and every watermarked page image travels over TLS. There is no unencrypted transport path into Lockey.

At rest

Lockey stores data in four Cloudflare services. All four are encrypted at rest with AES-256, using keys managed by Cloudflare:

Store	What lives there	Encryption
R2	Original uploaded files, rendered page images, cached watermarked composites	AES-256, Cloudflare-managed
D1	Metadata — accounts, documents, share links, grants, audit events	AES-256, Cloudflare-managed
KV	Short-lived cache: link-state snapshots, OTP records, rate-limit counters	AES-256, Cloudflare-managed
Queues	In-flight render jobs	AES-256, Cloudflare-managed

Encryption at rest is applied by the platform, transparently, to all objects and rows. It is not something a Lockey deployment can turn off.

What at-rest encryption does not do

Cloudflare-managed keys protect against physical and storage-layer compromise. They do not protect against a compromised application credential — anything holding a valid Lockey session or API key reads decrypted data by design. That threat is addressed by the access controls below, not by encryption.

We do not offer customer-managed keys or BYOK. If your procurement process requires you to hold the key material, Lockey does not meet that requirement today.

Application-layer protections

These are ours, not the platform's — the controls Lockey implements above what Cloudflare provides.

Credentials are never stored recoverably

Credential	Storage
Share-link passwords	PBKDF2-SHA-256, 100,000 iterations, 16-byte random salt per password. Verified in constant time.
Partner API keys	SHA-256 digest only. The plaintext key exists exactly once — in the creation response. We cannot show it to you again.
Phone / email OTP codes	Stored hashed, single-use, short TTL.

Password hashing uses PBKDF2 because it is the only password KDF available natively in the Workers runtime — bcrypt, scrypt, and Argon2 are not. The 100,000-iteration count balances the Worker CPU budget against offline-cracking cost, on what is already a secondary factor behind an unguessable link token.

Tokens are unguessable

• Share tokens — 16 random bytes (128 bits) from a CSPRNG, base64url-encoded to 22 characters. Unique-indexed in the database as the final guarantee.
• Partner API keys — a lk_live_ / lk_test_ prefix plus 32 alphanumeric characters (~190 bits).
• Page URLs — HMAC-SHA256 signed over (session, page, expiry), in a namespace that prevents a signature minted for one surface from authenticating another.

Signed URLs are transport auth, not authorization

A signed page URL expires with its viewing session. It is never a bypass: link state is re-checked live from the database on every page fetch, so a revoked or paused link stops serving images immediately, even to a URL whose signature is still valid.

The structural control

The strongest privacy property in Lockey is not cryptographic — it is that recipients and partners never receive the original file.

Documents are rendered to page images server-side. The per-session watermark and any masks are burned into the pixels before the image is served. Clean page images stay owner-private and are never sent to a recipient or a partner. There is no download path, for anyone but the owner.

This means a compromised partner integration leaks watermarked screenshots attributable to a specific session — not a portable, clean original.

Isolation

Lockey runs four separate identity planes that share no cookie namespace, no session store, and no user table:

1. Consumer — people who own documents (Google / Apple / phone OTP)
2. Partner members — humans in your org (password + TOTP, optional SSO)
3. Partner API keys — machine-to-machine
4. Admin staff — Lockey internal, invite-only

A credential from one plane cannot authenticate against another. Partner data is scoped by org on every query.

What we do not claim

Stated plainly, so you do not have to infer it:

• No SOC 2, ISO 27001, or HIPAA certification. Lockey has not been audited against these frameworks. Cloudflare's own certifications cover the underlying infrastructure, but they are Cloudflare's, not Lockey's — do not record them as ours.
• No data-residency guarantee. Data is stored on Cloudflare's global network. You cannot currently pin storage to a region or jurisdiction. If your regulator requires residency, raise it before integrating.
• No customer-managed encryption keys.
• No penetration-test report. An independent test has not been commissioned.
• Screenshots cannot be prevented on the web. Native apps set the OS screenshot flag; browsers expose no equivalent. The web viewer does disable the one-gesture copies — right-click "Save image as…", drag-out, long-press save, print-to-PDF — but that is friction, not enforcement: a page the browser has rendered is on the viewer's machine, and a screenshot or a phone camera defeats all of it. The watermark is the deterrent and attribution mechanism — it makes a leaked screenshot traceable to a session. It does not make one impossible. Design your process around that limit rather than assuming it away.

Reporting a vulnerability

Email security@trylockey.com with reproduction steps. Please do not open a public issue, and give us a reasonable window to remediate before disclosure.

Next: Data retention & deletion →