---
title: "Encryption at Rest + In Transit: CallSphere vs Vapi Defaults"
description: "TLS 1.3, AES-256, and KMS-backed key management — what defaults ship with CallSphere vs the patchwork you assemble for Vapi."
canonical: https://callsphere.ai/blog/encryption-at-rest-in-transit-callsphere-vs-vapi
category: "Technical Guides"
tags: ["Encryption at Rest", "TLS 1.3", "AES-256", "Vapi vs CallSphere", "Key Management", "Voice AI Security"]
author: "CallSphere Team"
published: 2026-04-18T00:00:00.000Z
updated: 2026-04-27T20:37:19.070Z
---

# Encryption at Rest + In Transit: CallSphere vs Vapi Defaults

> TLS 1.3, AES-256, and KMS-backed key management — what defaults ship with CallSphere vs the patchwork you assemble for Vapi.

## TL;DR

Encryption is now table-stakes for any compliance posture: HIPAA Security Rule technical safeguards, SOC 2 CC6.7 and CC6.8, GDPR Art. 32, PCI-DSS 4.0. The defaults matter — auditors examine "what ships out of the box" because customer drift from defaults is a common audit finding. CallSphere ships with **TLS 1.3 in transit, AES-256 at rest, KMS-backed keys, and per-tenant database isolation**. Vapi.ai's encryption posture is the union of what each upstream vendor (STT, LLM, TTS, telephony) and the customer's own glue code happen to enable. This post shows the encryption layer model, where each platform fits, and what to ask in procurement.

## Why Encryption Defaults Matter

Most security failures come from misconfiguration, not algorithm weakness. AES-256 has been NIST-approved for 25+ years; the breaches happen because:

- TLS 1.0/1.1 is left enabled on a legacy load balancer
- A debug bucket is created without server-side encryption
- A new microservice forgets to use the corporate KMS
- A vendor's "free tier" downgrades encryption silently

A platform with **strong defaults** removes most of these risks before a customer engineer can introduce them. A platform with **per-component customer-configured encryption** maximizes them.

## Encryption Layers in a Voice AI System

A voice AI call has at least seven encryption-relevant layers:

1. **Caller-to-carrier**: SRTP / TLS — controlled by the carrier
2. **Carrier-to-platform**: SIP TLS — controlled by the platform
3. **Platform-to-STT**: HTTPS / WebSocket — controlled by the platform
4. **STT-to-LLM**: HTTPS — controlled by the platform
5. **LLM-to-TTS**: HTTPS — controlled by the platform
6. **TTS-to-platform**: HTTPS — controlled by the platform
7. **Platform-to-storage**: at-rest encryption (S3 SSE / RDS) — controlled by the platform

Plus admin / dashboard / API access (HTTPS), database connections (TLS), backup encryption, and key management.

## CallSphere Defaults

| Layer | Default |
| --- | --- |
| Caller→carrier (Twilio) | SRTP / SIP-TLS |
| Carrier→CallSphere | TLS 1.3 |
| Internal service-to-service | TLS within K8s service mesh |
| LLM provider | TLS 1.3 |
| Database connections | TLS 1.3 (Postgres SSL required) |
| Storage at rest | AES-256 (S3 SSE or RDS encryption) |
| Backup encryption | AES-256 |
| Dashboard access | TLS 1.3 + JWT |
| Admin API | TLS 1.3 + JWT + RBAC |
| Key management | AWS KMS / equivalent regional KMS |
| Cipher suites | Modern only (no SHA-1, no RC4, no 3DES) |

These are not toggles — they are the only enabled options.

## Vapi DIY Posture

Vapi customers must verify encryption per layer per vendor, and may discover:

- TTS vendor offers HTTPS but no TLS 1.3 enforcement
- STT vendor allows plaintext on a low-latency path
- LLM vendor's enterprise tier defaults to TLS 1.2
- Vapi's own internal storage encryption is unclear without disclosure
- Customer's storage bucket may not have server-side encryption enabled by default

The customer's audit obligation is to **verify and document** each of these. Misses become findings.

