Confidential business communications under organisational control
SecureMessenger encrypts messages, attachments and calls on the device before transmission. The service routes encrypted content without holding the keys required to read it; identity and access do not depend on phone numbers or personal address books.
- On-device encryption and hybrid key agreement
- Passkeys and a cryptographic identity for each device
- Native iOS and Android apps, self-hosted service
Content encryption and service governance
Content and service operations remain separate: the service manages accounts, devices and delivery, while decryption and verification take place exclusively on authorised devices.
Local encryption
Each device generates and retains its own cryptographic identity. Messages, attachments and call signalling are encrypted before reaching the network; private keys remain in protected operating-system storage.
Separate delivery queues for each device
Each linked device receives a distinct encrypted envelope. Delivery sequences support resumption after interruption; delivered messages are removed from the queue upon acknowledgement.
Encrypted attachments and backups
Attachments and backups are encrypted by the device before object storage. The service stores opaque objects and does not receive the keys required to open them.
Limited metadata
The service processes operational metadata required for deferred delivery and abuse protection: accounts, devices, delivery times and technical signals. Conversation content remains excluded.
Verifiable cryptographic architecture
The design uses established primitives and separates identity, session establishment, key updates and recovery. Each property corresponds to a verifiable protocol function.
Per-device identity
Each device publishes only the public material required to establish sessions. The service does not hold private keys or message keys.
Hybrid key agreement
Session establishment combines elliptic-curve key agreement with Kyber-1024, adding a post-quantum component to the initial key-derivation process.
Continuous key updates
Keys advance with each exchange. Compromise of a current key does not allow previous messages to be reconstructed, and the protocol renews protection in subsequent exchanges.
Passkey access
Access is bound to a device passkey. Refresh credentials rotate on every use, and detected reuse revokes the associated session family.
Group key rotation
Membership changes create a new cryptographic epoch: departing members cannot access subsequent messages, and new members do not automatically receive earlier history.
Identity verification
Participants can compare a safety number or its code. A device identity change is signalled and requires renewed confirmation for messages subject to verification.
Protected communication features
Encryption covers text, media and application signals required for conversations, without transferring preview generation or content access to the service.
Messages and attachments
Text, replies, reactions, edits, delivery and read receipts, typing indicators, forwarding, mentions and scheduled drafts. Offline queues resume on reconnection.
Protected media
Images, video, files and voice notes are verified by block; thumbnails and previews are generated locally. Transfers can resume after interruption.
Expiring messages
Retention can be configured per conversation. At expiry, the defined removal procedures are applied to messages and protected media.
Groups
Roles, administrators, invitations, join requests and ownership transfer. Invitation links expire and can be revoked; each group supports up to 256 members.
Stories
Temporary posts for contacts, groups or audiences defined on the device. Views, reactions and replies remain encrypted and follow the post expiry.
Calls
One-to-one voice and video calls with encrypted signalling, interruption handling and network-change support. Group calls use capability links and session keys derived on the device.
Identity and devices under control
The perimeter of an encrypted conversation is the set of devices capable of opening it. SecureMessenger makes that set visible, verifiable and revocable.
Normalised usernames
The form used to check uniqueness neutralises confusable characters, ligatures and mixed scripts. Search uses exact usernames without uploading the phone address book.
Multiple devices per account
Each account can link up to ten devices, each with its own identity and queue. The list distinguishes the current device, active devices and revoked devices.
Controlled device linking
A new device is linked through a short-lived, single-use code and must be approved by an active device. Account state is transferred as encrypted content.
Immediate revocation
Revocation closes device access, removes its queues and notification registration, and invalidates the associated session without waiting for ordinary token expiry.
Separate recovery procedures
Service-access recovery and encrypted-identity recovery remain separate procedures. Email verification does not transfer conversation keys to the service.
Recovery kit
A 256-bit secret protects the device identity copy. Recovery on a new phone presents a verifiable preview before application.
Service administration without conversation access
Operational tools govern accounts, devices, limits and availability. Administrative functions do not include access to messages, attachments or calls.
Attributable operations
Account suspension, device revocation, username release and limit management require operator identification and produce audit records.
Abuse protection
Registration, authentication, delivery and search limits are calculated using rotating pseudonyms, reducing the need to retain clear-text IP addresses.
Limited retention
Queues are transient, delivered messages are deleted on acknowledgement, and undelivered items follow expiry periods defined by the organisation.
Integrated operations
Health probes, metrics, dashboards, alerts and operating procedures integrate SecureMessenger with the tools already used by the team responsible for the service.
Deployment model
The service is deployed on the client’s infrastructure; native applications run on authorised iOS and Android devices. DEC defines the scope, integrations and operating procedures with the client.
Self-hosted service
Deployment includes the application service, relational database, cache, object storage and call network-traversal components. Containers, Helm charts and infrastructure as code support commissioning.
Native applications
The iOS and Android applications include sharing extensions and operating-system integration. Interfaces are available in Italian and English and support screen readers, enlarged text and reduced motion.
Confidential messaging assessment
DEC can review users, devices, communication flows, retention policies, identity, infrastructure and integrations to define a verifiable SecureMessenger scope.