Every account is walled off at the database, not just behind a login.

Zero Trust from the first login. Requests are verified, records are encrypted, and no other account can reach your data.

AES-256 at restTLS 1.3 in transitUS infrastructureOwned by you, not us

One account can never read another

Most software keeps every customer in one shared database and trusts the application to filter each query by account. SecureCrews does not rely on that. Isolation is enforced by the database itself.

Every table carries a row-level security policy set to FORCE, so it applies to the connection the app runs on with no exception. Each request sets the tenant it belongs to before it touches any data, and the database returns only the rows that match. A query for another account comes back as if the record was never there.

request · tenant AROW-LEVEL SECURITYtenant_id must match session context · FORCECELL Ayour dataCELL BblockedCELL Cblocked
TLS 1.3AES-256

Encryption in three layers

  • In transit

    Every connection uses TLS 1.3. Older, weaker protocols are turned off, so there is no unencrypted path to any part of the system.

  • At rest

    Personal and financial fields are encrypted with AES-256-GCM before they reach disk. A stolen backup is ciphertext without the keys.

  • Sensitive documents

    W-9s, insurance certificates, and signed contracts get their own key, wrapped by AWS KMS and stored apart from the file.

Control ledger

What runs behind the login, layer by layer

These are shipping controls, not a roadmap. They break down into who is asking, where the data sits, and what a request is permitted to do. It is the same class of control that banks and regulated industries answer to.

Identity
Who is making the request
Access tokenJWT, 15 min lifetime
Refresh rotationfamily revoked on reuse
Two-factorTOTP, all user roles
Admin sign-inWebAuthn / passkey
Password checkHIBP breach match on set
Failed loginsprogressive lockout, owner alert
Data
Where it lives and how it is sealed
Tenant isolationPostgreSQL RLS, FORCE
Field encryptionAES-256-GCM at rest
Sensitive documentsKMS-wrapped per-document key
In transitTLS 1.3, older protocols off
File accesspre-signed URL, 15 min
Data residencyUnited States
Application
What each request is allowed to do
Authorizationrole-scoped, every request
Audit logappend-only, immutable
Session revocationpropagated in seconds
Rate limitingauth, public, admin paths
Privacy requestsexport / delete in-app
SOC 2 Type IIin progress

What this means on a normal day

Situation

A competitor signs up for SecureCrews.

What happens

They cannot tell your account exists, let alone read your clients, pricing, or job history. Accounts never share a table.

Situation

A crew member loses their phone.

What happens

Revoke the session from the dashboard. It stops working within seconds, on every device it was signed in on.

Situation

A client disputes a finished job.

What happens

Pull every signed document, GPS clock-in, and milestone photo into one record. Nothing in it can be changed after the fact.

Situation

You decide to leave.

What happens

Export everything, then ask us to delete it. We remove it from the database, the file store, and the backups.

Found something? Tell us.

If you spot a vulnerability, email [email protected]. We reply within 48 hours and we do not pursue researchers who report in good faith and give us time to fix it.

See what isolated actually means.

Start free trial. 30 days, no card.