Legal and compliance

Security

Updated: 21 July 2026

We design TrustFlare around security. This page describes our technical and organizational measures. See [ISO 27001 and infrastructure](/legal/iso/) for our certification position.

Our approach

We start with threats: minimal default trust, limited data collection and a small attack surface. Sensitive decisions such as device trust are verified cryptographically rather than accepted from client self-reporting.

Architecture and attack surface

  • Self-hosted device facts, access decisions and logs remain in customer infrastructure. We have no access by default.
  • The core API listens on loopback by default. The public demo is behind the access gate and Cloudflare Tunnel, without host-published ports.
  • The public website is static on Cloudflare Pages. Dynamic functionality is limited to serverless forms for leads, data requests and security reports, without SSH or a persistent application server.

Secure development

  • Specification before implementation: contracts and domain changes are documented before code.
  • Authentication and secrets changes require both code and security reviews.
  • Quality checks include strict typing, linting, test coverage and documentation.
  • Dependency hygiene and reproducible builds use lockfiles and pinned images.

Technical measures

  • HTTPS/TLS for external traffic, terminated at Cloudflare.
  • Detached Ed25519 signatures over RFC 8785 canonicalized device data protect integrity in transit.
  • Device-bound WebAuthn passkeys: cloud-synced keys are rejected and user verification is required.
  • One-use challenges and fresh nonces prevent replay; the browser polling secret is excluded from deep-link URLs.
  • Constant-time comparisons, attempt limits, expiry and one-use codes protect confirmations.
  • Sensitive endpoints are rate-limited. Secrets are stored in SOPS or Cloudflare secrets rather than Git.
  • Environment container isolation uses gVisor, non-root execution, read-only filesystems, dropped capabilities and no-new-privileges.

Release signing and contents

Agent releases include an SPDX software bill of materials and a signed update manifest. The agent embeds the minisign public key. The Linux repository key is trustflare-packages.asc. Windows Authenticode awaits a legal-entity certificate.

  • Latest release SBOM: TrustFlare agent SPDX.
  • Checksums and signature: SHA256SUMS.txt and SHA256SUMS.txt.minisig.
  • Verify with `minisign -Vm SHA256SUMS.txt -p <public-key>`; Linux repository: `deb [signed-by=/usr/share/keyrings/trustflare.gpg] https://dl.trustflare.tech/linux/apt stable main`.

Organizational measures

  • Least privilege and separation of access.
  • MFA for critical systems. SOPS/age keys are stored in Apple Secure Enclave; CI keys are separate from working keys.
  • Separate production and stage environments; third parties have no infrastructure access by default.

Compliance

Measures are mapped to ISO/IEC 27001 objectives. See ISO 27001 and infrastructure, GDPR and Russian personal-data policy.

Incident response

Our process covers detection, containment, remediation, notification and review. Regulatory notification timelines are:

  • Roskomnadzor under 152-FZ: initial incident notification within 24 hours and internal investigation results within 72 hours.
  • GDPR Articles 33–34: supervisory-authority notification within 72 hours, and data-subject notification where their rights face a high risk.

Report a vulnerability

Tell us about a security issue

Reports go directly to TrustFlare. If you provide an email, we will reply within three business days.