Security
The answers your vendor review will ask for
We are asking you to let customer mail pass through Fromenance, so we finished the security work before we asked anyone to pilot communication provenance with us. This page answers the questions a bank's third party risk review asks, in the order they usually ask them: what we store, how long we keep it, how tenants are kept apart, and who our subprocessors are. The DPA makes all of it contractual.
Data
What you store about our customers
Do you receive our customers' email addresses?
Not on the API path. Your application hashes the lowercased, trimmed address with your tenant secret and sends us only the hash. Our communications table has no column for an address. Where we have to see one, on a forward or through the journal path, it is encrypted with a key specific to your tenant and purged 30 days after use.
What happens to the forwarded messages?
The raw MIME of every submission goes into R2 under your tenant's prefix, encrypted with a tenant scoped key that lives in Workers secrets and rotates yearly. We keep it for your retention window, 90 days by default, and then delete it and write a deletion record to the audit log.
Can a fingerprint be turned back into a message?
No. We hold the normalized text only long enough to compute a SimHash and a SHA-256, and we do not persist it. Fingerprints are one way.
Does the reply repeat the suspicious message?
Never. The verdict reply does not quote the message, does not include its links, and does not name its sender. The verdict block is locked text.
What can you see across tenants?
Indicators and counts. Our backoffice intelligence view, and the network layer on the roadmap, never touch submissions, raw MIME, or content.
Where is the data?
In the United States, all of it, in v1. Our subprocessors are listed below and in the DPA.
Retention
What we keep, and for how long
| Data | Form | Retention |
|---|---|---|
| Registered communication | Verify code, recipient HMAC, SimHash and SHA-256 fingerprint, message id, From address, sent time, link domains, template and campaign ids | Your retention window, default 90 days |
| Forwarded or uploaded message | Raw MIME or screenshot, encrypted in R2 under your tenant prefix | Your retention window, default 90 days, deleted with an audit record |
| Submitter address | HMAC for matching; encrypted copy for the reply only | Encrypted copy purged 30 days after the reply |
| Verdict | Outcome, rule, signals, matched registration id, override trail | Life of your account |
| Indicators | Kind, normalized value, first and last seen, counts | Life of your account |
| Rejected inbound | Mail that failed the trust check, with the reason | 24 hours |
| Audit log | Actor, action, target, before and after | Life of your account |
Trust and abuse
How you stop it being gamed
How do you know a forward really came from us?
We drop mail to your tenant inbox unless the sending hop passes DKIM or ARC for a domain you own with a valid _fromenance TXT token. Rejected mail is held 24 hours so we can diagnose it, then deleted.
What if someone copies a real verify code?
A valid code on the wrong message or the wrong recipient comes back Not verified for the customer and raises a high priority replay flag for you.
How is the verify page protected from abuse?
Rate limited per IP (60 per minute) and per site key, only from an origin you allow, and escalated to Cloudflare Turnstile when a site key exceeds its normal rate.
Could someone poison our fraud list?
Anyone can forward anything to your inbox through your own rule, so fraud list entries come only from an analyst's action or, on the roadmap, a confirmed campaign. Never automatically from a single submission.
Is there an LLM anywhere in the verdict?
No. Extraction is regex, MIME parsing, and SimHash; matching is an HMAC comparison and a Hamming distance. Screenshot OCR runs in Workers AI and its output is untrusted text that only feeds those extractors. Any future lure classifier produces a fixed schema label and can never change a verdict from Verified.
How do you handle replayed or duplicate requests?
Every provider webhook signature is verified with a 5 minute replay window. Every creating call takes an idempotency key we keep for 24 hours.
Platform
How the platform itself is secured
How do your staff and ours sign in?
Admin app users sign in with Better Auth using email magic link and passkeys. Our backoffice sits additionally behind Cloudflare Access with a hardware key requirement. SSO (SAML and OIDC) is on the roadmap.
How are keys handled?
API keys are hashed at rest, shown once, scoped (register, read, admin), revocable, and tracked by last use. Site keys are public, tied to your tenant and your page's origin, and carry no secret.
How are tenants kept apart?
Every tenant owned table carries a tenant id and every query goes through a scoped repository that requires it. R2 prefixes are per tenant. An automated suite asserts that no endpoint reads across tenants, on every change.
What is encrypted, and with what?
Encrypted columns hold AES-256-GCM ciphertext produced with a per tenant data key wrapped by a master key that lives only in Workers secrets. TLS everywhere. Secrets never appear in configuration or source.
Is there an audit trail?
Every write in the admin app and the backoffice is logged with actor, action, target, before, and after. When our operators look at your tenant, it is read only and audited.
How do you run the platform?
Secrets live in Workers secrets only. Neon and R2 credentials rotate quarterly. Dependencies are scanned. Deploys happen only from CI on the main branch. We watch it through Workers Logs, Analytics Engine, and Sentry.
Subprocessors
Who else touches the data
At runtime, nothing runs outside Cloudflare, Neon, and Resend. Stripe holds billing and Sentry receives error events. We tell tenants 30 days before we add anyone, as the DPA describes.
| Subprocessor | Purpose | Location |
|---|---|---|
| Cloudflare, Inc. | Hosting, edge compute, edge storage (D1, R2, Queues), Workers AI for screenshot OCR, Turnstile | United States |
| Neon, Inc. | Postgres system of record | United States |
| Resend, Inc. | Inbound and outbound email | United States |
| Stripe, Inc. | Billing | United States |
| Functional Software, Inc. (Sentry) | Error monitoring | United States |
Compliance
SOC 2 and disclosure
Where are you on SOC 2?
We are targeting SOC 2 Type 1 within 12 months of our first paying tenant. Until then, this page, the DPA, and a completed vendor security questionnaire are what we offer your third party risk review. Send us yours and we will fill it in.
How do we report a vulnerability?
Email security@fromenance.com. We acknowledge within two business days, keep you informed, and do not pursue researchers who act in good faith, avoid privacy violations and service disruption, and give us reasonable time to fix. Please do not test against tenant inboxes or production tenant data; the demo tenant on this site is there for that.
If we confirm a security incident that touches your data, we tell you without undue delay and no later than 72 hours after we confirm it.
Send us your vendor security questionnaire.
We answer it against this page and the DPA. If your review would rather start without any mail routing at all, the web verify page needs none.