## Mermaid: Encryption Layers

```mermaid
graph TB
  CALLER[Caller Phone] -->|SRTP/SIP-TLS| TWILIO[Twilio Carrier]
  TWILIO -->|TLS 1.3| CSP[CallSphere Edge]
  CSP -->|mTLS| AGENT[Voice Agent Service]
  AGENT -->|TLS 1.3| STT[STT Provider]
  AGENT -->|TLS 1.3| LLM[LLM Provider]
  AGENT -->|TLS 1.3| TTS[TTS Provider]
  AGENT -->|SSL| DB[(Postgres TLS)]
  DB -. AES-256 SSE .- KMS[AWS KMS]
  AGENT -->|HTTPS+JWT| DASH[Dashboard]
  DASH -->|RBAC| OPS[Ops User]
  AGENT -. AES-256 .-> S3[(S3 Recordings)]
  S3 -. SSE-KMS .- KMS
```

Every edge in the diagram is encrypted, and the keys for at-rest data are KMS-managed.

## Comparison Table

| Encryption Capability | Vapi DIY | CallSphere |
| --- | --- | --- |
| TLS 1.3 enforced everywhere | Per-vendor verify | Default |
| AES-256 at rest | Per-vendor verify | Default |
| Customer-managed keys (CMK) | Per-vendor | Available via KMS |
| Database TLS required | Customer-configured | Required |
| Backup encryption | Customer-configured | Default |
| Cipher hardening | Per-vendor | Default modern-only |
| Key rotation policy | Per-vendor | Documented |
| Cross-component mTLS | Build yourself | Available |
| FIPS 140-2 endpoints | Per-vendor | Available on request |
| Audit log encryption | Per-vendor | Default |

## Procurement-Friendly Encryption Checklist

1. Is TLS 1.3 enforced for all customer-facing endpoints?
2. Are TLS 1.0 and 1.1 explicitly disabled?
3. Is AES-256 the at-rest default for primary database, recordings, and backups?
4. Are customer-managed keys (CMK) supported via KMS?
5. What is the documented key rotation cadence?
6. Are administrative interfaces protected by mTLS or strong identity binding?
7. Are cipher suites restricted to a modern allowlist?
8. Are all sub-processor links encrypted with documented protocols?
9. Are there any plaintext debug paths in non-production?
10. Are encryption settings part of the SOC 2 / HIPAA scope?

## Key Management Notes

CallSphere uses AWS KMS (and regional equivalents) for at-rest encryption keys. CMKs can be customer-owned for enterprise customers. Key access is logged via AWS CloudTrail, satisfying the "encryption logging" controls in SOC 2 and HIPAA.

In a Vapi-based stack, each upstream vendor brings its own key management. Reconciling these into a single audit narrative is non-trivial — and a misconfigured S3 bucket on the customer's side is a classic finding.

## Real-World Audit Example

A 2025 SOC 2 audit of a healthcare technology company using a Vapi-style multi-vendor stack found:

- TTS vendor used TLS 1.2 by default; no enforcement of 1.3
- One internal microservice connected to Postgres without SSL during a rolling upgrade window
- Backup encryption was enabled but used a single KMS key shared across environments

Two findings led to qualified opinions. Remediation took 4 months. CallSphere's defaults would have prevented all three.

## CTA

Encryption is the easiest control to get wrong by accident. [Book a CallSphere demo](/demo) and ask for our encryption-defaults summary. Or visit our [pricing](/pricing) for plan tiers.

## FAQ

### Does CallSphere support customer-managed encryption keys?

Yes. Enterprise plans support CMK via AWS KMS, with documented key access auditing.

### What about FIPS 140-2 validated cryptography?

FIPS 140-2 validated endpoints are available on request for federal and state government workloads.

### Are recordings encrypted with the same key as transcripts?

By default they share a per-tenant master key, with separate data keys per object envelope-encrypted. Enterprise customers can use distinct CMKs per data class.

### Is mTLS used between internal services?

Yes — internal service-to-service traffic in CallSphere's K8s mesh uses mTLS where supported, with strict cipher suites.

