Beskos
Get started

Security

How we protect your data

The technical and organisational measures in force. This page describes what is implemented; the relevant limitations are set out in Annex II to the Data Processing Agreement.

Last updated:

Encryption

  • All connections are encrypted in transit with TLS, using certificates issued by a public certification authority: the application, the API and the mail protocols (SMTP, IMAP and JMAP).
  • Files in Drive, documents and meeting recordings are encrypted by us, before they reach the storage provider, with AES-256-GCM. The provider stores ciphertext and holds no key that opens it.
  • Each organisation has its own key, held in the European Union and wrapped by a master key that lives only in the environment of the running service. Deleting an organisation's key makes every file belonging to it unreadable at once — a stronger guarantee than deleting rows.
  • This protects your files from the storage provider and from anyone who obtains a copy of the storage. It is not end-to-end encryption: we hold the keys, because the service produces previews, edits documents in the browser and serves shared links. We would rather say so than let the word 'encrypted' imply otherwise.
  • Mail is not yet covered by this measure. Message content is held by the mail server, which reads and writes it directly and does not pass through the layer described above. It is protected in transit by TLS and at rest by the provider's own encryption and by the access controls below. Extending our own encryption to it is work in progress, not something we claim today.
  • Two-factor authentication secrets are encrypted in the database with a key held outside it.

Access control

  • Account passwords are stored as bcrypt hashes. Mailbox credentials are held by the mail server and are never stored in plaintext.
  • Password strength is measured at the point of choosing one and weak passwords are refused — both by us and by the mail server itself.
  • Two-factor authentication is available to everyone and can be required across an organisation.
  • Access to data within the service is governed by roles and per-resource permissions. Every query for customer data is constrained to the organisation of the authenticated user — it is a condition in the query, not a check on the screen.
  • Administrative access to production infrastructure is restricted to authorised personnel and protected by key and second factor.

Application security

  • Session cookies travel only over HTTPS and are not accessible to scripts. State-changing requests require a header that a cross-site request cannot set.
  • Authentication endpoints are rate-limited, to frustrate brute force and the reuse of stolen credentials.
  • Secrets and credentials reach the system through the environment and do not live in the source code.
  • The mail server's administration interface is not exposed to the internet.

Separation between customers

  • The service is multi-tenant. Each organisation's data is separated logically: every record carries the identifier of the organisation that owns it, and every query is constrained by it.
  • Mailboxes are separate accounts on the mail server, isolated from one another by its own controls.

Backups

  • The application and mail databases — the latter holding accounts, mailbox configuration and message data — are backed up regularly to object storage under European jurisdiction.
  • Object storage itself is not separately backed up. Files in Drive, meeting recordings and the original of each mail message with its attachments rely on the durability of the storage provider; there is no second copy under our control. We state this rather than let the word 'backups' cover everything.
  • Backups are encrypted before they leave the server, with an asymmetric key: the server carries only the public half, so it can write new backups and cannot read old ones. The private half is held outside the production infrastructure.
  • Each backup is verified as readable before it is encrypted and stored, and the restore procedure is tested from an encrypted copy — including the check that the copy cannot be read without the private key.

Monitoring

  • The availability of each component is measured continuously from outside the infrastructure and published at status.beskos.com.
  • Administrative access and sensitive operations are logged.

Development

  • Changes to the software are version-controlled, reviewed before release and deployed through an automated pipeline; the history is retained.
  • Dependencies are pinned by version and images are built by us from known sources.

Reporting a vulnerability

  • Write to security@beskos.com. We acknowledge reports within five working days.
  • We do not pursue researchers who act in good faith and do not access, alter or retain other people's data. We ask for time to fix an issue before it is made public.