TMSRoute

Security

Effective 13 October 2026

Where Data Lives

Logrinth runs its own database, file storage and sign-in service on a server it owns and operates in the United States. The server accepts no connection from the internet; traffic reaches it only through an encrypted Cloudflare tunnel. Cloudflare carries traffic, Stripe takes payment, and Google or Microsoft handles sign-in. Each product's privacy policy names anyone else it involves.

Separating Organisations

Every record belongs to an organisation. The database itself keeps each organisation to its own rows: every table that holds an organisation's records enforces row-level security, for its owner too, and every key carries the organisation, so no record can point at another's.

The database decides which organisation a request acts for. It verifies the signed session and the person's membership in every transaction, and the application cannot set the organisation itself. A file is read through a link that lasts two minutes and is issued only to a member.

Encryption

Every site is served only over HTTPS, and browsers are told to refuse anything else for two years. The server's disk is fully encrypted, backups are encrypted with AES-256, and contractor taxpayer numbers are encrypted under a key the database does not hold.

Sign-In and Sessions

You sign in with Google or Microsoft, or with a passkey once you have set one up. Logrinth never holds a password of yours. A sign-in started in one browser cannot be finished in another.

A session on a product lasts at most eight hours and ends after an hour without use; the Logrinth sign-in behind it lasts at most a day, also ending after an hour without use. Session cookies are sent only over HTTPS, only to the site that set them, and cannot be read by scripts. An organisation's owners and administrators decide who holds a seat and in what role.

Backups

The databases, file storage and keys are backed up every night. Each file is verified before it is kept, everything holding data or keys is encrypted, and the last fourteen sets are kept. Backups are held on the server itself; an off-site copy is not yet in place. A scripted restore rebuilds the whole system from one backup.

Scanning on Every Release

Before a release is built it is scanned for secrets written into the code, for breaches of the codebase's own security rules, for known vulnerabilities in the libraries it runs on, and for critical vulnerabilities with a fix in any service it runs. Any finding stops the release. After every deploy the live sites are scanned with the OWASP ZAP baseline, and a failure rolls the deploy back.

Incident Response

When an incident is suspected, the state of the system and its logs are preserved before anything is changed. It is contained with the smallest step that stops it: ending every session, replacing a leaked key, returning to the last good release, or blocking a source at the edge. The cause is reproduced and fixed on a copy, never on the live system, and a record is kept. Affected customers are told as the law requires.

Reporting a Vulnerability

Write to [email protected]. The Vulnerability Disclosure Policy says what you may test, what is out of scope and how quickly we respond.

Certification

Logrinth holds no SOC 2 report, ISO 27001 certificate or other certification, and has not had an independent penetration test.