Encryption and Transcription Tools: What Providers Actually Do

Encryption is the single most-claimed security feature in transcription marketing. It is also the most misunderstood. This post explains what the encryption claims actually mean, which threats they protect against, which they do not, and what to look for when evaluating a provider. The goal is to give you enough technical detail to ask informed questions and recognize marketing language when you hear it.

Two Layers of Encryption That Matter

For any cloud transcription service, there are two distinct encryption layers:

Encryption in transit: Protects data while moving between your device and the provider's servers. The standard is TLS (Transport Layer Security), typically TLS 1.2 or TLS 1.3 in 2026.

Encryption at rest: Protects data while stored on the provider's disks. The standard is AES-256 (Advanced Encryption Standard with 256-bit keys).

These protect against different threats. In-transit encryption defeats network eavesdroppers. At-rest encryption defeats anyone who steals the physical storage.

If a provider only mentions one of the two, ask about the other. Both should be present.

What TLS in Transit Actually Does

When you upload an audio file to a transcription service, the file travels across your local network, your ISP, multiple internet backbones, and the provider's network. Any of those hops could in principle see the data.

TLS encrypts the connection end-to-end between your browser and the provider's server. Even if someone is sniffing your local WiFi, ISP traffic, or any intermediate router, they see encrypted gibberish.

What TLS specifically guarantees:

• Confidentiality: The data is unreadable to third parties on the network
• Integrity: The data has not been modified in transit
• Authentication: The server you are talking to is who they claim (via certificate)

What TLS does not protect against:

• The provider themselves reading your data after it arrives
• An attacker who has compromised your endpoint device
• An attacker who has compromised the provider's server after the data arrives

TLS is necessary but not sufficient. Every reputable transcription service has it. If a service does not have TLS in 2026, run.

Verifying TLS Is Actually Used

You can verify TLS by checking the URL in your browser. HTTPS (not HTTP) means TLS. The padlock icon confirms a valid certificate.

For more detail, browser tools like SSL Labs (ssllabs.com/ssltest) grade a provider's TLS configuration. Look for A or A+ ratings, modern cipher suites, and TLS 1.2+ only.

CATT uses TLS 1.2+ with modern ciphers via Cloudflare's edge network. All uploads, downloads, and API calls are encrypted in transit. The same applies whether you use our Audio to Text tool, MP3 to Text, or any other transcription endpoint.

What AES-256 at Rest Actually Does

Once your audio file arrives at the provider, it sits on a hard drive somewhere. AES-256 at rest means the data is encrypted on disk using AES with 256-bit keys.

What this specifically guarantees:

• Physical theft protection: Someone who steals the disk cannot read your data without the key
• Disposal protection: Disks decommissioned without proper wiping do not leak readable data
• Cloud provider isolation: Other tenants on the same physical hardware cannot read your data

What at-rest encryption does not protect against:

• The application server reading data through normal application paths (it has the keys)
• Insider threats from the provider's employees (they have access through the app)
• Compromise of the key management system

Server-side encryption is now standard on AWS S3, Cloudflare R2, Google Cloud Storage, and Azure Blob Storage. Most transcription services inherit this from their cloud provider.

CATT files live on Cloudflare R2 with server-side AES-256 encryption. Keys are managed by Cloudflare. Decryption happens transparently when the application reads files.

End-to-End Encryption: What It Means

End-to-end encryption (E2EE) is a stronger property than transit + at-rest encryption. With true E2EE, the provider cannot read your data even when they want to. Decryption happens only on the user's device.

For text messaging this is implemented well (Signal, iMessage). For transcription, true E2EE is essentially impossible because the provider must read the audio to transcribe it. The AI model needs plaintext audio to produce a transcript.

A few providers claim "end-to-end encryption" for transcription. What this typically means in practice:

• Client-side AES key: User holds an encryption key. Audio is encrypted client-side, sent to the server, and decrypted by the AI for processing. After processing, the transcript may be encrypted again with the user's key. The provider still has plaintext access during processing.
• Confidential computing: Server-side processing happens in a secure enclave (Intel SGX, AMD SEV) where the provider's operators cannot read the data even though their code is running on it. The privacy guarantee is the hardware enclave, not the encryption per se.

Neither of these is true E2EE in the Signal sense. The provider has access at some point. Read marketing claims about E2EE for transcription with skepticism.

For genuinely E2EE transcription, the only path is self-hosting. Run Whisper on your own hardware and the provider never sees the audio because there is no provider.

What Modern Transcription Providers Typically Offer

Across the major transcription services in 2026:

Common: TLS 1.2+ in transit, AES-256 at rest via cloud provider, role-based access controls, audit logs.

Sometimes: Customer-managed encryption keys (CMEK), private cloud deployment options, confidential computing for processing, data loss prevention (DLP) integration.

Rare: True client-side encryption with provider unable to access plaintext, hardware security module (HSM)-backed key management, formal cryptographic certifications (FIPS 140-2 Level 3+).

