Back to blog
Security

Why we built true end-to-end encryption into every session

Most remote support tools decrypt your session at the relay. We took a harder path so even we can never see a frame of your screen.

Dana Whitfield

June 4, 2026 · 8 min read

Why we built true end-to-end encryption into every session

When a technician connects to a client device, the most sensitive data imaginable flows across the wire: live screens, keystrokes, files, and credentials. The question every security team should ask a remote-support vendor is simple — who, besides the two endpoints, can see this traffic? For most tools, the honest answer is "the relay can."

The relay should be blind

AccessMonk uses a relay to traverse NAT and firewalls, but the relay only ever forwards ciphertext. Session keys are negotiated directly between the agent and the technician using an authenticated key exchange. The relay never holds a key and never sees a decrypted frame.

agent  ──(ECDHE handshake)──▶  technician
  │                              │
  └────── ciphertext only ───────┘
              (via relay)

If the relay is compromised, the attacker gets a stream of useless ciphertext. That is the whole point of designing for the worst case.

Dana Whitfield, Head of Security

What this means for your clients

  • No plaintext session data is ever stored or transited by our infrastructure.
  • Per-session keys are ephemeral and discarded when the session ends.
  • Device identity is verified before any key exchange begins.

Encryption that stops at the vendor is not end-to-end. Building it correctly took longer, but it is the only model we would be comfortable putting in front of a client security review.