Security and data handling
Written for the person who has to approve this. Latch is a desktop product with no server behind it, and the design choices below are deliberate rather than incidental.
There is no Latch service to breach
Latch is a Windows application. We operate no backend, no API and no database that holds your data. Your files, their names and their contents are never transmitted to Captivated Ltd, because there is nowhere for them to be transmitted to. Latch talks only to Microsoft Graph and SharePoint, from the user's own machine, as the user.
Delegated authentication only
Latch signs in as the person using it, through the Microsoft-supplied broker (WAM). Practically, that means:
- Latch cannot reach anything the signed-in user could not already reach. It inherits their permissions exactly, and nothing more.
- Every check-out and check-in is attributable to a real person in your audit log — never to a service identity.
- Your Conditional Access, MFA and device-compliance policies apply unchanged, because the broker is the same one your other Microsoft applications use.
We do not ask for application permissions
Latch requests no Application-level (app-only) permissions, and holds no client secret or certificate for your tenant. This is a decision we have committed to rather than a stage we have not reached yet.
App-only access would mean a credential capable of reading and writing every file in your tenant, sitting either on every endpoint or in a service we run. It would also allow unattended release of a lock — which in this product is a destructive act, because discarding a check-out can discard work that has already reached the server. Releasing someone else's lock should involve a human who can find out whether that work mattered. Your SharePoint administrators can already do exactly that, with their own credentials and your existing audit trail.
Credentials stay in the user's session
Latch has two parts: an elevated Windows service that detects editing activity, and a per-user agent that performs the SharePoint operations.
| Elevated service | Sees file activity for every signed-in user. Holds no credentials at all — it cannot authenticate to anything, by construction. |
|---|---|
| Per-user agent | Runs unelevated as one person. Holds only that person's token, in the Windows token cache, and performs all SharePoint calls. |
Tokens are managed by the Windows broker and never leave the machine. On multi-user systems — Azure Virtual Desktop, Citrix, Remote Desktop session hosts — this split is what stops one compromised process from holding every logged-on user's access at once. It also means one user can never see, or act on, another user's files through Latch.
Permissions we request, and how to narrow them
Files.ReadWrite.All | Delegated. Needed to check files out and in on the libraries the user syncs. |
|---|---|
Sites.ReadWrite.All | Delegated. Used to read library and check-out state that Microsoft Graph does not otherwise expose. |
For tenants that prefer a narrower grant, Latch can be configured against Sites.Selected, so it reaches only the specific sites you nominate. If that matters to you, tell us and we will document the exact configuration for your environment.
What stays on the machine
Latch keeps a small amount of local state: which libraries are synced, which applications you have approved for locking, and which files it currently believes are checked out. That last record exists so a lock is never silently forgotten after a crash or reboot. It is stored under ProgramData and restricted to SYSTEM and Administrators, because the file paths themselves can be sensitive.
Latch never moves, copies, uploads or modifies file content. The sync client owns the bytes; Latch only changes lock state on the server.
What we do not have yet
Latch is in development. We hold no SOC 2 report, ISO 27001 certificate or completed penetration test, and we would rather say so than let silence imply otherwise. If your procurement process needs any of those, talk to us about timing before you plan around it.
Reporting a vulnerability
Email security@filelatch.com with enough detail to reproduce the issue. We will acknowledge within five working days. Please give us a reasonable opportunity to fix an issue before disclosing it publicly; we will not pursue legal action against anyone acting in good faith under those terms.