Fortress Communicator is a business phone with end-to-end encryption built in. This article explains what that means in plain language, what the security badges in the app are telling you, and what we can and cannot defend. If you want the full technical detail, see the technical whitepaper.
What “end-to-end encrypted” actually means
When a call between two Fortress users is end-to-end encrypted, only the two phones in the call hold the key that decrypts the audio. Our servers route the audio between you, but the bytes flowing through our servers are opaque ciphertext — we cannot listen even if we wanted to, and a subpoena against Fortress yields ciphertext.
This is not the same as “encrypted in transit.” Almost every voice product today encrypts the audio between your phone and the server. End-to-end means the encryption keeps going past the server — the key never touches the server in the first place.
The three trust badges
Look at the top of any active call. You will see one of three badges:
- Green check — End-to-end encrypted · Verified. Both ends are Fortress users on devices whose safety numbers you have verified out of band. Our servers see ciphertext only. This is the strongest state.
- Yellow shield — End-to-end encrypted · Not verified. Both ends are Fortress users; the encryption is in place, but you have not yet verified the other party’s safety number. The cryptography is the same as green; the trust UI is reminding you to verify.
- Orange band — Routed through Fortress PBX. At least one leg of the call is plain phone audio (PSTN — the other party is on a regular phone number). The audio is encrypted between you and our PBX, but unencrypted on the leg between our PBX and the carrier.
Safety number verification
Every Fortress device has an identity key. A safety number is a 60-digit fingerprint of the two identity keys in a call — yours and the other party’s. When you and the other party can confirm you see the same 60-digit number, you know there is no third party in the middle holding a different key and reading your call.
How to verify:
- Open the Private Chat or call screen with the other party.
- Tap the security badge at the top.
- Compare the 60-digit number on your screen with the 60-digit number on theirs. The numbers must match exactly. You can compare verbally, send a screenshot through an out-of-band channel, or scan the QR code shown on the other party’s screen with your camera.
- If they match, tap Verify. The badge turns green and stays green for that contact across future calls — until either party rotates their device key.
Verification is a one-time thing per contact per device. After you verify Alice’s iPhone, every future call between you and Alice on that iPhone is green-badge automatically. If Alice gets a new phone, you will see yellow again until you re-verify.
Why PSTN calls cannot be end-to-end encrypted
When you call a regular phone number — a landline, a mobile number that is not on Fortress, a 1-800 number, anywhere on the public phone network — the call has to land on a carrier’s switch. The phone network was built in the 1960s and does not speak end-to-end encryption; it speaks plain voice. Our PBX terminates the encryption on our side, hands the audio to a carrier in plain form, and the carrier delivers it to the receiving phone.
This is a property of the phone network, not a Fortress limitation. No business phone product can end-to-end encrypt a call to a regular phone number. The orange band is the honest signal that you are on that path.
Why SMS cannot be end-to-end encrypted
Same answer, different protocol. SMS is a carrier-side protocol; the message has to be readable by the carriers in order to be delivered. We encrypt the message between your phone and our SMS gateway (Telnyx), but the carrier sees plaintext after that.
If you want end-to-end encrypted messaging, use Private Chat — the Fortress-to-Fortress messaging channel inside the app.
In-call key ratcheting
During an end-to-end call, the encryption key changes every 30 seconds. This is called ratcheting. The current key is derived from the previous key plus fresh entropy; the previous key is destroyed and cannot be recovered from the new one.
Practical effect: if an adversary somehow captured a single frame’s key, they could decrypt that one 30-second window of audio — not the whole call, and nothing that came after. This is the same property the IETF SFrame standard (RFC 9605 §4.7) specifies.
Trust the math, but verify the device
End-to-end encryption pins trust to a device’s identity key. When somebody gets a new phone or reinstalls the app, their identity key changes. The app surfaces this — calls and Private Chat threads with that contact return to yellow (not verified) so you know something changed.
Re-verify when this happens. The math is solid; the only way to know you are talking to the right person is to confirm the new key is theirs through a channel you trust.
What we cannot protect
- The other party. If your contact records the call or screenshots the chat, no encryption can stop them. End-to-end encrypts the channel, not the participants.
- A compromised phone. If iOS, the Secure Enclave, or the iOS Keychain are compromised, the identity key can be extracted from your device. Any cryptosystem that pins identity to a mobile device carries this residual trust.
- Call metadata. Who called whom, when, and for how long is visible to our billing system. We retain this for as long as billing reconciliation requires it.
- PSTN audio. Already covered above — the audio on the carrier leg is plaintext at the carrier.
Lawful process
We comply with valid US legal process. What that yields:
- Call metadata — who called whom, when, duration. Yes, available.
- SMS content — the carrier holds this; we hold message routing records. Available to the extent they exist in our systems.
- End-to-end call audio — we hold ciphertext. We do not have the key. There is nothing to produce.
- Private Chat content — same answer. Ciphertext only.
This is one of the clearest breakdowns of E2E encryption I’ve seen written for people who aren’t IT specialists — our communications sergeant actually forwarded it to the whole shift. One question though: how does the safety number verification process work when staff are rotating across different facility pods and using shared devices? That’s the scenario that keeps me up at night.
Appreciate that you actually explained what ‘end-to-end’ means without burying us in jargon — most vendors just throw the buzzword around and call it a day. Quick question though: how does the safety number verification work in practice when we’re onboarding new deputies who aren’t exactly tech-savvy? That’s always where things fall apart on our end.
Finally someone explained E2E encryption in a way I can actually repeat to my lieutenant without sounding like I’m reading off a tech brochure. One thing I’m still fuzzy on though — what happens to message retention if the encryption keys rotate? That’s been a sticking point for us when it comes to audit trails.
This is exactly the kind of plain-language breakdown we needed — our IT guy has been trying to explain E2E encryption to our command staff for months and getting blank stares. One question though: how does the safety number verification process work in practice when you have high staff turnover and new deputies are constantly being added to channels?
We’ve been burned before by vendors who promised ‘secure communications’ and couldn’t explain how it actually worked under the hood, so I appreciate that you’re breaking this down in plain language instead of just throwing buzzwords at us. One question though — does Fortress Communicator’s encryption hold up if a device is physically seized, or does that fall into the ‘what we cannot defend’ category? That distinction matters a lot for our chain-of-custody protocols.
Appreciate that you spelled out what the system actually can and cannot defend against — too many vendors oversell their security claims and leave staff with a false sense of confidence. Quick question though: do the safety numbers need to be verified manually by staff each time a new device is paired, or is that a one-time process per user? That detail matters a lot for our intake workflow.