Skip to main content
This page covers Firma’s technical and organizational security posture. For the legal standing of Firma’s electronic signatures under eIDAS, ESIGN, and UETA, see Legal Validity & eIDAS Compliance.
Quick answer: Firma’s infrastructure runs entirely in the EU, with encryption in transit and at rest, row-level access control on every database table, and a signing process backed by a full audit trail. Firma’s security practices align with SOC 2 and ISO 27001 frameworks. Firma does not run a formal bug bounty program. Security reports are welcomed and acted on. Details below.

​
Infrastructure overview

Firma’s platform is built on a small set of managed providers, each running in the EU: There’s no self-managed server fleet — every component above is a managed cloud service, so patching, network isolation, and physical security are handled by Supabase and AWS’s own security programs, not by Firma’s own hardware.

​
Data residency

All Firma infrastructure runs in EU data center regions, with no fallback or replication outside the EU:
  • Supabase (database, storage, edge functions): eu-west-3 — Paris, France
  • AWS Lambda (signing API, certificate generation): eu-west-3 — Paris, France
  • DSS (digital signature sealing): eu-north-1 — Stockholm, Sweden
  • Resend / Amazon SES (email delivery): EU region — signer-facing emails (invitations, reminders) transit through Resend’s infrastructure
Signing request documents, signer data, and account data are stored and processed exclusively within these regions. If your organization has a data residency requirement that specifies the EU, Firma’s default deployment already satisfies it — there’s no separate “EU region” tier to opt into.

​
Encryption

In transit: All communication with Firma — the dashboard, the signing pages, the API, and every internal service-to-service call shown in Firma’s architecture overview — is over HTTPS/TLS. Outbound webhooks are additionally signed with HMAC-SHA256 so the payload’s integrity and origin can be verified independently of transport-layer security; see Webhooks. For the full list of Firma’s services and how they communicate, see Multi-Tenant Architecture. At rest: Database storage (Postgres) and file storage (signed documents, templates, certificates) are encrypted at rest using Supabase’s and AWS’s default encryption for their respective services. This is provider-managed encryption at the storage layer, not an application-level encryption scheme Firma implements itself.

​
Authentication and access control

  • User authentication is handled by Supabase Auth, supporting email/password and OAuth sign-in.
  • Passkey (WebAuthn) authentication is available as an alternative to passwords.
  • Row-Level Security (RLS) is enabled on every database table containing tenant data. Access to a row is enforced at the database layer based on the requesting user’s company and workspace membership — not just at the application layer — so a bug in application code can’t by itself expose one tenant’s data to another.
  • API access uses per-workspace API keys with rate limiting, independent of dashboard session authentication. See Authentication.
  • Signing-time access for recipients uses a unique per-signer link (valid until the signing request expires — default 7 days). An optional one-time-passcode (OTP) verification step can be enabled per workspace or per signing request to require a code-based identity check before granting a session.

​
Compliance status

Firma’s security practices align with SOC 2 and ISO 27001 frameworks:
  • SOC 2 alignment. Firma’s infrastructure, access controls, and data handling practices are designed around the SOC 2 Trust Services Criteria (security, availability, confidentiality).
  • ISO 27001 alignment. Firma follows an information security management approach consistent with ISO 27001 controls.
  • No formal penetration test report available for distribution. Security review happens on an ongoing basis (see Responsible disclosure below), but there is no third-party pen test report currently available to share with prospective customers.
For the legal-validity side of compliance — eIDAS signature tiers, ESIGN/UETA, and country-specific rules — see Legal Validity & eIDAS Compliance. That page also covers SOC 2/ISO 27001 alignment in the context of signature legal weight.

​
Data Processing Agreement (DPA)

A Data Processing Agreement is available on request for customers who need one under GDPR or a similar data-protection framework. Contact support@firma.dev to request one.

​
Responsible disclosure

Firma does not run a formal, published bug bounty program. That doesn’t mean security reports go unheard — they’re read, triaged, and acted on. If you believe you’ve found a security vulnerability in Firma:
  • Email support@firma.dev with a description of the issue, steps to reproduce, and any relevant request/response details.
  • Please report privately rather than disclosing publicly first, and avoid testing against other customers’ data or accounts.
  • Firma does not currently commit to a fixed response-time SLA for security reports, but reports are prioritized above routine feature work when a real vulnerability is confirmed.
Firma reviews and responds to security reports on an ongoing basis, and confirmed issues have led to fixes; in at least one case, a reporter received a discretionary bounty payment outside of any formal program. This is handled case by case rather than through a published bounty schedule.