If your threat model requires the rare category, you are looking at enterprise-tier products or self-hosting.

For most teams, the common tier is adequate. CATT is in the common tier with TLS + AES-256, role-based access in the app, and audit logging.

Customer-Managed Encryption Keys (CMEK)

A pattern offered by enterprise cloud providers: instead of the SaaS managing all the encryption keys, the customer brings their own keys via a key management service (AWS KMS, Google Cloud KMS, Azure Key Vault).

The advantages:

• You can revoke access by rotating or disabling the key
• The provider cannot decrypt data without your key infrastructure responding
• Audit trail of every key use is in your control

The disadvantages:

• Operational complexity for both parties
• Service disruption if your KMS is unavailable
• Often only available on enterprise tiers

CATT does not offer CMEK as of 2026. For customers who need this, the available paths are AWS Transcribe with KMS or Azure Speech Services with customer-managed keys.

Encryption Standards Worth Knowing

A quick reference:

TLS 1.2 vs TLS 1.3: 1.3 is faster and more secure. 1.2 is still acceptable but increasingly deprecated. 1.0 and 1.1 are obsolete and should not appear anywhere.

AES-256 vs AES-128: Both are considered secure. 256 has more headroom against future cryptanalytic advances. 128 is faster. Most providers use 256 for at-rest.

SHA-256 hash signatures: Used in TLS for integrity. The current standard.

RSA-2048 vs ECDSA P-256: RSA is the legacy choice for TLS keys. ECDSA is faster and equally secure at smaller key sizes. Modern providers use both.

SSL: An obsolete protocol replaced by TLS in 1999. If a service mentions SSL specifically, they may be using old language or actually running insecure protocols. Ask which version.

You do not need to verify all of these for every provider. SSL Labs grading captures most of it in a single A/A+/F rating.

What Encryption Does Not Solve

Encryption protects against specific threats. It does not protect against:

The provider deciding to read your data: TLS and at-rest encryption do not prevent the provider's employees from accessing data through normal application access. Internal access controls and audit logs are the relevant protection here.

Compromised application accounts: If your password leaks, encryption does not help. Strong authentication (MFA, hardware keys) does.

Compromised endpoint devices: If your laptop is compromised, the data is readable on your device before it gets encrypted for transit. Endpoint security is a separate domain.

Misconfigured access controls: A bucket set to public read defeats at-rest encryption entirely. Proper access control configuration is necessary alongside encryption.

Compromised AI models: If the model itself is malicious or compromised, all the transit and at-rest encryption in the world does not help because the model legitimately has the plaintext during processing.

A complete security posture combines encryption with access controls, authentication, audit logging, vendor management, endpoint security, and incident response. Encryption is one layer, not the whole stack.

Questions to Ask a Provider

When evaluating a transcription service for security, ask:

1. What TLS versions and cipher suites do you support?
2. Is data at rest encrypted with AES-256?
3. Who manages the encryption keys? Provider or customer?
4. Are backups also encrypted?
5. Are logs and metadata encrypted at rest?
6. Do you offer customer-managed keys (CMEK)?
7. What is your access control model?
8. Are you SOC 2 audited?
9. Do you have a HIPAA BAA or healthcare-specific certifications?
10. How do you handle key rotation and incident response?

For most use cases, the first five matter. The rest become important at enterprise scale or under specific compliance regimes.

Honest Disclosure for CATT

What we do:

• TLS 1.2+ in transit via Cloudflare edge
• AES-256 at rest on Cloudflare R2
• Cloudflare-managed keys (we do not currently offer CMEK)
• Encrypted backups inherited from R2's default protection
• Role-based access controls for our application

What we do not do:

• Customer-managed encryption keys
• Hardware security module (HSM) integration
• FIPS 140-2 Level 3+ certified key handling
• Confidential computing for processing
• True client-side encryption (the model needs plaintext)

For the vast majority of business and personal transcription, the first list is adequate. If you need the second list, you are in enterprise or regulated industry territory and likely need a different provider or self-hosting. For business inquiries about specific encryption needs, see our pricing page.

See is AI transcription private for the broader privacy posture and GDPR-compliant transcription for the regulatory framing.

A Practical Threat Model

For most transcription users, the realistic threats are:

• Network eavesdropping on public WiFi: TLS solves this completely.
• Provider data breach: At-rest encryption helps, access controls and breach response also matter.
• Insider threat at provider: Encryption alone does not solve, access logs and least-privilege do.
• Account compromise: MFA on your account is the key control.
• AI training data exposure: A provider that does not train on customer audio (like CATT) eliminates this entirely.

If your threat model is one of these, standard transcription services with documented encryption are appropriate. Pair the encryption layer with auto-deletion of transcription files and the privacy posture is solid for most business use. If your threat model includes nation-state actors, classified content, or extreme privacy requirements, self-hosting is the only fully correct answer.

Choose based on the actual threat, not the marketing language. The encryption claims that matter are TLS in transit and AES-256 at rest, both implemented correctly. Everything else is either an upgrade for specific use cases or marketing.