Skip to main content
BrokerDefender
Security

How BrokerDefender protects vetting records.

BrokerDefender's value depends on the integrity of the records it produces. This page describes how vetting data is transmitted, stored, and protected against tampering, and how a third party can independently verify a Due Diligence Packet.

Transport security

All BrokerDefender web traffic is served over HTTPS with HSTS enabled in production. The FMCSA QCMobile API is called over HTTPS using an FMCSA-issued webkey held in server-side configuration and never exposed to the browser.

Authentication

User accounts are managed through ASP.NET Identity with password hashing via PBKDF2 (industry standard). Passwords are never logged, stored in plaintext, or transmitted outside the sign-in flow. Account creation requires a unique verified email address; the application enforces a minimum password length and complexity.

Anonymous vettings are bound to a per-browser session cookie (bd_anon) so the result page is accessible only from the browser that ran the vetting. When an anonymous user signs in or creates an account, their pending vetting is claimed onto their account record.

Storage

Vetting records are stored in a SQL Server database with the carrier's raw FMCSA payload preserved verbatim in a snapshot table. The decision engine reads from the snapshot, never from a re-fetched payload, so the data evaluated is the data retrieved.

Due Diligence Packets are stored as ZIP files on encrypted disk. Each packet's SHA-256 hash is recorded against the corresponding VettingChecks row at the moment of generation; the hash is the integrity anchor for the packet's life.

Retention

Free-plan vetting records and their packets are retained for 30 days from the generation timestamp, after which they are deleted by a nightly retention job. Paid-plan retention is determined by the plan tier and shown on the pricing page. Retention applies to both the database row and the packet ZIP on disk; both are removed together.

Deletion under retention is permanent. Brokers who require a record beyond their plan's retention window should download the Due Diligence Packet and archive it externally.

Tamper evidence

Every Due Diligence Packet is shipped with three layers of integrity verification, in increasing order of authority:

  • The Forensic Audit Record inside the packet lists the SHA-256 hash of every other document the packet contains, plus the raw FMCSA snapshot.
  • The raw/report_hash.txt file inside the packet lists the same hashes in sha256sum format for verification with standard *nix tooling.
  • The packet ZIP's own SHA-256 is recorded against the corresponding vetting record on the server. It is displayed on the vetting result page and on the public verification endpoint. The ZIP cannot contain its own hash; the server-side record is the authoritative integrity anchor.

Independent verification

A third party in possession of a Due Diligence Packet can verify its authenticity without a BrokerDefender account:

  1. Open the Compliance Attestation or Forensic Audit Record and locate the QR code or printed verification URL.
  2. Scan or visit the URL. The public verification endpoint at /verify/{vettingId} displays the vetting's fingerprint: carrier USDOT, legal name, generation timestamp, decision outcome, and packet SHA-256.
  3. Compare the displayed fingerprint to the same fields inside the packet, and recompute the packet ZIP's SHA-256 to compare against the value shown. A match on all four confirms the packet is unmodified and was produced by BrokerDefender for the indicated carrier at the indicated time.

Disclosures

BrokerDefender does not currently undergo external security audits or hold SOC 2, ISO 27001, or similar formal certifications. The protections described above are operational, not formally attested. A broker whose compliance program requires audited controls should confirm fit with BrokerDefender before relying on it for high-stakes decisions.