Request Demo
ZENQIX Assist
Preview

Remote support

Govern technician access as an authorized support session rather than treating remote control as an anonymous connection.

AvailabilityPreview
WorkflowDiscover → Act → Verify → Prove
Evidence model5 evidence elements
EvaluationAcceptance checklist
Operational need

What the administrator needs to solve.

Remote access solves the immediate support problem but can create a governance problem if technician identity, authorization and session evidence are unclear.

Current approach

How ZENQIX handles it.

ZENQIX treats remote support as a controlled workflow: technician, authorization, target endpoint, session, result and audit evidence.

Workflow

Requested action and verified outcome stay separate.

01Technician requests access
02Authorization is checked
03Target device binding is resolved
04Session is launched
05Session ends and evidence is retained
Capability

What is currently in scope.

Authenticated remote-support launch path

Endpoint-to-remote-node binding

Controlled session brokering

Session-oriented audit architecture

Future terminal/file actions where supported

Platform status

Availability by operating system.

WindowsPreview

Physical customer acceptance remains staged.

macOSPreview

Production broker integration exists; broader physical acceptance remains staged.

LinuxPreview

Physical customer acceptance remains staged.

Synthetic product model

Inspect the state the UI needs to expose.

This panel uses synthetic data. A genuine ZENQIX Endpoint screen can replace it only after sanitization and publication approval.

Open Product Proof
ZENQIX Endpoint · Remote supportPreview
Requested / observed stateCapability-specific endpoint state
EvidenceTimestamped, bounded and tenant scoped
VerificationShown separately from execution

Security

  • Broker authentication
  • Per-action authorization boundaries
  • No public Windows RDP forwarding requirement
  • Remote node identifiers normalized only at the integration boundary

Evidence

  • Technician identity
  • Target endpoint
  • Launch request
  • Authorization result
  • Session timestamps where available

Technical detail

  • Remote-support infrastructure is separated from the public marketing website
  • Product storage preserves the raw remote node identifier and normalizes at the broker boundary
FAQ

Technical questions for this capability.

Is ZENQIX Remote Support just remote desktop?

No. The intended product model includes authorization, technician identity, target binding and auditable session context around the remote tool.

Does it require exposing RDP/3389 publicly?

The current architecture does not require public Windows RDP forwarding.

Evaluate remote support in your environment.

Use the capability matrix and the written acceptance checklist to confirm whether the current status matches your pilot needs.