End-to-end encryption built on RFC 9605 SFrame.
RFC 9605 SFrame with AES-128-GCM, per-frame AEAD, and 30-second key ratcheting on every call between two Fortress users.
🔐 Built on IETF-standard SFrame (RFC 9605) — the same end-to-end media encryption protocol Signal uses for group calls.
What we protect
🛡
Voice and video between Fortress devices
AES-128-GCM AEAD per frame, keyed by SFrame per RFC 9605. The Fortress PBX sees opaque ciphertext.
🔄
Forward secrecy via in-call ratcheting
The encryption key rotates every 30 seconds during a call per RFC 9605 §4.7. Compromise of one epoch’s key never reveals earlier audio.
🔐
Safety-number verification
60-digit fingerprint, persistent trust records. Verify out-of-band once and the app warns you if anything ever changes.
The three badges you see during a call
Fortress always tells you what mode you’re in. No silent fallbacks.
🟢 Verified end-to-end
You and your peer have compared safety numbers in person, by video, or over a separate trusted channel. The trust record is pinned. If the key changes, the badge drops and the app warns you loudly.
🟡 End-to-end, not verified
The call is encrypted end-to-end, but you haven’t compared safety numbers yet. Same encryption strength as green; you just haven’t done the one-time fingerprint check.
🟠 Routed through Fortress PBX
One leg of the call lands on the public phone network or a non-Fortress endpoint. The audio is decrypted at the carrier — we cannot encrypt past the carrier boundary. We tell you when.
How we stack up — security axis
RingCentral leads on installed base; Fortress leads on end-to-end media encryption at one-quarter less per seat.
| Property | Fortress | RingCentral | Wickr | Cellcrypt |
|---|---|---|---|---|
| End-to-end voice (in-network) | Yes (SFrame) | No | Yes | Yes |
| Open IETF standard for E2E media | Yes (RFC 9605) | n/a | Proprietary | Proprietary |
| Safety-number verification UX | Yes (60-digit) | n/a | Yes | Limited |
| Per-call ephemeral keys | Yes (purged 30 min server-side) | n/a | Yes | Yes |
| In-call ratcheting | Yes (30 s, RFC 9605 §4.7) | n/a | Limited | Limited |
| Forced TURN relay (no IP leak) | Yes | No | Limited | Limited |
| Subpoena yields ciphertext only | Yes | No | Yes | Yes |
The security architecture documented on this page is implemented per IETF RFC 9605 (SFrame). For deployments where an independent cryptographic audit is required by procurement policy, see our enterprise tier.
What we don’t claim
The hard truths every honest security page should state out loud.
- PSTN calls are NOT end-to-end encrypted. By definition. When a call lands on a real phone number through Telnyx or VoIP.ms, the audio is plaintext at the carrier and at the terminating phone. We show an orange banner so you always know.
- Mixed-cohort conferences fall back to PBX-mediated. If three Fortress users dial into a conference with one PSTN participant, the whole conference is routed through Asterisk’s mixer in plaintext.
- Apple Keychain compromise breaks end-to-end. If iOS, Secure Enclave firmware, or the Keychain are compromised, your identity key can be extracted. Any cryptosystem that pins identity to a mobile device carries this residual trust.
- Call metadata is visible to Fortress operations. Who called whom, when, for how long, which extension or DID. Sealed-sender style metadata protection is roadmap, not shipped.
- Multi-device key sync is not shipped. Today each Fortress account uses one device for end-to-end. Adding a second device produces an independent key.
Read the technical details
The full security whitepaper, in PDF.