SECURITY Signing, encryption and the record
Signed end to end. HELP and replies encrypted end to end.
Only the site can send an order, every answer is tied to one device, and the messages that carry personal detail are encrypted from the staff member's phone to the site's control center. Life-safety alerts are signed but deliberately not encrypted, so that nothing can stop them.
Stage: built and tested in our software and on our bench. Not field-tested. No outside security audit yet; one is planned.
01 Encryption
What is encrypted, in our own words.
HELP messages and operator replies are encrypted end to end between the staff member's phone and the site's control center (ChaCha20-Poly1305 with a per-device key). Relay nodes, gateways and radio links carry only ciphertext and cannot read them. Phones pair only over HTTPS pinned to the site's own certificate authority (TLS 1.2+ with forward secrecy), and the device key is never sent over an unencrypted connection. Life-safety alerts (STOP, E-STOP, HOLD, CANCEL) are digitally signed but deliberately not encrypted, so that no key failure, and no forged traffic, can ever stop them.
Wording reviewed against our adversarial review of the link encryption, November 5, 2026.
02 Controls
Each part of the lane, and how it is protected.
| Orders | Every order is signed at the site's control center. Every node and device rejects anything unsigned, altered or replayed, so a fake STOP or a fake all-clear goes nowhere. Bench |
|---|---|
| Replies | Each reply is signed by the staff member's device. The device key stays on the phone. Built |
| Names on air | None. Replies travel with per-event codes, and names resolve only at the site's control center. Built |
| HELP and replies | Encrypted end to end between the phone and the site's control center, as quoted above. Built |
| Life-safety alerts | STOP, E-STOP, HOLD and CANCEL are signed, not encrypted, by design: a wrong or missing key must never stop a STOP. Built |
| Pairing and enrolment | Staff enrol through a site-signed handshake over HTTPS pinned to the site's own certificate authority. Partner SDKs accept only enrolments the site signed, for the site they expect. Built |
| Operators | Operators sign in with multi-factor authentication or single sign-on. Every order is armed with a one-second hold before Send. Built |
| Keys on phones | iOS Keychain, this device only, never synced or backed up. On Android, keys are held under the Android Keystore with backup disabled. Built |
| Receive-only mode | For places where transmitting is unsafe: phones receive alerts and transmit nothing until the person chooses. Bench |
| BUILT = in the software and tested in our test suites and digital twin, not field-tested. BENCH = also shown on our own boards. | |
03 The record
A record that holds up, and stays with the site.
- Who was told what, when, and who answered, for every order.
- Hash-chained with signed, time-stamped checkpoints, so it is tamper-evident.
- Encrypted on disk and kept on site. The backup control center keeps its own copy.
- Checkable offline by a separate verifier, without the key and without contacting us.
- Encrypted to a key only the operator holds.
- Any STOP automatically keeps the 30 minutes before it, including who was reachable.
- Every download is written into the record itself.
The record is designed to support investigators, insurers and counsel; counsel confirms its use case by case. It shows what the site's control center received and did. It is not proof of what a phone authored, and we do not describe it that way.
04 Honest limits
What is not encrypted, and what has not been checked yet.
| State | Area | Detail |
|---|---|---|
| Not yet | Field test | Nothing on this site is a field result. The encryption work has been tested in software, not yet run end to end on hardware with real phones in the field. |
| Not yet | Outside audit | No outside security audit or review yet. One is planned. |
| By design | Life safety | STOP, E-STOP, HOLD and CANCEL are signed and readable on air, so that no key failure can stop them. |
| Not yet | Voice and crew text | Push-to-talk voice is authenticated but not encrypted. Crew text messages are not yet encrypted end to end. |
| No | FIPS | The cryptography uses standard, widely reviewed algorithms, but it is not a FIPS-validated module. |
| By design | Site access | The site's control center decrypts and stores HELP messages for incident review. Metadata, such as that a HELP happened and which node heard it, is visible to the site's own network. |
| Not yet | Radio | Designed to FCC Part 15.247, not yet certified. Our prototype boards are not FCC-authorized; the plan is off-the-shelf certified devices running Cover4 firmware. |
05 Commitments
How Cover4 behaves at your site.
- Staff alerts only. No public alerts and no attendee tracking. Attendees can be offered HELP and short texts to staff, never attendee-to-attendee messaging.
- A person always arms and presses Send. Nothing goes out on its own.
- Alongside your radios, PA, evacuation system, fire alarm and alerting app, never instead of them.
- Radio plan coordinated with your RF team before any event.
- Nothing in your audio or video path.
- Every result we publish carries its stage: BENCH, SIMULATED, TWIN, BUILT, DESIGNED, PLANNED or ESTIMATE.
Security questionnaire or a design review?
We answer security questionnaires and share the technical detail behind this page with partners and sites under NDA.
partners@getcover4.com