### How often are TLS configurations re-tested?

CallSphere runs continuous TLS configuration scans (Mozilla Observatory / SSL Labs equivalents) on customer-facing endpoints, with results reviewed monthly.

## Deep Dive: Cipher Suite Hardening

Modern TLS deployments benefit from explicit cipher suite restrictions, not just version restrictions. CallSphere's TLS termination points enforce:

**TLS 1.3 cipher suites (allowed):**

- TLS_AES_256_GCM_SHA384
- TLS_CHACHA20_POLY1305_SHA256
- TLS_AES_128_GCM_SHA256

**TLS 1.2 cipher suites (allowed for legacy carrier interop only):**

- ECDHE-ECDSA-AES256-GCM-SHA384
- ECDHE-RSA-AES256-GCM-SHA384
- ECDHE-ECDSA-CHACHA20-POLY1305
- ECDHE-RSA-CHACHA20-POLY1305

**Disabled across the board:**

- All TLS 1.0 / 1.1 cipher suites
- All RSA key exchange (no PFS)
- All CBC mode ciphers
- All RC4, 3DES, MD5, SHA-1 hashes
- Export-grade ciphers

This list passes Mozilla's "Modern" recommendation as well as PCI-DSS 4.0 cipher requirements.

## Key Rotation Cadence

Documented rotation cadence at CallSphere:

| Key Type | Cadence | Method |
| --- | --- | --- |
| TLS certificates | 90 days | Automated via ACM / Let's Encrypt |
| Database encryption master key | Annual (or on personnel change) | KMS-managed |
| Application JWT signing key | Quarterly | Automated rollover with grace period |
| API keys (customer) | Customer-controlled | Self-service rotation |
| KMS data keys | Per-object envelope | AWS KMS-managed |
| SSH keys (operator access) | 90 days | Centralized key management |
| Backup encryption keys | Annual | Managed alongside DB keys |

## At-Rest Encryption Layers

A single piece of customer data may be encrypted at multiple layers:

1. **Application-layer field encryption** for the most sensitive fields (e.g., insurance numbers) — encrypted before insert
2. **Database-level transparent encryption** (RDS encryption-at-rest)
3. **EBS volume encryption** (cluster storage)
4. **S3 server-side encryption** for objects (SSE-KMS)
5. **Backup encryption** at the snapshot level

The layered design means a single layer compromise does not expose plaintext.

## Quantum-Resistant Cryptography Roadmap

NIST published the first post-quantum cryptography standards in 2024, and major TLS implementations are adding hybrid PQC support. CallSphere's roadmap includes:

- 2026: Hybrid X25519 + Kyber-768 key exchange evaluation in test environments
- 2027: Production rollout of hybrid PQC for TLS 1.3 ingress
- 2028+: Migration of long-lived data encryption keys to PQC algorithms

Vapi-based stacks will require each upstream vendor to migrate independently, with no coordination guarantee.

## Encryption in Use (Confidential Computing)

For customers requiring "encryption in use" (data encrypted while being processed), CallSphere is evaluating AWS Nitro Enclaves and confidential compute options for the most sensitive workflows. This goes beyond standard encryption-at-rest and in-transit and is typically required only by very high-sensitivity customers (federal, financial, or biotech).

## Customer-Facing Encryption Documentation

CallSphere publishes an encryption posture document covering:

- Algorithm choices and rationale
- Cipher suite allowlist
- Key management architecture
- Rotation cadences
- Incident response for key compromise
- Customer-managed key options
- Migration plans for deprecated algorithms

This document is updated quarterly and is included in the trust portal.

## Real-World Defense

In a 2025 supply chain incident (industry-wide, not CallSphere-specific), a vulnerability in a popular TLS termination component allowed downgrade attacks on older deployments. CallSphere customers were unaffected because:

- TLS 1.2 was not the floor (1.3 was the default)
- Cipher allowlists prevented downgrade to vulnerable suites
- Centralized rotation closed the window quickly

Customers running multi-vendor stacks reported much longer remediation timelines because each vendor had to be patched independently.

