Security model and encryption
Principles
Ubidesk’s security model rests on three principles:
- A single channel: all traffic, console, agents and clients, goes through port 443. No other port is opened toward the platform.
- No long-lived session secrets: each session negotiates its own keys.
- Tamper-evident traceability: every action is written to a hash-chained log.
Transport
Connections use TLS 1.3. Earlier protocol versions are not accepted. In practice:
- port 443 is enough, even behind a restrictive egress firewall or a proxy;
- certificates are verified on both sides;
- there is no plaintext fallback: a connection that cannot negotiate TLS 1.3 fails instead of downgrading.
Session encryption
Every remote session is encrypted with AES-256-GCM, an authenticated cipher that protects both confidentiality and integrity of the stream.
Keys are derived from a per-session ECDH exchange: the session key exists only for the duration of the session, is never stored, and compromising one key does not compromise other sessions.
Technician authentication
MFA is mandatory for all technician accounts, on every plan:
- TOTP codes from an authenticator app;
- passkeys, synced or device-bound;
- FIDO2 security keys.
On the Business plan, authentication can go through an identity provider via SAML or OIDC SSO. MFA stays required even when SSO is enabled.
Audit log
The log records session and administration events: sign-ins, sessions opened and closed, file transfers and confirmations, configuration changes.
It is hash-chained: each entry references the fingerprint of the previous one. Altering any entry breaks the chain, which makes tampering detectable.
The log can be exported to a SIEM in Syslog format and to Splunk and Microsoft Sentinel integrations.
Data residency
Workspace data is hosted in a region chosen among the European Union, Canada and the United States. The choice is made when the workspace is created and determines where metadata, logs and session recordings are stored.
File transfer and consent
No file transfer starts without explicit user confirmation. Confirmation is per-file, logged, and cannot be bypassed by the technician.
Session recording
Session recording, available from Pro, is stored in the workspace’s residency region. Tell the user before starting a recording. Recordings are only created when a technician starts one, and only on plans that include the feature.
Threat model
These mechanisms defend against specific threats:
- Interception: TLS 1.3 on port 443 defeats passive listening and downgrade attacks on the transport.
- Session key compromise: per-session ECDH keys limit the blast radius of any single leaked key.
- Account takeover: mandatory MFA blocks password-only attacks; FIDO2 and passkeys also resist phishing.
- Insider tampering: the hash chain makes silent edits to the audit log detectable.
What they do not do: protect a machine whose local credentials are weak, or a user who grants control to someone they should not trust. That part is covered by the hardening guide.
What remains your responsibility
Session security also depends on the endpoint configuration: local passwords, screen lock, OS updates. See the Hardening your remote access guide and the Trust Layer page.
For the programmatic side, see REST API: overview.