Two-factor authentication, role-based access, device and session control, audit logging, and encryption in transit and at rest, all on servers you host. Secret chats add end-to-end encryption.
Overview
Sover is user-hosted, on your own servers, your Kubernetes cluster or your virtual machines, so its security controls run on infrastructure your organization operates: mandatory two-factor authentication, role-based access in the back-office console, device and session management, administrative audit logging, and encryption in transit and at rest.
Two kinds of conversation carry two protection models. Secret chats are end-to-end encrypted, for sensitive private conversations. Standard chats are protected by TLS in transit, encryption at rest, and session-key and file-key payload encryption, which your deployment’s policy configures.
Capabilities
Two-factor authentication is mandatory: every user enrolls a TOTP authenticator app or one-time codes sent by email. Each deployment sets how enrollment is enforced for existing users.
Role-based access control in the back-office console separates administrative duties, so each administrator holds only the permissions their role grants.
Users see every device they are signed in on and can revoke any session. Administrators can revoke all of a user’s sessions or remove access from one device.
Back-office sign-ins and administrative actions on users and other entities are recorded with who acted, from which IP address and when, and can be filtered.
TLS 1.2 or higher, with clients validating the server against a certificate authority your organization controls.
End-to-end encrypted secret chats for sensitive private conversations.
Messaging & ChannelsEncryption
Standard chats are protected in layers that your deployment configures. Secret chats are end-to-end encrypted. The end-to-end claim covers secret chats, not every conversation or integration.
In Transit. TLS 1.2 or higher. Administrators can set a custom certificate authority that clients validate the server against.
At Rest. Encryption at rest on the servers you host.
Payload. Session-key encryption for messages, responses and live events; file-key encryption for uploaded files. Request classes can be exempted at deployment time.
End-to-End Encrypted
Private chats for sensitive conversations, end-to-end encrypted.
Reactions are not available in secret chats.
How It Works
Every account passes the same controls, from registration to revocation.
A user registers with a phone number confirmed by a one-time SMS code, or with an email address confirmed by a one-time code.
Two-factor authentication is mandatory: new users enable it at first sign-in, with a TOTP app or email codes.
On mobile, a six-digit passcode locks the app after a set period of inactivity, with fingerprint or face unlock on supported devices. It stays on the device, separate from two-factor authentication.
Users and administrators end sessions on any device. Changing the registered phone number signs the user out of every device, so whoever holds the old number cannot intercept their codes.
Included
Identity. Phone-number or email registration with one-time codes, and mandatory two-factor authentication.
Access. Role-based access control in the back-office console, and account deactivation without deletion.
Sessions. A connected-devices list with each device’s name, type and last activity, and revocation by the user or an administrator.
Audit. Administrative audit logging, with filters by date, event, initiator, IP address and object.
Encryption. TLS 1.2 or higher with a customer-controlled trust store, encryption at rest, and session-key and file-key payload encryption.
Secret chats. End-to-end encrypted private chats for sensitive conversations.
End-to-end means secret chats. Standard chats use transit, at-rest and payload encryption; the end-to-end claim is not extended to every conversation or integration.
Payload policy is set per deployment. Administrators can exempt request classes from payload encryption, and three pre-session operations are always exempt. TLS still protects them in transit.
Audit requirements are agreed up front. Confirm the events, access, retention and export you need for your deployment; audit logging alone is not a complete forensic or legal-hold system.
Deactivation is not erasure. Deletion, retention and backup treatment are confirmed for your deployment before anyone relies on them.
Configuration is confirmed per deployment. Two-factor enforcement, the allowed methods and the device and session actions are set and checked for the deployment you operate.
Some threats sit outside the platform. Malware on a user’s device, denial-of-service attacks and physical access to your servers are not stopped by application controls; denial-of-service mitigation belongs to your infrastructure.
Compliance
Sover’s deployment, identity, encryption, role-based access and audit controls can support your organization’s compliance program. Your organization validates the selected configuration, external integrations, device handling, data flows and operating procedures against its own obligations.
Hosting on your own infrastructure is one part of that work, not proof of it: on-premises hosting does not by itself show that every integration or push service keeps data inside your network. Agree the audit, retention and data-flow requirements during evaluation and verify them on the release you run.
Where It Runs
Tell us about your organization and we will arrange a briefing for your team.
Yes. Sover offers end-to-end encrypted secret chats for sensitive private conversations. Standard chats have a different security model, including transport, at-rest, and payload-encryption controls; the secret-chat claim should not be extended to every conversation or integration.
Sover supports TLS 1.2 or higher for transport, encryption at rest, and session-key and file-key payload encryption. These controls have different purposes and configuration boundaries; they do not mean that all content uses the same end-to-end encryption model.
Yes. Two-factor authentication is part of Sover's identity controls. Enrollment, enforcement, and the allowed methods should be configured for your deployment; a local app lock is separate from server-side authentication.
No. Hosting is one part of a compliance program. Your organization must assess configuration, access, integrations, devices, data flows, and operating procedures against its obligations. Sover's controls can support that work; hosting alone does not establish compliance.
Yes. Sover includes device and session management. Use those controls as part of your access policy, and confirm the supported actions and client behavior for the deployment you operate.
Yes. Administrative audit logging is part of Sover's control set. Agree the events you need to record and the access, retention, and export requirements; audit logging alone does not establish a complete forensic or legal-hold system.