Security

What we hold, and what we do not

CROapps Oy does not hold a SOC 2 report or an ISO 27001 certificate. We would rather say so here than let a sales conversation discover it later. If your procurement process requires one, tell us: it changes our roadmap, and it is the kind of commitment we would rather make against a real customer than in the abstract.

What we do have is a published Data Processing Addendum incorporating the Standard Contractual Clauses, a complete sub-processor list, and the description below. On Startup and Enterprise we will also answer a security questionnaire and walk your reviewer through the architecture.

Where your data is

The application, object storage, and queues run on Cloudflare. The database is Neon, in the United States. Mail is sent and received through Amazon SES in eu-north-1 (Stockholm), and inbound messages pass through Amazon S3 in the United States on their way to us.

We are a Finnish company and the contract is governed by Finnish law, but the data itself is processed in the United States under the Standard Contractual Clauses. EU data residency is on the roadmap and is not something we offer today. Anyone who tells you otherwise about us is reading an old page; the sub-processor list is the authority.

Encryption

• – Everything in transit is TLS. The API, the MCP server, the dashboard, and the tunnel relay have no plaintext listener.
• – Data at rest is encrypted by the underlying providers: Neon for the database, Cloudflare R2 for raw messages and attachments.
• – The vault is end-to-end encrypted. Secrets are encrypted in your browser or your process with a key we never receive, and the server holds only ciphertext, a salt, and a verifier. We cannot read a vault secret, and neither can anyone who obtained the database.
• – API keys are stored only as hashes. A key is shown once, at creation, and cannot be recovered from us afterwards.
• – There are no account passwords to store. Signing in is a single-use link sent to your address, or a passkey, so there is no password hash for a breach to expose and nothing to reuse from one.
• – Webhook deliveries are signed with HMAC-SHA256 over a timestamp and the body, so a receiver can tell our delivery from a forgery.

Tenant isolation

Every query is scoped to a workspace at the data layer rather than in the interface. An API key resolves to one mailbox in one workspace, and the scoping is asserted by tests that specifically try to read one workspace with another workspace's credentials.

Free mail leaves through a different Amazon SES configuration set and IP pool than paid mail, so a bad free cohort cannot damage the sending reputation of paying customers.

Access and audit

• – Access to production data is limited to the people who run the service.
• – Two-factor authentication is available on every plan, as a code from an authenticator app with one-time backup codes, or as a passkey. We do not offer second-factor codes by email, because a code sent to the same mailbox the sign-in link arrived in guards nothing.
• – Sign-in attempts are rate limited by network address and by account, so neither a single host asking for links in bulk nor a distributed attempt on one address gets an unlimited number of tries.
• – We email you when your account is signed into from a country or a browser it has not used before, and when repeated sign-in attempts against your address are refused. Your last fifteen sign-ins are on the security page. Changes that hand over control of a workspace, meaning a transfer, a new admin, single sign-on removed, or the vault exported, email the workspace as they happen.
• – Administrative actions inside a workspace are recorded with who did them and when: members added and removed, inboxes and domains created, API keys created and revoked, plan and spend-cap changes, and single sign-on configuration. Workspace owners can read that trail themselves on Startup and above.
• – Single sign-on, with SAML 2.0 or OIDC, is available on Enterprise, so joiners and leavers are governed by your identity provider rather than by us.
• – Deleting an account erases its workspaces, its mail, and the objects behind them, and there are automated checks that fail if anything is left behind.

What we do not do

We do not read message content. Abuse enforcement is behavioural: sending velocity, duplicate-content patterns, bounce and complaint rates, and the spam and virus verdicts Amazon SES already attaches. Model or manual review happens only on a workspace that has tripped one of those, only on flagged samples, and only before it is unpaused.

We do not use your data to train models, and we do not sell it or share it for advertising.

Retention

On the free plan, messages are kept for 30 days and then deleted, along with the stored objects nothing else points at. Paid plans keep messages until you delete them or close the account.

Abuse-detection records used for duplicate detection are pruned on a rolling window, and the audit trail is kept for 90 days.

Reporting a vulnerability

Use the contact form and pick the security topic. Tell us what you found and how to reproduce it, and give us a reasonable window to fix it before publishing.

We will confirm receipt, keep you updated, and credit you if you want the credit. We do not run a paid bounty programme, and we will not threaten you for reporting something in good faith.

If something goes wrong

We notify affected customers of a personal data breach without undue delay and within 48 hours of becoming aware of it, with what happened, what data was involved, and what we are doing about it. That commitment is in the Data Processing Addendum, which is the contractual version of this page.