Skip to content
Circadify Circadify Circadify

Encryption

All data handled by Circadify is encrypted in transit. Persistent stores are encrypted at rest.

Encryption in Transit

Section titled “Encryption in Transit”

All communication with the Circadify API is encrypted using TLS.

  • Protocol: TLS 1.3 (TLS 1.2 supported for backward compatibility)
  • Cipher suites: Strong AEAD ciphers with forward secrecy
  • HSTS: Enforced on all responses with max-age=31536000; includeSubDomains; preload
  • Security headers: Every response includes X-Content-Type-Options: nosniff, X-Frame-Options: DENY, Content-Security-Policy: default-src 'none'; frame-ancestors 'none', and Cache-Control: no-store, no-cache, must-revalidate, private

Encryption at Rest

Section titled “Encryption at Rest”

All persistent data stores use encryption at rest:

  • Account database — AES-256 encryption at rest for developer accounts, API key hashes, audit logs, and usage records.
  • Object storage — Server-side encryption for the upload pipeline. Uploaded tensors are processed and discarded; nothing health-related persists.
  • Key management — Encryption keys are managed by a dedicated key-management service with automatic rotation.

Hybrid Architecture and Data Protection

Section titled “Hybrid Architecture and Data Protection”

The SDK extracts processed RGB data from skin regions on-device, then uploads it over TLS to our inference engine. Raw video and raw camera frames never leave the device. The uploaded RGB tensor cannot be played back as video and contains no identifiable imagery.

After inference, the tensor is discarded and the vital sign results are returned to the client over TLS. Results are not stored on our side. The only persisted artifact of a scan is a usage record (one scan credit consumed) used for billing and quota.

Key & Secret Management

Section titled “Key & Secret Management”

Circadify uses distinct cryptographic approaches for different types of secrets:

  • API keys — Generated using cryptographically secure random bytes and stored as one-way hashes. Only the key prefix is retained in plaintext for identification. The full key is shown once at creation and never stored.
  • Passwords — Developer account passwords are hashed with bcrypt before storage. Raw passwords are never logged or persisted.
  • Session tokens — Generated using a CSPRNG and stored as hashes with a short TTL.
  • Application secrets — Internal service credentials are stored in a managed secrets service with automatic rotation.

Next Steps

Section titled “Next Steps”