This post is for CISOs, security engineers, and IT leaders evaluating DeskTrust Connect for production use. It covers authentication, authorization, transport security, at-rest encryption, and the audit surface.

Authentication

Connect inherits DeskTrust\'s existing authentication — no new credentials, no new tokens.

Admins authenticate via a JWT stored in an HttpOnly cookie named token. Set at login; validated by every Connect API route.
Employees authenticate via a separate JWT in an HttpOnlycookie named emp_token. Same validation path.
Socket.io connections re-verify the cookie on every handshake. Invalid or missing tokens are rejected before any WebSocket data is exchanged.

JWTs are signed with JWT_SECRET, an env var required to be at least 32 characters. Connect will refuse to start if it\'s missing or weak.

Authorization

Every Connect operation is scoped by organization and role. The gates:

Cross-org isolation: no operation ever crosses an Organization.id boundary. Every DB read filters on organizationId. Every Socket.io room name embeds the orgId.
Room membership: chat operations verify the caller is in the targetChatMember table before returning data.
Call participant check: WebRTC events (produce, consume, hangup) verify the caller is either the initiator, an invitee, or an established participant of the session.
Manager scoping: manager-role admins can only initiate screen views for employees in their assigned Groups. Enforced in src/lib/orgContext.js.
Employee opt-out: EmployeeFeaturePreference.blockScreenViewRequests overrides everything. No admin can bypass it.

Transport security

Web traffic: TLS via your DeskTrust deployment\'s existing Let\'s Encrypt certificate. All API + WebSocket + static content.
WebRTC media: DTLS-SRTP end-to-end between peers and the SFU. Standard WebRTC transport security — even if someone taps the network, they can\'t read the media.
TURN relay traffic: coturn supports TLS on port 5349 for TURN-over-TLS, used when a peer\'s network blocks UDP.
Internal traffic: The Node connect-server, mediasoup workers, coturn, and Redis all communicate on localhost or LAN. Not exposed to the internet.

Media path

Peer-to-server-to-peer. NOT peer-to-peer. The SFU is in the middle:

Peer A encrypts media with DTLS-SRTP, sends to SFU.
SFU decrypts (temporary in-memory), re-encrypts with a per-peer key, forwards to Peer B.
Peer B decrypts.

The SFU sees plaintext media in memory during the transit. Not persisted (except when recording is enabled).

End-to-end encryption (where the SFU can\'t see plaintext) requires WebRTC Insertable Streams — on our v2 roadmap. For now, if you need true E2E for calls, use Signal.

At-rest encryption

Chat messages: stored in MySQL. Encryption depends on your deployment — enterprise deployments use AWS RDS with encryption at rest.
Attachments: stored on disk under ./storage/connect/. If your host disk is encrypted (AWS EBS with encryption enabled, self-hosted with LUKS), attachments are encrypted at rest.
Recordings: same as attachments. Same encryption story.

Standard DeskTrust enterprise deployments include disk encryption for all of the above.

The audit surface

Every consent-critical operation writes an immutable row to ScreenViewAuditLog. Rows are never updated or deleted. Contains:

Event type (requested/approved/denied/expired/cancelled/started/ended/revoked/error)
Actor (type + id + name resolved at write time)
Target employee
Jurisdiction, IP, user-agent, and any manager-supplied reason
Linked request and session IDs

Call sessions themselves (not just screen-view sessions) are logged in CallSessionrows with start/end times and participant lists. Chat messages persist in ChatMessage.

Rate limiting

All user-triggered operations are Redis-backed rate-limited:

Chat messages: 30 per principal per minute
Attachments: 20 per principal per minute
Call invites: 10 per principal per minute
Screen-view requests: 10 per manager per hour
Standalone screen shares: 5 per principal per minute

Exceeded limits return 429. No overage charge, no lockout.

Deployment isolation

For enterprise customers:

Single-tenant deployment on customer-specified AWS region
Dedicated database instance
Optional VPC peering to customer\'s existing network
Custom retention policies
Custom consent disclosure text (jurisdictional or company-specific)

Contact sales for details.

Known limitations

No E2E encryption for chat or calls (SFU sees plaintext in memory)
No SSO / SAML in v1 — uses DeskTrust\'s username/password + JWT model
No hardware-backed key attestation for TURN credentials
Recording access itself is not currently audit-logged

Most of these are v1.1 or enterprise-tier custom work. Ask if any are blockers.

The Connect security model: authentication, access control, encryption