Security
mintfax is a developer-first fax service, and every security control on this page is available at every tier. Encryption at rest and in transit, structural API key scoping, a tamper-evident audit log, HMAC-signed webhooks, and a named vulnerability-reporting channel are on every account regardless of tier.
Controls
| Control | Mechanism | Details |
|---|---|---|
| Encryption at rest | AES-256 envelope encryption, mintfax-managed keys, KMS automatic rotation | /compliance |
| Encryption in transit | TLS 1.2 minimum on API and outbound webhooks; plain HTTP endpoints rejected at registration | /compliance |
| API authentication | Opaque bearer tokens; session authentication for the dashboard, separate from API keys | /docs/authentication |
| API key scoping | mfx_test_, mfx_live_, mfx_acct_; sandbox cannot reach live resources by construction | /docs/keys |
| Webhook integrity | HMAC-SHA256, Standard Webhooks specification, three signature headers on every delivery | /docs/authentication |
| Audit log | Two-stream, tamper-evident hash chain, customer-exportable via GET /v1/account/audit | /compliance |
| PHI retention and delete | 30-day default (7 to 365 days configurable), zero-footprint mode, DELETE /faxes/{id}/content | /compliance |
| Vulnerability reporting | [email protected], one-business-day response | See below |
Encryption
Fax content is stored with envelope encryption under mintfax-managed keys, one content encryption key per environment, rotated automatically by the KMS. Content encryption uses AES-256; the database itself sits behind cloud-provider at-rest encryption on top of that.
Inbound API calls and outbound webhook delivery use TLS 1.2 minimum. Webhook endpoints registered with plain HTTP are rejected at registration time.
Encryption keys are mintfax-managed. Customer-managed keys (BYOK) are not offered.
Authentication and API key scoping
API keys are opaque bearer tokens. Three key prefixes identify the scope of the request:
mfx_test_- sandbox-environment-scoped, operationalmfx_live_- live-environment-scoped, operationalmfx_acct_- account-scoped administrative; manages billing, members, and keys
A sandbox key cannot reach live resources by construction. Account keys can only be created in the dashboard; API-driven creation returns acct_key_creation_dashboard_only. The dashboard uses session-based authentication, separate from API key authentication.
Rotation follows a generate-then-revoke pattern: create a new key, update the application, revoke the old key. Both keys work simultaneously during the transition. Revocation is effective on the next request; a revoked key returns api_key_invalid.
Webhook integrity
Every webhook delivery is signed with HMAC-SHA256, following the Standard Webhooks specification. Three headers accompany every payload: webhook-id, webhook-timestamp, webhook-signature. Receivers should reject signatures whose timestamp drifts more than five minutes from their own clock.
Webhook signing secrets are per-endpoint, whsec_ prefix, shown once at creation, and rotated atomically through a regenerate action. Standard Webhooks verifier libraries accept multiple secrets, so rotation is coordinated without an outage window: add the new secret to the verifier first, regenerate, then remove the old secret once the customer is confident.
Audit log
The audit stream is the security-relevant log, separated from the operational stream used for debugging and pipeline context.
Read events for PHI content access land in the audit stream: API content downloads, dashboard “View content” clicks, and any mintfax personnel action that renders customer PHI in support tooling. Personnel-access rows carry a pseudonymous staff identifier and a mandatory reason field, and are visible in the customer’s audit feed.
Each row carries prev_hash and row_hash fields; row_hash = SHA-256(prev_hash || canonical_serialize(row_payload)). The chain is verifiable end-to-end from a deterministic genesis hash, against a published reference verifier.
Customers export the stream over HTTP via GET /v1/account/audit (paginated JSON, account-scoped, cross-environment with a filter) or download CSV from the dashboard. Both responses include the hash-chain fields. Retention is fixed at six years from row creation to match HIPAA 45 CFR 164.530(j)(2).
PHI content controls
PHI content retention defaults to 30 days, customer-configurable per environment in the range 7 to 365 days. Zero-footprint mode is a per-environment toggle; when enabled, PHI is scrubbed the moment a fax reaches a terminal state (fax.delivered or fax.failed). Operational metadata is preserved. Active per-fax deletion is available at any time via DELETE /faxes/{id}/content; the fax resource itself remains queryable with PHI fields nulled.
The full PHI boundary and BAA-covered scope live on /compliance.
Frameworks mintfax does not hold
mintfax does not hold SOC 2, ISO 27001, HITRUST, FedRAMP, or PCI DSS Level 1. These are not offered.
mintfax does not claim end-to-end encryption. The T.30 protocol is not encrypted, and the carrier and recipient legs sit outside mintfax control. Customer-managed encryption keys (BYOK) are not offered. Storage is single-US-region; region selection is not available today. IP allowlisting, per-resource key permissions, key auto-expiration, and JWT or OAuth authentication are also not offered.
Report a vulnerability
Send reports to [email protected]. The alias carries a one-business-day response.