Sanket.Chat
Security: customer control

Customer control: your infrastructure, your keys, your rules

SANKET (Sanket.Chat) by Tosh Defence puts the customer in control of everything around its communications: its own infrastructure, keys, identity provider, policies, update timing, branding, retention and deployment topology, from a cloud the customer chooses to a fully air-gapped network. That depth of control is SANKET's defining advantage, the kind of control that hosted messaging services are simply not built to offer.

Encryption decides who can read a message. Control decides everything else: who runs the service, who is admitted, which devices are trusted, when the software changes and where the records live. With SANKET, every one of those answers sits inside your own security boundary.

Your infrastructure and your keys

Every SANKET installation is dedicated to one organisation and runs where that organisation decides: a cloud account in any region it chooses, Tosh Defence hosting, its own data centre or a closed network. There is no vendor-operated service in the message path.

Users' private keys are generated on their devices and protected by hardware-backed storage. Server-side secrets live inside the installation in non-exportable key storage. Only the public licence and release verification keys come from Tosh Defence.

Your identity provider and your administrators

The organisation decides how identities come into existence: administrator provisioning, single-use invitations (the default) or SCIM 2.0 from its own directory. Enrolment can be checked against LDAP or Active Directory, and administrators can sign in through the organisation's own OpenID Connect or SAML 2.0 provider. Public identity providers are refused and no account is ever created just because someone signed in.

Administrators authenticate with FIDO2 security keys and work within permission-scoped roles, and every administrative action is recorded in a SHA-256 hash-chained audit log.

  • FIDO2 security keys for administrators
  • Single sign-on through your own provider
  • SCIM 2.0 joiner, mover and leaver automation
  • Permission-scoped administrator roles

Your devices

Device governance is the organisation's. Every device is approved before it receives anything, holds hardware-backed keys, appears on its account's signed device list and presents its own client certificate through device mutual TLS, issued under the customer's certificate authority. Administrators can place a device in lost mode, revoke it or remotely wipe it at any time.

Your policies, retention and branding

Security, messaging, files, calls, groups, retention, notifications and integrations are tenant policy, set by the organisation. Classification labels are defined by the customer, up to eight ranked labels. First-party usage analytics stay inside the installation and can be switched off or locked off for the whole installation.

Sanket.Work installations are whitelabel, so users see the organisation's own name and branding.

Your update timing, with signed releases

Releases are signed packages with a software bill of materials. The installation verifies the signature and every hash before loading, refuses an expired release (freeze protection) and refuses anything older than the release it has recorded (rollback protection). The organisation's change authority decides when to install; the upgrade checks health and rolls back automatically on failure. Connected upgrades are optional, and running an upgrade from the console is off by default.

Technical proof

Read the detail in the SANKET whitepaper

Every statement on this page is set out in full in the public SANKET Technical Security and Architecture Whitepaper, free to read without registration.

FAQ

Frequently asked questions

Ask our team a question

What does customer control mean in SANKET?

The customer owns and decides its infrastructure, keys, identity provider, policies, update timing, branding, retention and deployment topology. Each installation is dedicated to one organisation, from a chosen cloud to fully air-gapped.

Who holds the encryption keys?

Users' private keys are generated and stored on their own devices in hardware-backed storage. Server-side secrets stay inside the customer's installation. Tosh Defence holds no customer keys.

Can we use our own identity provider?

Yes. Users can be provisioned through SCIM 2.0 and checked against LDAP or Active Directory, and administrators can sign in through your own OpenID Connect or SAML 2.0 provider together with a FIDO2 security key.

Who decides when SANKET is updated?

You do. Signed releases are installed only when your change authority approves. Expired and older releases are refused, and a failed upgrade rolls back automatically.

Can SANKET carry our organisation's branding?

Yes. Sanket.Work installations are whitelabel, so users see the organisation's own name and branding.

Can we set our own retention periods?

Yes. Retention for messages, broadcasts, call logs, alerts and disappearing messages is set by the organisation's administrators.

What is device mutual TLS?

Every approved device holds its own client certificate, generated from a key created on the device and issued under the customer's certificate authority, and presents it on every connection as an independent proof of the device.

Take control of your organisation's communications

Tosh Defence helps you design an installation around your infrastructure, identity provider, policies and release process.