## Encryption in Practice: Voice Path Walkthrough

Trace a single call through encryption layers:

1. **Caller dials in** — The caller's carrier negotiates SRTP with Twilio's edge. The audio is encrypted from the carrier handoff.
2. **Twilio to CallSphere ingress** — TLS 1.3 with modern ciphers; certificate pinned in Twilio's trust store.
3. **CallSphere ingress to voice agent service** — mTLS within the K8s service mesh; service identities authenticated via SPIFFE / mTLS certs.
4. **Voice agent to STT provider** — TLS 1.3; provider certificate validated against trust roots.
5. **Voice agent to LLM provider** — TLS 1.3; enterprise endpoint with region pinning.
6. **Voice agent to TTS provider** — TLS 1.3; provider certificate validated.
7. **TTS audio back to CallSphere** — TLS 1.3 chunked for streaming.
8. **CallSphere to Twilio** — TLS 1.3; same path as ingress.
9. **Twilio to caller's carrier** — SRTP outbound.
10. **Storage of recording** — AES-256 server-side encryption with KMS-managed key envelope.
11. **Storage of transcript** — Postgres TLS connection; column-level encryption for sensitive fields; AES-256 at rest at the volume level.
12. **Storage of analytics row** — same as transcript layer.

Twelve encryption events per call. Each one is enforced by default. A misconfigured layer would be caught in CI / continuous monitoring.

## Compliance Mapping

Encryption defaults map to:

- HIPAA Security Rule § 164.312(a)(2)(iv) and § 164.312(e)(2)(ii) — encryption is "addressable" (must be implemented if reasonable and appropriate)
- PCI-DSS 4.0 Requirement 3 (protect stored cardholder data) and Requirement 4 (encrypt cardholder data in transit)
- SOC 2 CC6.7 (transmission encryption) and CC6.8 (storage encryption)
- ISO 27001 A.10 (cryptography)
- NIST 800-53 SC-8 and SC-28
- GDPR Art. 32 (security of processing)

A single encryption posture document can be mapped to all of these for the auditor.

## Encryption and Right-to-Erasure

When a customer requests erasure, CallSphere can use **cryptographic shredding**:

1. Identify the per-tenant or per-record KMS key
2. Schedule key deletion via AWS KMS (7-30 day grace period)
3. Storage-level delete of encrypted objects
4. Database row delete
5. Audit log entry confirms erasure

After the KMS key is destroyed, even if the encrypted bytes were exfiltrated, they are unrecoverable. This is faster and more defensible than physically scrubbing every storage layer.

## Performance Impact

A common concern: does strong encryption slow voice down? In practice:

- TLS 1.3 1-RTT handshake adds ~10ms per session
- mTLS internal calls add ~1-2ms per hop
- AES-256 storage encryption adds <1ms per IOP
- KMS key envelope decryption adds ~5ms per object decrypt (cached)

Total per-call encryption latency: ~20-50ms, well within real-time voice budgets. Modern hardware (AES-NI instructions on Intel / AMD CPUs) makes encryption essentially free at voice volumes.

## Audit Evidence

Encryption controls produce evidence including:

- TLS configuration scan reports (monthly)
- Cipher suite allowlist documentation
- KMS access logs (CloudTrail)
- Key rotation event logs
- Penetration test reports
- mTLS certificate inventory and rotation logs

This evidence is auditor-ready and exportable from the trust portal.

## Common Encryption Misconfigurations to Avoid

When evaluating any voice AI vendor, watch for these red flags:

- TLS 1.0 / 1.1 endpoints still active (should be hard-disabled)
- Mixed cipher suites including CBC-mode ciphers
- Unencrypted backup endpoints
- KMS keys shared across environments (production should use separate keys)
- Lack of perfect forward secrecy (PFS)
- Self-signed certificates in production
- Hardcoded encryption keys in code or config
- Plaintext logs containing sensitive data

CallSphere's CI / continuous compliance monitoring catches all of these before they reach production.

---

Source: https://callsphere.ai/blog/encryption-at-rest-in-transit-callsphere-vs-vapi