QNova Client · Assisted support

Remote support software with no password to steal

Two things have to be true before anyone sees your screen. The device is already on the VPN and cryptographically authenticated, and the person at the keyboard accepted this session. There is no remote desktop password, because there is nothing to type one into.

Where this is today: in integration phase, not fully productised. Everything described below is built. It is not a finished product yet, and we would rather you read that here than find it out on a call.

What it is

The risk was never the screen share

Support tools get judged on how fast they connect, and that is the wrong thing to measure. A support session hands one person full control of the machine of somebody else. So the question a security team actually asks is not how quickly it connects. It is what has to be true before it can. Most remote tech support software answers that with a code: six digits read down the phone, a PIN, a link. Codes get shared, reused, screenshotted into a group chat, and read out to whoever rang up and said they were from IT.

Both ends are already on the VPN

Cryptographically authenticated, before a session is possible at all. Identity comes from the network, not from something typed in.

The host accepted this session

Not sessions in general, not once at install time. This one, now. That is the two-factor authorisation, and neither half can cover for the other.

There is no socket to knock on

The host never listens for inbound traffic. Before consent there is literally no socket to talk to, which is a stronger sentence than saying the port is firewalled.

And the agent on the device usually sits there listening for a connection all day, whether a session is happening or not. That listener is the part worth worrying about. A door that is always there is a door somebody can knock on.

The mechanism

Try to connect without asking, and watch nothing answer

Then refuse a session, and watch the refusal get written down with a name and a time, exactly like an acceptance. Most tools only log the sessions that happened, which quietly makes declining invisible.

no socket on the host, nothing is listening

An administrator on the left, a relay in the middle that holds no keys and keeps no recording, and a host device on the right. Both ends are already on the VPN and cryptographically authenticated. Below the host is a slot that reads no socket: until the person at the keyboard accepts, there is nothing on that device listening for a connection, so the button that tries to connect without asking finds nothing to talk to and the attempt is written down. Asking for a session issues a single-use ticket that lives thirty seconds and carries around 190 bits of entropy. Accepting opens an end-to-end encrypted session through the relay. Refusing closes the attempt, and the refusal is written to the audit trail with a name and a timestamp, exactly like an acceptance.

Why this exists

Four things this category usually gets wrong

The standing listener

Every laptop becomes permanently reachable so that support is convenient on the rare day it is needed. That is a design decision, and it is the wrong one.

The shared secret

A code puts the security of the session in the hands of whoever on your team is most tired and most helpful at four on a Friday.

The relay that sees too much

Holding keys or recordings on infrastructure that has no business holding either turns a support tool into a second place your screen lives.

A second identity system to run

Most of these arrive with their own server, their own directory of accounts, their own patch cycle and their own opinions about who still works here.

What you get

One authorisation model, two people it has to satisfy

The person who runs support wants to reach a machine without a ritual. The person who signs for it wants to know what had to be true before anyone could.

For support

Nothing to knock on between sessions

The host does not listen for inbound traffic. There is no window during which a laptop is reachable just in case somebody needs help later.

No second directory to keep honest

The identity is the device identity the network already checked on the way in, so there is no separate manager with its own accounts and its own leavers process.

The list is devices that answered 20 seconds ago

A heartbeat every 20 seconds is what puts a device on the list and makes it reachable at all, so the list is current rather than a memory of last Tuesday.

For the business

The step people get wrong is removed, not trained

Nobody reads a password out loud to somebody they cannot see, because there is no password to read. Removing the step beats training it away.

A refusal is an answer, on the record

Declining is an event with a name and a timestamp. The person at the keyboard does not have to explain a no afterwards, and you can show that the no happened.

The relay cannot become a liability

It holds no key material and keeps no recording. It moves bytes it cannot read, and both ends are already inside a post-quantum tunnel.

How it works

Three steps, and the person at the desk owns the second

The device is visible, because it said so 20 seconds ago

Before a device can be helped it has to be visible. The QNova Client sends a heartbeat every 20 seconds, and that heartbeat is what puts the device on the administrator list in QS-WAN and makes it reachable for support in the first place. That part is in production today. It also means the list is devices that answered 20 seconds ago, rather than devices that were online last Tuesday.

You ask, and the person at the desk chooses

A session needs a ticket that works once, lives 30 seconds and carries around 190 bits of entropy. It is not a password, it cannot be reused, and it has expired before anyone could finish reading it out loud. The person sees who is asking, and accepts or refuses. Refusing ends the attempt and is recorded, so not now is an answer rather than a thing to explain afterwards. There is also a directory of colleagues currently present, so asking for help does not start with three messages working out whether anybody is around.

