> ## Documentation Index
> Fetch the complete documentation index at: https://docs.openwhispr.com/llms.txt
> Use this file to discover all available pages before exploring further.

# How OpenWhispr is secured

> Encryption, credential storage, access control, and where our compliance attestations actually stand.

Short version: everything in transit is encrypted with TLS, data at rest in our
cloud database is encrypted, your API keys are held in your operating system's
own keychain, and everything the desktop app runs binds to your own machine by
design.

The binding detail lives in our [security
overview](https://openwhispr.com/security) and the [DPA](https://openwhispr.com/dpa).
Our [trust centre](https://trust.openwhispr.com) carries the live control list
and the current sub-processors.

## Encryption

| Where                     | What protects it                                                    |
| ------------------------- | ------------------------------------------------------------------- |
| **In transit**            | TLS 1.2 or higher on every connection, to us and to model providers |
| **At rest, our cloud**    | Encrypted at the database layer                                     |
| **At rest, your machine** | Your OS account and your disk encryption — FileVault, BitLocker     |
| **Your API keys**         | Encrypted through your OS keychain                                  |

## How your API keys are stored

Keys you enter — bring-your-own-key credentials and enterprise cloud credentials
— are encrypted using Electron's `safeStorage`, which hands off to the operating
system's own secret store: **Keychain** on macOS, **DPAPI** on Windows,
**libsecret** on Linux. The encrypted blobs sit in a `secure-keys` folder inside
OpenWhispr's application data.

They are never sent to OpenWhispr's servers.

<Warning>
  **One real limitation, on Linux.** If your system has no keyring available,
  Electron falls back to storing secrets in plaintext. That's Electron's default
  behaviour rather than something we've chosen, but the effect is the same: on a
  Linux box without a working keyring, treat stored API keys as unprotected at
  rest. Install and unlock a keyring — GNOME Keyring, KWallet — before entering
  keys on a shared or portable machine.
</Warning>

## The desktop app

* **Loopback-only by design, with one known exception.** Every connection to
  our servers is outbound and client-initiated, over TLS on port 443. A few
  components listen on `127.0.0.1` for the app's own local pieces to talk to
  each other — the CLI bridge, an auth bridge, an OAuth callback catcher, and
  local model servers when you use them. The bundled Parakeet speech server is
  the one exception: its upstream binary can't bind loopback-only, so on
  Windows it listens on all interfaces until the installer's firewall rule
  closes it off — see [antivirus and firewall
  prompts](/help/fix/antivirus-blocks-openwhispr) for what that means for
  per-user and portable installs.
* **Context isolation is on**, with a restricted preload bridge between the app's
  interface and the parts of it that can reach your system.
* **Native helpers are compiled from source** during our build — the key listener
  and paste utilities aren't downloaded binaries.

## Access and monitoring on our side

Production access is least-privilege and requires MFA. Access and sessions are
logged and monitored, with logins reviewed monthly. We run vulnerability and
patch management alongside secure development practices, and staff are under
confidentiality obligations with security training.

Backups and recovery objectives are documented — a four-hour recovery time
objective and a one-hour recovery point objective for the primary datastore —
and the contingency plan is tested annually.

## Where our compliance stands

We'd rather be precise here than impressive, because this is exactly the sort of
claim that gets checked.

|                    | Status                                                                                                                              |
| ------------------ | ----------------------------------------------------------------------------------------------------------------------------------- |
| **SOC 2 Type 2**   | Audit complete and the observation period has passed. The final report is available under NDA once issued                           |
| **HIPAA**          | Attestation held (2026, through our compliance platform) — see [HIPAA and healthcare use](/help/privacy/hipaa-and-healthcare)       |
| **GDPR**           | Attestation held (2026, through our compliance platform) — see [GDPR and your data rights](/help/privacy/gdpr-and-your-data-rights) |
| **ISO 27001:2022** | Our programme is aligned to it and all 93 Annex A controls are implemented. We have **not** undertaken a certification audit        |

If you need the SOC 2 report or a completed security questionnaire, email
[support@openwhispr.com](mailto:support@openwhispr.com) and say which you need.

## Reporting a security issue

Email [security@openwhispr.com](mailto:security@openwhispr.com), or use [GitHub's
private vulnerability
reporting](https://github.com/OpenWhispr/openwhispr/security/advisories/new).
Please don't open a public issue for a security problem. We aim to acknowledge
within 48 hours.

<Snippet file="still-need-help.mdx" />

## Related

* [Answering a security review](/help/privacy/for-your-it-team)
* [Where your voice and text go](/help/privacy/where-your-data-goes)
* [Network allowlist](/help/it/network-allowlist)
* [Security overview](https://openwhispr.com/security)