Digital Signatures for Freight Brokers
What actually happens when a carrier "signs" your broker-carrier agreement online — the cryptography, the trusted timestamp, the audit envelope, and how to prove the signature in a claim dispute six months later.
What a digital signature actually is
Most of what brokers call an "e-signature" today isn't really a signature. It's an event. The carrier checks a box, types their name into a field, or clicks "I agree" — and somewhere on the platform's server, a row gets written to a database. The PDF itself never changes. If the platform's database is later wiped, sold, or sued out of existence, the proof goes with it.
A digital signature — the kind that survives a hard drive crash, a vendor going under, or a lawyer subpoenaing the file — is different in three ways:
- It's cryptographic. A mathematical hash of the document is signed with a private key. Anyone with the matching public certificate can verify, with no help from the original platform, that the document hasn't been altered since signing.
- It's tied to a real moment in time. A separate request goes to a Time-Stamp Authority (TSA), which signs a token attesting "this document existed in exactly this form at 14:32:17 UTC on 2026-05-18." The TSA never sees the contents — only the hash — but its signature on the time is independently verifiable.
- It lives inside the PDF. The signature, the certificate, and (for the strongest profiles) the timestamp token are all embedded in the file's byte stream. The PDF travels with its own proof.
The legal world has three rough tiers of e-signature: a plain typed name (basically a wet-ink scan), a click-to-accept event (better — there's an event log somewhere), and a cryptographically-signed PDF (strongest). The first two require you to trust whichever vendor's database the event lives in. The third doesn't.
Why this matters when the carrier is moving your freight
If you're a broker, your broker-carrier agreement is the only thing standing between you and an unrecoverable loss when a load goes sideways. The carrier signs it once at onboarding, and it sits in a folder somewhere until — months or years later — it has to do real work. Here's where the signature actually gets tested:
Cargo claim disputes
A load goes missing or damaged. The carrier's insurer asks for the signed BCA before paying. If your signature evidence is a row in a vendor's database and the vendor is unresponsive, the claim sits.
Double-brokering fraud
A bad actor uses a real carrier's MC# to book your load, then re-tenders it. When the real carrier shows up and asks "why does my MC# have your signed packet?", you need to prove who actually controlled the email that signed it.
Factoring & surety audits
Your bond company, your factor, or an annual broker-authority audit asks for documentation that the carriers you paid had a signed agreement on file. "Trust me, it's in the system" is not the answer they want.
Non-payment lawsuits
A carrier sues for unpaid invoices and claims the rate confirmation terms in your packet aren't binding because they never agreed to them. The signed PDF — with audit trail — is your direct rebuttal.
FMCSA records retention
49 CFR Part 379 says brokers retain records for three years. "Records" includes the carrier's signed agreement. A cryptographically-signed PDF satisfies that requirement cleanly; a database row plus a screenshot does not.
Vendor lock-out
If the platform you e-signed through closes its doors or changes pricing, your signed agreements should stay verifiable without their cooperation. With cryptographic signatures, the file alone is enough.
Sign your first packet in under five minutes.
Every plan, including the free tier, ships with full cryptographic signing on every onboarded carrier. No add-on, no per-envelope fee.
What CarrierPacket.Link actually does
Most broker-onboarding platforms outsource the signing step to a third-party signing service (DocuSign, Adobe Sign, HelloSign, Dropbox Sign). That's a perfectly reasonable choice — those services produce real, AATL-trusted, PAdES-grade PDFs. We made a different decision: signing happens inside CarrierPacket.Link, end to end. No third-party signing service in the loop. No per-envelope fee. No second vendor relationship for your legal team to vet.
The trade-off is honesty about which trust tier we sit at. We use the same cryptographic anchors a commercial signing service uses, with one technical caveat we'll explain below. Here's the spec sheet:
- Signature standard: CMS / PKCS#7 detached envelope, embedded in the PDF byte stream per the ISO 32000 signature dictionary spec. Functionally equivalent to PAdES B-T (ETSI EN 319 142). Cryptographic anchors are identical to a strict PAdES signature; the technical caveat is that we use Adobe's pre-PAdES SubFilter (
adbe.pkcs7.detached), which every standards-compliant PDF reader treats the same as the strict ETSI variant. - Algorithm: RSA-2048 + SHA-256. The current NIST recommendation for new signatures through at least 2030.
- Signing cert: A self-issued RSA-2048 certificate held by CarrierPacket.Link (CN:
CarrierPacket.Link Signing Authority). The public certificate is downloadable at /app/cert.php so a third party can verify any signed PDF without needing access to our infrastructure. The private key lives outside the web docroot, readable only by the signing process. - Trusted timestamp: Every signed PDF is paired with an RFC 3161 timestamp token from FreeTSA, a free public Time-Stamp Authority. FreeTSA's signature attests when the signing happened, independent of our server clock.
- Email verification gate: The signed PDF is not minted until the signer clicks the verification link in their email. The verification token, the verified-at timestamp, and the verifier's IP address are baked into the signature's Reason field — alter any of them and the cryptographic signature breaks.
- Secured mode (optional): For high-stakes packets, you can require the carrier to claim their MC# via SMS to the phone FMCSA has on file for that carrier before they're allowed to sign. The SMS code is verified against a 10-minute window; only an authenticated carrier session can submit a secured packet.
- Audit envelope: An append-only
signature_eventslog captures every step — intent-to-sign, submission, email-verified, signed — with IP, user-agent, OS, consent text hash, and PDF hash for each event. No event row is ever updated or deleted. - Public verification: Every signed packet has a permanent public verification URL at
/v/<hashid>where the hashid is the SHA-256 of the signed PDF. Anyone with the link — a claims adjuster, an attorney, an auditor — can confirm the file is intact without a login, without a download, without an API call.
What we're not (and why that's the right level for broker-carrier agreements)
Our cert is self-issued, not bought from an AATL-listed Certificate Authority. That means Adobe Reader will show "Signed by CarrierPacket.Link Signing Authority — issuer trust unknown" on first open. The cryptography is identical; what's missing is the green-check UI Adobe shows for commercial certs purchased from CAs on Adobe's Approved Trust List.
Our RFC 3161 timestamp is a sidecar .tsr file rather than an unsigned attribute embedded on the CMS signature itself. Strict PAdES B-T embeds the timestamp inline; ours sits next to the PDF on the verification page. Verifying the timestamp with openssl ts -verify works the same against the sidecar.
For US broker-carrier agreements — the typical 30 to 60-day payment cycle, governed by E-SIGN and UETA — this profile is the right level. Upgrading to AATL-trust or strict PAdES B-T is on the roadmap; both require either purchasing a commercial certificate or moving to a hardware-backed signing service.
Done with the spec sheet? Spin up a free account and walk through the signing flow yourself — start to finish in five minutes, no card required.
Create your accountThe audit envelope, in plain English
A digital signature isn't one thing. It's four answers to four different questions a lawyer might ask about the document later. Each anchor stands on its own; together, they make the signature defensible.
Document tamper-evidence
The PDF's bytes are hashed at signing. Any change to the document after signing — a single pixel, a comma — invalidates the cryptographic signature.
Answers: "Has the document been altered since the carrier signed?"Signer identity
The X.509 certificate embedded in the signature identifies who signed. For our signatures, that's CarrierPacket.Link signing on behalf of the verified signer. The signer's email + verification IP are encoded into the signature itself.
Answers: "Who actually signed this?"Independent time attestation
The RFC 3161 timestamp token from FreeTSA attests when the signing happened, independent of our server clock. FreeTSA never sees the document — only its hash — but its signature on the time is independently verifiable.
Answers: "When was this signed, attested by an independent third party?"Audit metadata
An append-only log captures the IP address, user-agent, operating system, and verbatim agreement text the signer was shown. None of this is ever updated or deleted, and each entry's hash is anchored to the next.
Answers: "From where, on what device, and exactly what text did the signer agree to?"Every signed packet PDF also includes a final page titled Certificate of Completion. It's the human-readable companion to the cryptography: signer name, signer email, signer IP address, signing time (both our server's clock and the TSA-attested time), the SHA-256 hash of the agreement text the signer saw, and the signing algorithm. A reader who can't or won't verify the embedded cryptographic signature can still read this page and understand the audit story at a glance.
What your carrier sees, step by step
Five steps from link-click to signed PDF in your TMS. We labeled each step with what's happening cryptographically underneath, in case your team wants to understand the moving parts.
-
The carrier fills the packet
From the broker's onboarding link, the carrier completes their profile, uploads documents (W-9, COI, Operating Authority), and reviews the broker-carrier agreement text in full. Auto-fill from FMCSA cuts the form down to what only the carrier knows.
No signature yet. The agreement HTML is captured verbatim so it can be hashed at sign time. -
The carrier clicks "Sign"
The exact agreement text appears one final time with a "Sign here" button. Clicking it submits the form with explicit intent to sign — the consent surface is unambiguous, the agreement is on screen, and the click is the affirmative act.
The agreement HTML is SHA-256 hashed. An intent-to-sign event is written tosignature_eventswith the signer's IP, user-agent, and operating system. -
A verification email goes to the signer
Before the PDF is minted, we email the signer a single-use verification link. This is the email-OTP gate: the signature isn't legally complete until the signer demonstrates they control the email they submitted.
The verification token is the SHA-256 of a random 32-byte value. The plaintext is sent to the signer; only the hash is stored on our side. -
The signer clicks the link, and the PDF is minted
The verification click is what cryptographically signs the PDF. The signer's email, the verification token's first 16 hex characters, the verified-at timestamp, and the signer's verification IP are baked into the signature's Reason field. Modifying any of those values invalidates the signature.
The PDF is signed with RSA-2048 + SHA-256 via CMS/PKCS#7. A request to FreeTSA fetches the RFC 3161 timestamp. The signed bytes and the timestamp token are written to disk; their hashes go intocarrier_profile_versions. -
The broker is notified and the TMS webhook fires
You get an email with the full carrier profile, a link to the signed PDF, and a permanent public verification URL. Simultaneously, if your TMS is connected, an HMAC-signed webhook fires with the carrier record and the PDF URL. The signed agreement is in your system of record within seconds of the verification click.
A "signed" event is written tosignature_eventscapturing the final PDF hash, the timestamp path, the PAdES level achieved (B-T when the TSA succeeds, B-B if it timed out).
Walk through this flow yourself.
Sign up free, build your first packet, and send the link to yourself as a test carrier. See exactly what your real carriers will see — including the signed PDF, the audit envelope, and the public verification page.
How to verify a signed packet in five minutes
The point of cryptographic signing is that anyone — your insurer, your attorney, an auditor, an opposing counsel's expert witness — can verify a signed PDF without needing access to your systems. Three methods, easiest first.
The public verification page
Every signed packet has a permanent URL at /v/<hashid>. Open it in any browser. The page shows whether the file's bytes match what we signed, displays the signing cert fingerprint, and offers a download of both the PDF and the timestamp sidecar. No login required.
Adobe Reader's signature panel
Open the signed PDF in Adobe Reader (or any standards-compliant PDF reader). Click the signature panel in the left sidebar. You'll see whether the document has been modified since signing, the signing cert, and the signing time. Adobe will show "issuer trust unknown" for our self-issued cert; the cryptography is still valid.
Programmatic, via OpenSSL or our API
For your dev team or an outside auditor: download the PDF and the .tsr sidecar from /v/<hashid> and run openssl ts -verify against the timestamp. Or use our REST API to fetch the stored SHA-256 and re-hash. Full instructions are in our developer documentation.
Why this is enforceable
This section is general information, not legal advice — but the federal framework is straightforward enough that a broker can understand it without retaining a contracts attorney for an hour.
United States: E-SIGN Act and UETA
Two laws give electronic signatures the same legal weight as wet-ink signatures: the federal Electronic Signatures in Global and National Commerce Act (E-SIGN, 15 U.S.C. § 7001, enacted 2000) and the state-level Uniform Electronic Transactions Act (UETA, adopted by 49 states plus DC). Both require four elements for an electronic signature to be enforceable:
- Intent to sign. Our carrier clicks "Sign here" after seeing the agreement text in full. The click is the affirmative act; the surface is unambiguous.
- Consent to do business electronically. The agreement is shown verbatim on the same screen as the click; consent to electronic execution is part of the click-to-sign action itself.
- Attribution to the signer. IP address, user-agent, signed-at timestamp, and email-verification token are captured per signing event. The verification email gate adds one more attribution layer: the signer demonstrably controlled the email at signing time.
- Record retention. The signed PDF is stored on disk, the SHA-256 is stored in the database, and the
signature_eventsaudit table is append-only. The signed file persists for the life of the broker's account.
European Union: eIDAS
EU Regulation 910/2014 (eIDAS) defines three tiers of electronic signature: simple electronic signature (SES), advanced electronic signature (AES), and qualified electronic signature (QES). Our signatures qualify at the SES tier — sufficient for the vast majority of commercial agreements in the EU, but not the strongest tier the regulation defines.
Upgrading to AES requires a certificate from an EU-listed Qualified Trust Service Provider (QTSP) plus signer-control properties (uniquely linked to the signer, capable of identifying them, sole-control creation, tamper detection). Upgrading to QES additionally requires the signature be created with a Qualified Signature Creation Device (QSCD) — typically a hardware token or a certified remote signing service backed by HSM technology. Both AES and QES upgrades are on our roadmap for brokers who specifically need them.
FMCSA records retention
49 CFR Part 379 requires brokers to retain records of every transaction for at least three years, and the signed broker-carrier agreement is explicitly listed among the records covered. A cryptographically-signed PDF satisfies this requirement on its own — the bytes prove the carrier's signature without needing any auxiliary database to be online.
What changes when a dispute happens
Here's the concrete scenario the whole system is built to handle. Eight months after onboarding, a carrier you've paid eighteen invoices sues you for non-payment on a nineteenth. They argue the rate confirmation terms in your broker-carrier agreement aren't binding because they never agreed to them.
What you produce
From your dashboard, you download:
- The signed PDF of the broker-carrier agreement (the same file the carrier saw when they signed)
- The
.tsrsidecar timestamp token from FreeTSA - The append-only
signature_eventsaudit log row for this carrier - The public verification URL at
/v/<hashid>
What the opposing counsel's expert witness sees when they open the PDF in Adobe Reader: the embedded signature, the cert chain, the SHA-256 of the document at signing time, and the FreeTSA timestamp. They can independently verify with openssl ts -verify against the sidecar that the document existed in exactly that form on the date and time stamped. They can read the Certificate of Completion page and see the signer's email, IP, and the agreement-text hash.
What they can't do is argue the document was altered after signing, or that the signature was fabricated, or that the signing time is wrong. The cryptography rules those arguments out.
This is what you're buying. Not the dashboard. Not the embed. Not the FMCSA pulls. The proof that holds up the day you actually need it. Every carrier onboarded through CarrierPacket.Link ships with this envelope by default.
Start protecting your contractsWhy Adobe says "issuer trust unknown" (and what it means)
The first time you open a CarrierPacket.Link-signed PDF in Adobe Reader, you'll see a yellow banner: "Signed and all signatures are valid" alongside "Signed by CarrierPacket.Link Signing Authority — issuer trust unknown." This is expected, and it does not mean the signature is invalid.
Adobe maintains a list of root Certificate Authorities it trusts out-of-the-box called the Adobe Approved Trust List (AATL). Commercial signing services (DocuSign, Adobe Sign) sign with certs issued by CAs on that list, so Adobe shows a green check on first open. Our cert is self-issued by CarrierPacket.Link — the same key, the same algorithm, but Adobe doesn't recognize the issuer.
Two ways to get the green check:
- Add our root cert to Adobe's trust store manually (one-time, per user). Download our public cert at /app/cert.php and import it into Adobe Reader's trusted-identities list. Adobe shows a green check from then on.
- Wait for the AATL roadmap. We can purchase a cert from an AATL-listed CA and re-sign new packets with it. That's a planned upgrade for brokers who specifically need out-of-the-box AATL trust — typically those whose internal compliance team requires it for vendor signing.
For everyone else, the practical answer is: the cryptography is identical to a commercial-CA signature; the visual badge in Adobe is what differs. Your insurer, your attorney, and any auditor will run their own verification — and verifying via OpenSSL or our public verification page produces the same trust outcome either way.
CarrierPacket.Link vs the alternatives
There are four ways brokers commonly handle broker-carrier agreement signing today. Each has a place; the right choice depends on what trade-offs you're optimizing for.
| What you get | Typed-name PDF | DocuSign / Adobe Sign | CarrierPacket.Link | AATL-trusted commercial cert |
|---|---|---|---|---|
| Cryptographic signature | No | Yes | Yes | Yes |
| Tamper evidence in the file itself | No | Yes | Yes | Yes |
| Verifiable without vendor cooperation | No | Yes | Yes | Yes |
| Trusted third-party timestamp | No | Yes | Yes (FreeTSA, RFC 3161) | Yes |
| Adobe Reader green check out-of-box | No | Yes | No (trust unknown) | Yes |
| E-SIGN / UETA compliant | Marginal | Yes | Yes | Yes |
| eIDAS tier | Below SES | SES (often AES) | SES | AES or QES |
| Per-envelope cost | $0 | $0.50–$3 | $0 (in your plan) | $1–$5+ |
| Built into your carrier-onboarding flow | No | Integration required | Yes, native | Integration required |
DocuSign and Adobe Sign make great products. We didn't build our signing pipeline because theirs are bad — we built it because tying broker-carrier signing to a per-envelope outside vendor creates a cost floor that doesn't fit a per-broker SaaS price. For brokers whose internal compliance specifically requires AATL-trusted commercial certs, our SES tier may not be a fit today; the AATL roadmap addresses that.
Compare it against what you're using now. The free tier signs your first 30 carriers at zero cost — bring a real packet over and see how the signed PDF holds up against whatever you have on file today.
Sign up freeFrequently asked questions
Is a self-signed cert really legally binding?
What happens if FreeTSA goes down when a carrier signs?
Can I use my own cert instead of CarrierPacket.Link's?
What happens if the carrier denies signing?
signature_events. The signature ties the carrier's submitted email to the verification-click IP; the FreeTSA timestamp ties the signing to an exact moment in time; the audit log captures IP, user-agent, OS, and the verbatim agreement HTML. To successfully deny signing, the carrier would need to argue someone else controlled their email at the moment of verification — a steep claim against the documentary record.Do you support eIDAS Qualified Electronic Signatures (QES)?
How long do you keep the signed PDF and the audit log?
signature_events log is append-only and rotates with normal database backups. If you cancel your subscription, signed PDFs remain accessible for export for a reasonable wind-down window. We don't delete signature evidence on a schedule.Can the broker (or the carrier) download the signed PDF?
/v/<hashid> also offers a direct download of both the signed PDF and the FreeTSA timestamp sidecar.What about EU / GDPR carriers?
Is this the same as a wet-ink signature legally?
What's the difference between this page and your developer docs at /docs/signing?
References
- 15 U.S.C. § 7001 — Electronic Signatures in Global and National Commerce Act (E-SIGN)
- Uniform Law Commission — Uniform Electronic Transactions Act (UETA, 1999)
- Regulation (EU) No 910/2014 — eIDAS
- ETSI EN 319 142-1 — PAdES (PDF Advanced Electronic Signatures)
- RFC 3161 — Time-Stamp Protocol (TSP)
- ISO 32000-2 — PDF 2.0 (signature dictionary spec)
- FreeTSA — public RFC 3161 Time-Stamp Authority
- 49 CFR Part 379 — Preservation of records (FMCSA, three-year retention)
- CarrierPacket.Link — Developer documentation: digital signatures
- CarrierPacket.Link — Public signing certificate (PEM download)
Start signing real PDFs today
Two minutes to sign up, no card to start. Every carrier you onboard gets a cryptographically-signed agreement out of the gate — no upgrade, no per-envelope fee, no second vendor.
Try CarrierPacket.Link free