The session runs through a relay that cannot read it

End-to-end TLS, and the relay holds no key material and keeps no recording. Both ends are already inside the tunnel, and that tunnel uses post-quantum cryptography like every other channel here. Everything is audited, refusals included.

Before you start

You need the client on both machines and both of them on the network. There is no support server to stand up and no directory of support accounts to maintain, because the identity is the one the network already checked.

In detail

The ticket nobody reads out, and the broker that stays blind

Tickets

Single use, thirty seconds, and not a password

A session needs a ticket that works once, lives 30 seconds, and carries around 190 bits of entropy. It is not something anybody types, reads out or writes down, and it has expired before a phone call could pass it along.

That is the difference between a secret people handle and a secret nobody ever touches. A six digit code is a secret people handle, which is why it ends up in a group chat and why it works just as well for the person who rang up claiming to be from IT.

Relay

A broker that moves bytes it cannot read

The host never listens for inbound traffic, so the session goes through a relay rather than a direct connection. The relay holds no key material and keeps no recording. The session itself is end-to-end TLS, and both ends are already inside a tunnel that uses post-quantum cryptography.

What you get from it is an audit trail of who asked, who answered and when. Not a video. A refusal is written exactly like an acceptance, which is the part most tools skip: when only the sessions that happened get logged, declining becomes invisible.

Where this earns its place

Four mornings this changes

Somebody rings up saying they are from IT

There is no code to read out, so the oldest social engineering script in the category has nothing to ask for.

A colleague needs help and does not know who is around

The directory shows who is present, so asking for help does not start with three messages working out whether anybody is there.

An assessor asks who can reach the laptops

Nobody, between sessions. The device does not listen, and the audit trail shows every request, every acceptance and every refusal.

The person at the keyboard says not now

That is an answer, and it is recorded as one. They do not have to justify it afterwards, and you do not have to take their word for it.

Works better with

What makes it reachable, and what often makes it unnecessary

Remote device management

The console side of the same heartbeat, and everything you can do to a gateway without a session on anybody screen.

Network traffic monitoring

Often the thing that makes a session unnecessary: the graph and the connection details the person can read out to you.

Secure remote access

The tunnel this lives inside. Support here is a channel within the network you already run, not a way onto machines outside it.

Post-quantum cryptography

What the tunnel around the session is built on, and why the relay being blind is not just a promise about behaviour.

What this does not do

The limits, starting with the one at the top of the page

It is in integration phase

The mechanism is built and that is why it is described plainly here. It is not a fully productised feature yet, and we are not going to write it as one. Ask us for its current state before you decide anything on it.

It does not do unattended access

If nobody is at the machine to accept, nobody connects. That is the design working as intended, and it is also a real limit: a device sitting alone overnight cannot be fixed this way.

It does not record sessions

The broker keeps no recording and holds no key material. You get an audit trail of who asked, who answered and when. Not a video.

It does not reach a device that is not on the network

No heartbeat, no visibility, no session. It is a support channel inside the secure remote access you already run, not a way onto machines that live outside it.

Questions people ask

The ones that come up first

What is remote support software?

It lets an IT person see and control the device of somebody else to fix it, without walking to their desk. Every product in the category differs on one question: who is allowed in, and how is that proved.

Is there a password or a code?

No. There is nothing to type one into. Authorisation is two separate facts at the same time: the device is already on the VPN and cryptographically authenticated, and the person at the keyboard accepted this session. Neither half can cover for the other.

Can somebody connect while nobody is looking?

No. The host never listens for inbound traffic, so before consent there is literally no socket to talk to. An attempt to connect without asking finds nothing to answer it, and the attempt is written down.

What happens if the person refuses?

The attempt ends, and the refusal is recorded with a name and a timestamp exactly like an acceptance. Most tools only log the sessions that happened, which quietly makes declining invisible.

Does the relay see my screen?

No. The session is end-to-end TLS, and the relay holds no key material and keeps no recording. It moves bytes it cannot read, and both ends are already inside a tunnel using post-quantum cryptography.

Do we need a separate support server for this?

No. Most tools in the category arrive with their own remote support software manager: a server, a directory of accounts, a patch cycle, and its own opinions about who still works here. Here the identity is the device identity the network already checked on the way in.

Ask us where this is, and we will tell you plainly.

We show you the authorisation model on a real pair of devices, refuse a session on purpose so you can see the refusal land in the audit trail, and answer honestly about what is finished and what is not. It is free, it lasts as long as you want, and there is nothing to sign.