Security

Infrastructure

Borderly runs on Vercel's application hosting platform, backed by a managed PostgreSQL database on Supabase. All traffic between your browser and our servers is encrypted in transit (TLS 1.2+), and data is encrypted at rest at the infrastructure level.

Production data is automatically backed up on a regular schedule, with backup integrity checked on an ongoing basis and restore procedures tested independently of the primary backup job.

Authentication & Access Control

• Passwords are never stored in plain text — only as one-way bcrypt hashes.
• Optional sign-in via Google OAuth, alongside email/password.
• Optional two-factor authentication for any account: an authenticator app (TOTP), a passkey, or an emailed one-time code, with a 30-day trusted-device option to reduce repeat prompts.
• Role-based access within an organization (Owner, Admin, Member), with finer-grained roles for agencies managing multiple client organizations.
• Every organization's data — shipments, documents, companies, products — is isolated from every other organization's, enforced in our application logic on every request and backed by database-level Row-Level Security as a defense-in-depth control.
• API access uses separate, individually revocable API keys, stored as one-way hashes rather than plaintext, with per-organization rate limiting.
• Borderly Handshake's non-org stakeholders (farms, truckers, brokers, carriers, prep centers) authenticate one of two ways, matched to how often they use it: a persistent JWT session for repeat participants, or a single-use magic link scoped to exactly one shipment milestone for one-time check-ins. Either way, a stakeholder only ever sees the milestone(s) they're assigned to — never the rest of the shipment's compliance data.

Application Security

• All inputs — from file uploads to API requests — are validated against strict schemas before being processed or stored.
• Outbound webhook deliveries are hardened against server-side request forgery: requests to private, loopback, or link-local addresses are rejected, and every payload is signed with HMAC-SHA256 so recipients can verify authenticity.
• A strict, nonce-based Content-Security-Policy restricts every page to running only the scripts we serve — a fresh, unpredictable token is issued per request and required for any script to execute.
• A test-mode authentication bypass used for our own automated testing is disabled by default and only active in non-production environments.
• Dependencies and third-party libraries are kept current as part of our normal release process.

Monitoring & Incident Response

Application errors are monitored in real time so issues are caught and addressed quickly. Key account and organization-level actions — membership changes, billing events, data exports — are recorded in an audit log.

If you believe you've found a security vulnerability in Borderly, please email info@latitude10.tech with details. We investigate every report and will follow up directly — please give us a reasonable window to address an issue before disclosing it publicly.

Compliance

Borderly is building toward a SOC 2 Type I report covering our security practices. This is an active program, not yet a completed certification — reach out if you need current status for a vendor security review.

Our own compliance engine screens shipments against denied-party and sanctioned-destination lists as part of the export readiness checks we run for you — see Features for what's included at each plan.

Sub-processors

We use the following third-party services to operate Borderly. Each is bound by its own data protection obligations for the data it processes on our behalf.

For details on what personal data we collect and how it's used, see our Privacy Policy.