Security overview

Architecture

BridgeComp is a single application with a Postgres database, a background worker and a per-flow webhook surface. Customers are companies inside one multi-tenant instance; every row that belongs to a customer carries its company. Enterprise plans can run as a dedicated instance instead.

The application never lets an integration adapter reach the platform database, and never lets a route reach tenant data without a company scope. Both rules are enforced by architecture tests that fail the build, not by convention.

Credential protection

The credentials you give BridgeComp — ERP tokens, 3PL secrets, database passwords — are encrypted with AES-256-GCM before they are written, using a key that is held in the deployment's environment and never in the database.

• No API returns a stored credential — not the admin UI, not the export, not support tooling. Credentials go in and are used; they don't come back out.
• A database dump on its own is not enough to use them, because the key isn't in it.
• The key is validated at boot: a wrong or mistyped key stops the process instead of quietly writing data nobody can decrypt again.
• Connections can be duplicated for a test environment with the credentials deliberately left blank, so a test system never inherits live secrets.

Tenant isolation

Every tenant-scoped query goes through a repository layer that requires the company scope as an argument. Route handlers cannot issue raw database queries — an automated architecture test fails the build if one tries.

Platform staff have no ambient access to your data. Support access happens through an explicit "act as company" switch that demotes the staff session to that company's administrator role, writes an audit record for the switch itself, and shows a banner for the whole time it is active.

Authentication

• Passwords are hashed with argon2id. They are never logged, never emailed back, and changing one revokes your other sessions.
• Two-factor authentication uses TOTP from any authenticator app, with one-time recovery codes issued at enrolment. It is enforced for administrator roles.
• Brute force is answered with lockout: five consecutive failed passwords locks the account for fifteen minutes, and the second factor has its own lockout.
• Sessions are server-side records behind an HttpOnly cookie, revocable individually or all at once, and every state-changing request needs a matching CSRF token.
• Recovery is administrative: a company administrator can reset a colleague's password or second factor, and every reset is audited and revokes that user's sessions.

Access control

Systems, flows and jobs belong to groups. A user holds one role per group — viewer, operator or admin — so the person who watches the warehouse integration does not automatically get to edit the finance one.

• Viewer reads jobs and flows.
• Operator also retries and cancels jobs.
• Admin also configures systems, flows and tokens in that group.
• Company administrator manages users, groups and every group's configuration.

Going live is treated as privileged: taking a flow out of dry-run is a separate audited action, and a job whose external write already committed cannot be retried by anyone — the API refuses it rather than trusting a warning dialog.

Audit logging

Configuration and operational changes are written to an append-only audit trail with the actor, the target, the time and the company. Logins, user changes, credential changes, flow edits, go-live flips, retries, cancellations and support access all appear there, and flow configuration is versioned separately so you can see exactly what a flow looked like when a given job ran.

Webhook security

• Each flow gets its own endpoint, and each endpoint requires a scoped bearer token.
• Tokens are shown once when minted and stored only as a SHA-256 hash — we cannot recover one for you, only replace it.
• Tokens are scoped to the direction and systems they serve, and revoking one takes effect immediately.
• Payload size is capped, and a rejected call never reaches a flow.

Data handling

BridgeComp stores what it needs to prove what happened: the payloads a flow read and wrote per step, the configuration of your systems and flows, the correlation ledger, and the audit trail. It is not a copy of your ERP — documents pass through and are recorded, they are not replicated into a parallel database.

Your plan sets how far back you can inspect payloads and step detail. Ask us and we will delete a company's job data, or the company itself, at any point — including at the end of a contract, where deletion is the default rather than something you have to request.

Infrastructure & backups

• Traffic is HTTPS only, with HSTS and a content security policy set by the application rather than left to defaults.
• The application listens behind a reverse proxy; its port is not reachable from the internet.
• The database is backed up nightly by a scheduled job that is part of the deployment, with retention on the backup host.
• Encryption keys are held outside the database and are escrowed separately — a restore needs both.
• Dependencies are pinned, and the platform runs on supported LTS versions of its runtime and database.

Monitoring & incidents

The same machinery that watches your integrations watches the platform. Failures are classified and raise alerts to the destinations you configure — email, Slack or a webhook — deduplicated so they stay readable. Silence is treated as a failure too: if the worker stops ticking or due jobs pile up, an alert fires rather than nothing happening quietly.

If an incident affects your data or your integrations, you hear it from us with what happened, what we did and what we changed — as soon as we know, not after we have a story.

What we don't claim

Security pages are usually a list of logos. Here is the honest state of ours, so nobody discovers it late in a procurement cycle:

• BridgeComp is not SOC 2 or ISO 27001 certified.
• We make no HIPAA or PCI DSS compliance claim, and BridgeComp is not intended for cardholder or protected health data.
• There has been no third-party penetration test to date.
• There is no standard published uptime SLA; a contractual SLA is available on Enterprise plans.
• There is no blanket data-residency guarantee outside a dedicated Enterprise instance.

What we do have is a small, auditable system with the mechanisms above, and people who will answer a security questionnaire in specifics.