White Paper · May 2026

Beyond “Certified Fax”
Why vendor-controlled proof isn't proof

Every major fax provider calls their delivery confirmation “certified.” Every one of them controls the evidence themselves. This white paper explains why that fails under real audit scrutiny — and how open-standard cryptographic attestation, already proven in software supply-chain security, closes the gap.

ECDSA · prime256v1Sigstore RekorLinux FoundationOffline-verifiableHIPAA-aligned
Section 1

The Problem: What “Certified” Actually Means

When a healthcare organization, law firm, or government agency sends a critical fax, they receive a “delivery confirmation” — a PDF or portal entry that says the fax was delivered. This confirmation is described by every major fax provider as “certified,” “verified,” or “audit-ready.”

Under scrutiny, this claim does not hold.

A PDF receipt generated by the same vendor who sent the fax is a statement by that vendor about their own service. It is not independently verifiable. It can be backdated. It exists only as long as the vendor remains in business and the customer remains a paying subscriber.

The fax industry inherited its trust model from physical fax machines — where “proof of delivery” meant a confirmation page from the sending machine. That model has not evolved in thirty years, despite the move to cloud services where the stakes — HIPAA violations, legal disputes, regulatory enforcement — are substantially higher.

The question a compliance auditor, opposing counsel, or OCR investigator will ask is not “does this PDF say it was delivered?” The question is:

“Can you prove this document was transmitted to this recipient at this time, independently of the vendor who sent it?”

No major fax provider can answer yes to that question today. FaxSeal can.

Section 2

The Industry Gap: Vendor-Controlled vs. Independent Proof

The diagram below shows the proof chain for a traditional “certified fax” versus FaxSeal's cryptographic attestation. In the traditional model, every node in the chain is controlled by the same vendor. In the FaxSeal model, proof exits vendor control at step 3 — permanently, and before any dispute can arise.

Vendor-controlledIndependently verifiable
Traditional "Certified Fax" — every node owned by the vendor
Fax Sent
via eFax / RingCentral
Carrier Callback
vendor logs it
PDF Receipt
vendor generates it
Audit Log
vendor controls it
✗ If the vendor goes down, gets acquired, or has an incentive to alter records — there is no independent check.
FaxSeal Fax Attestation — proof exits vendor control at step 3
Fax Sent
via FaxSeal
EC Signature
signed at send time
Rekor Entry
Independent — tamper-evident
Delivery Event
second signature logged
Your Bundle
verify offline with openssl
✓ Rekor is append-only. FaxSeal cannot edit or delete the entry after submission.

The critical difference is not technical sophistication — it is independence. Sigstore Rekor, maintained by the Linux Foundation, is an append-only transparency log. Once an entry is submitted, it cannot be altered or deleted by anyone, including FaxSeal. The entry is public, permanent, and independently fetchable by any party with the entry ID.

This is the same model that Certificate Transparency logs brought to TLS certificates in 2013, and that Sigstore brought to software supply-chain security in 2021. FaxSeal is the first to apply it to fax delivery.

Section 3

The FaxSeal Approach

FaxSeal's Fax Attestation feature builds a two-event signed audit chain for every fax sent by an Enterprise organization or Partner API integration.

Event 1 — Fax Sent

  • ·Triggered at carrier handoff (not at job creation)
  • ·Payload includes: jobId, recipient number hash, sender email hash, page count, timestamp
  • ·Signed with ECDSA prime256v1 private key
  • ·Submitted to Rekor — entry ID stored in database

Event 2 — Fax Delivered

  • ·Triggered when carrier confirms delivery
  • ·Payload includes: jobId, SHA-256 hash of delivered document, delivery timestamp
  • ·Independently signed and logged to Rekor
  • ·Both events linked by jobId — a complete, auditable chain

Both events are idempotent — if a webhook fires twice or a reconciler retries, the existing Rekor entry is preserved and no duplicate is created. The signing key never leaves FaxSeal's servers. Recipients and auditors verify using the public key, which is embedded in every bundle.

Section 4

How Attestation Works: Step by Step

The following sequence shows exactly what happens from the moment a user clicks “Send” to the moment an auditor can independently verify delivery.

📄
Fax uploaded & sentEvent 1 begins

User uploads PDF, FaxSeal hands off to carrier

1
🔑
Payload signedPrivate key — server only

ECDSA signature over jobId, recipient hash, page count, timestamp

