Security model

A remote-support tool can see any screen, type anything, and — with elevation or backstage — run commands as SYSTEM. That makes it one of the most valuable targets in an estate. This page is written so a reviewer can check the claims rather than take them.

Trust boundaries

[client host] --TLS--> [relay host] --TLS--> [agent host]
     endpoint          forwards ciphertext        endpoint
   holds a key            holds no key          holds a key

• Each hop is TLS. An on-path network attacker cannot read or modify traffic in transit.
• The relay terminates TLS, so it could read whatever it forwards. That is why the endpoints encrypt above it. With end-to-end encryption negotiated, the relay forwards ciphertext it holds no key for — which removes it from the confidentiality boundary.
• The endpoints are the trusted parties. The installed client runs as LocalSystem and is powerful by design. Install it only where that is intended, and only let authorized technicians pair with it.
• Backstage is the highest-privilege surface in the product: a SYSTEM shell, no user present, nothing on screen. Treat access to it as equivalent to handing out a remote SYSTEM command prompt.

The encryption scheme

After pairing, both endpoints generate an ephemeral ECDH P-256 key pair and exchange public keys through the relay. The shared secret goes through HKDF-SHA256, salted with the session token, to derive:

• two AES-256-GCM keys, one per direction, so a captured frame cannot be replayed back the other way;
• a 4-byte nonce salt per direction, combined with a monotonic counter — no nonce is ever reused, and the receiver rejects a non-increasing counter, which is also anti-replay;
• the material for a 6-digit short authentication string.

The browser console uses the standard WebCrypto API; the native Windows client implements the identical scheme, so any pairing of console and client interoperates.

Read the 6 digits aloud

Both ends derive the same short authentication string from the agreed key material — and only if nothing altered the exchange in flight. Folding the session token into the derivation already defeats a passive relay; the SAS is what catches an active man-in-the-middle, including a malicious relay that also knows the token. Compare it out of band — say it to the user — before backstage or elevation.

Three identity planes that never mix

Secure Desk is deliberately decoupled from the supported computer's own security. A client can sit in any customer domain, or none, and the system never joins, trusts or authenticates against that domain in order to operate.

The consequence is the one worth stating plainly: compromising the portal does not grant OS access to any client, and operating a client never exposes portal identities or customer domain secrets to the support infrastructure.

Authentication and roles

Local accounts are gated until they enrol TOTP — on by default — with recovery codes issued once and stored only as hashes. SSO delegates the second factor to your identity provider, and domain-allowlisted auto-provisioning drops a new SSO user into the read-only viewer role rather than granting access by default.

Socket access is authorized per session: the relay validates the session id format and its secret token against the portal's registry with constant-time comparisons, honours expiry, and consumes a one-time link when its client session ends. Sessions use HttpOnly, SameSite cookies and scrypt-hashed passwords. The legacy shared relay token remains only as an optional path for unregistered session ids and is off by default — leave it off in production.

Elevation, specifically

When a technician needs more rights than the session has, they are prompted inside the session for that machine's own administrator account. Those credentials are used once, on that box, for a linked-token launch. They are never persisted, never logged, and never reach the portal — and with end-to-end encryption they never reach the relay either. The relaunched worker reports the integrity level it actually obtained, so the console cannot claim an elevation that did not happen.

PCI-DSS considerations

PCI-DSS compliance is a property of an environment and an organization's processes, validated by an assessor. Software cannot be compliant on its own — it can only support a compliant deployment. Nothing here is a compliance claim.

What the design gives you:

• TLS on every link, with TLS 1.2 as a floor and an AEAD-only cipher list when the relay terminates TLS itself (Req. 4).
• A relay that forwards opaque bytes and stores no payloads, so it is a candidate to sit outside the cardholder data environment — and with end-to-end encryption, "does not look" becomes "cannot look".
• Per-session identity and per-user portal accounts with MFA (Req. 7, 8).
• Idle session reaping (Req. 8.2.8).
• Connect, disconnect, pair and file-transfer events as logging points (Req. 10).

What is still your work:

• Shipping those events to tamper-evident, time-synced central logging, with retention, monitoring and alerting.
• Certificate and key provisioning, rotation and protection (Req. 3, 4).
• Patching, hardening and access control on the relay host and every endpoint host (Req. 5, 6, 7).
• Network segmentation that positions the relay to minimize CDE scope.
• Gating backstage behind MFA, authorizing it per technician, and logging its commands — it is privileged access to the host and squarely in scope.
• The documentation, change control and SAQ or ROC with your assessor.

What this product does not do

Stated here rather than discovered during a rollout:

• It does not capture the Windows secure desktop. UAC consent prompts and Ctrl-Alt-Del are on a protected desktop that requires the worker to attach to it explicitly — a documented next step. Sign-in and lock screens are handled; backstage works before login because it needs no desktop at all.
• End-to-end encryption is negotiated, not yet mandatory. The plaintext fallback exists for older peers. Require it in policy for sensitive deployments.
• There is no consent prompt on the client for an enrolled device. The portable client is inherently consensual — the user runs it and closes it. An installed service is not, by design. If you need per-session user approval on managed machines, that is a policy and process you build around the tool.
• Endpoints are Windows only.

Operational advice

• Leave TLS certificate validation enabled in the client's relay connection. If you have a self-signed certificate, fix the certificate — do not disable the check.
• Prefer the portable client. Reserve the installed service, and especially backstage, for cases that genuinely need unattended, pre-login or SYSTEM access, and apply stronger controls to those.
• Keep join tokens out of logs and tickets: the token is the session secret.
• Rate-limit and monitor the relay: per-IP connection limits, maximum sessions, maximum message size.
• Change every default. The installer generates its own secrets, but any value you set by hand during evaluation should not survive into production.