Platform · Security

An accurate posture, not a checkbox page.

Bridgewerks is mid-migration from a single-tenant deployment model to one shared, organization-scoped service. We'd rather tell you exactly where that stands than round it up.

SOC 2 is a hard gate before general sale: we will not claim SOC 2 completion, and we have not started a Type I or Type II audit. A gap-analysis document tracks the control work against SOC 2's expectations and is available under NDA once a pilot conversation is underway.

Access & authentication
Centralized authentication

Every session-bearing route gates through a shared auth check. Sign-in supports Microsoft Entra ID, Google, and email/password, with domain or email allowlisting for SSO.

Password hashing + reset

Bcrypt password hashing; single-use, hashed, time-limited password reset tokens.

Login lockout

Durable, database-backed lockout after repeated failed logins — survives serverless restarts.

Durable abuse controls

Postgres-backed sliding-window limits cover auth, borrower and broker portals, AI/Ask, generated exports, and selected high-cost uploads. User and organization budgets hold across server instances; auth and portals fail closed if the limiter store is unavailable.

Multi-factor authentication

Not enforced by Bridgewerks itself. Entra ID and Google sign-in may enforce MFA at your identity provider if you configure it there.

Planned
Role-based / admin access separation

Database-backed admin flag is the source of truth for admin access, with an environment allowlist as an SSO fallback.

Tenant isolation — migration in progress

This is the section most worth reading closely if you're running a security review. Bridgewerks is moving from one deployment per customer to one shared multi-tenant service with row-level security as the enforced isolation boundary. That migration is underway in the same codebase you'd be evaluating — not finished, and not represented as finished.

Organizations and memberships

Every lender is an organization; users get access through a verified membership record, not a client-supplied ID.

Organization-scoped ownership rollout

organization_id is being added across tenant-owned tables and enforced through row-level security, table family by table family — the migration is in progress, not finished across the whole schema.

Limited / setup
Row-level security as the execution path

RLS policies are shipping alongside a non-service-role database role so tenant queries are actually forced through them, replacing the prior service-role (RLS-bypassing) access pattern — in progress, being proven table family by table family, not yet the sole path everywhere.

Limited / setup
Per-request membership re-verification

Re-checking active membership on every request (so a suspended member's session can't outlive the suspension) is part of the same in-progress migration.

Planned
Cross-organization negative testing

Automated tests that prove one organization cannot reach another's data are a required acceptance gate for the migration, not yet complete across every surface.

Planned
Per-organization encrypted integration credentials

Integrations are configured deployment-wide today, not yet as per-organization encrypted rows — a named target of the same migration.

Planned
Audit trail, headers & monitoring
Document access audit log

Every view, download, upload, and delete of a borrower document is recorded — actor, action, and linkage to the deal or loan.

Admin action audit events

Administrative actions are recorded to a durable audit-events table.

Security headers

HSTS with preload, a restrictive Content-Security-Policy, X-Frame-Options, and X-Content-Type-Options are set on every response.

Encryption in transit and at rest

TLS everywhere; hosting and database providers encrypt data at rest by default.

Centralized security monitoring / alerting

No Sentry/Datadog-class monitoring or alerting on lockout spikes or anomalous admin activity exists yet.

Planned
Written incident-response and disaster-recovery runbooks

Not yet adopted as formal, auditor-facing documents.

Planned
SOC 2

SOC 2 is a hard gate before Bridgewerks is sold at general list price. Today that means an internal gap-analysis document, not an audit: no compliance-automation platform is connected, no auditor is engaged, and no Type I or Type II report exists yet. A Type I report is a point-in-time design assessment; a Type II report requires an observation window of several months after that. Design-partner conversations can proceed on the strength of a completed Type I and a dated Type II commitment once that work starts — general sale waits for the completed Type II report.

Bridgewerks hosts on Vercel and Supabase, both of which publish their own SOC 2 reports as subservice organizations; encryption at rest and infrastructure redundancy below the application layer are their responsibility, tenant isolation above it is ours.

Ask us the hard question first.

Bring your security questionnaire. We'll answer what's shipped, what's in progress, and what isn't built yet — in that order.