2
🌐
Entry logged to RekorIndependent — tamper-evident ledger

Hash + signature submitted to Sigstore Rekor. Entry is permanent and public.

3
Carrier confirms deliveryEvent 2 begins

Carrier callback received. FaxSeal generates SHA-256 hash of delivered document.

4
🔗
Delivery event loggedIndependent audit trail complete

Second signed entry: document hash + delivery timestamp + send Rekor ID. Two-event chain sealed.

5
🔍
You verify — offlineVerified OK ✓

Download bundle once. Run openssl. No FaxSeal server, no login, no trust required.

6
Section 5

Independent Verification Demo

The following demo shows the complete offline verification flow. The only network call is the initial bundle download. After that, the signature check runs entirely locally with no FaxSeal server, no Rekor connection, and no trust assumption beyond the public key.

The key insight: the math either checks out or it doesn't. There is no way to produce “Verified OK” from a forged or altered bundle without access to FaxSeal's private key.

bash — offline verification
Section 6

HIPAA and PHI Considerations

Sigstore Rekor is a public log. Every entry is readable by anyone with the entry ID. This raises an obvious concern for healthcare use: does logging fax metadata to a public log create a HIPAA violation?

FaxSeal addresses this by hashing all identifiers before they enter the public log:

FieldIn public Rekor entryReasoning
Recipient fax numberSHA-256 hash onlyFax numbers are HIPAA identifiers when linked to PHI
Sender emailSHA-256 hash onlyEmail addresses are HIPAA identifiers
Job IDPlain textInternal identifier — no PHI linkage without FaxSeal access
Page countPlain textNon-identifying operational metadata
TimestampPlain textRequired for audit trail integrity
Document contentSHA-256 hash only (delivery event)Proves content integrity without exposing content
The hashes are one-way. They prove the number or email was involved in this transaction without revealing it. An auditor who already has the fax number can hash it and confirm it matches — but a third party reading the Rekor log cannot reverse the hash to identify the patient or facility.

Organizations should consult their compliance counsel regarding their specific BAA obligations. FaxSeal's standard BAA covers the attestation feature. The Rekor entries themselves contain no PHI under the hashing scheme described above.

Section 7

Compliance Use Cases

🏥

Healthcare — HIPAA audit trails

When OCR requests proof that a patient record was faxed to the correct facility on a specific date, a vendor-generated PDF is a claim, not evidence. A Rekor entry logged before any dispute arose is evidence.

⚖️

Legal — chain of custody

Court filings, discovery documents, and settlement agreements require a provable chain of custody. The two-event attestation chain — signed at send and again at delivery — satisfies the same standard as certified mail with return receipt.

🏛️

Government — FOIA and regulatory submissions

Federal agencies receiving FOIA responses or regulatory filings need to demonstrate receipt without relying on a private vendor's records. The Rekor entry is public, permanent, and subpoenable.

💊

Pharma — controlled substance prescriptions

DEA Schedule II prescriptions faxed to pharmacies require documentation that the exact document was transmitted and received. The document hash in the delivery attestation proves content integrity end-to-end.

Section 8

Competitor Comparison

The following table compares the attestation capabilities of major fax providers against FaxSeal's implementation.

ProviderProof methodIndependent?Offline verify?Open standard?PHI in public log?
eFaxCarrier callback + PDF receipt
RingCentral FaxDelivery status in portal
SfaxHIPAA audit log (vendor-held)
ConsensusCertified PDF receipt
FaxSealECDSA signature + Rekor logSHA-256 hashed
Section 9

Conclusion

The fax industry has operated on a thirty-year-old trust model: the vendor confirms delivery, the vendor generates the receipt, the vendor holds the audit log. For most use cases this has been acceptable. For healthcare, legal, and government use cases — where the question is not “did it send?” but “can you prove it in court or to a regulator?” — it is not.

Cryptographic transparency logs, proven in the software supply-chain security community, provide the missing piece: proof that exits vendor control at the moment of creation, is permanently logged to an independent append-only ledger, and is verifiable by any party with standard tools and no vendor relationship.

FaxSeal Fax Attestation is the first implementation of this model in the fax industry. It is available today on the Enterprise plan and via the Partner API.

The one-sentence claim: for the first time in the industry, fax delivery proof is independently verifiable — logged to a public transparency log that no vendor, including FaxSeal, can alter.

See Fax Attestation in action

Watch the interactive demo, read the technical overview, or contact us to activate for your organization.