QS-WAN · Enrollment

Device enrollment that hands out an identity, not a password

Device enrollment is how a new laptop gets a cryptographic identity on your network. An admin sends a single-use token by email. The device then generates its own post-quantum key pair locally, registers the public halves, and connects. The private keys never leave that machine, and the token burns on first use.

What it is

Most devices still get onto a network with something copyable

A pre-shared key, a config file on a USB stick, a password read out over the phone, a profile forwarded just this once to a colleague who needed it on a Friday. They all have the same flaw. Whatever proves the device is allowed on the network is a thing that can be copied, and if you copy it, you are the device. The network cannot tell the two apart, because there is nothing there to tell apart.

An invite with a token

You create the device in the console and the system issues one token for it. The token is stored as a hash, never in the clear. It is valid for 48 hours, it is never reused, and it burns the moment it is used. It reaches the user by email, over your own SMTP server.

Keys generated on the device

The QNova Client creates an ML-KEM key pair for key exchange and an ML-DSA key pair for signatures, and it does both locally. The private halves are written into the protected profile on that machine. Regeneration is idempotent, so running it twice does not leave you holding two identities for one laptop.

Only the public halves travel

The console records them against that device, and that is what turns a name in a list into something you can verify later. The device then connects and proves it holds the private keys it claimed.

Ask anyone who runs a fleet how many copies of the current VPN profile exist and watch their face. Nobody knows. There is no way to know, which is why the honest answer is usually a shrug and a change of subject.

The mechanism

The question nobody asks the vendor: where was the private key born?

Two enrollment systems can look identical on an architecture diagram and be completely different underneath. One question separates them. Switch between the two below and watch what moves.

The private key has never left the laptop.

An admin creates the device in the console and one single-use token goes out by email, stored as a hash and dead after 48 hours. The laptop generates an ML-KEM key pair for key exchange and an ML-DSA key pair for signatures, both locally, keeps the private halves and sends only the public halves back. The badge flips to PQ enrolled. Switching to the other way shows the private key being made on the server and travelling down the wire, which is the moment it stops proving that only this laptop can hold it. Using the token a second time shows it refused, because it burned on first use.

Why this exists

Four things that go wrong without it

Nobody knows how many copies of the profile exist

A shared secret has no edition number. Once it has been forwarded once it has been forwarded an unknown number of times, and there is no honest way to count.

A key made on a server is a key that travelled

If it existed in two places it no longer proves that only this device can hold it. That is not a technicality. It is the entire reason for having a key instead of a password.

A token that works twice is a password in a better jacket

Reusable enrollment secrets are the quiet default in a lot of products. Single use, hashed at rest, dead at 48 hours whether anyone used it or not.

A device can describe itself confidently and be believed

Everything a device says about itself, including its own name, is treated as a claim rather than as fact, so it cannot talk its way into another tenant.

What you get

One identity per machine, and nothing to read out loud

The person who runs the fleet wants a first connection that cannot be forwarded. The person who signs for it wants a sentence they can give an auditor. Same four steps, read two different ways.

For the fleet

No key material of yours in our hands

The private halves are created on the machine and stay there. We never hold a copy, so there is no copy of ours for anyone to take.

One badge tells you it finished

The device list flips from PQ pending to PQ enrolled when the public keys are registered. You do not go hunting through a log for the confirmation.

Running it twice is safe

Regeneration is idempotent. A second run does not leave you holding two identities for one laptop, which is the usual way these things go wrong at scale.

For the business

The onboarding step stops being a phone call

No certificate authority to explain, no signing request to email back, no twenty-minute call where someone reads a fingerprint out loud.

An answer for the question auditors ask

Where the private key was generated, and whether the enrollment secret can be reused, are both answerable in one sentence each.

The worst news wins the colour

When several badges apply, pending removal beats revoked, revoked beats expired, expired beats online. A device queued for removal never gets to look healthy.

How it works

Three steps, and the person only does one

You create the device and one token goes out

You add the device in the QS-WAN console and the system issues a single token for it. It is stored as a hash, never in the clear, and it travels to the user by email over your own SMTP server. If SMTP is not configured, nothing else on this page happens, and that is worth knowing before you start rather than during.

The laptop makes its own keys and registers the public halves

The person opens the client and pastes the token. The client generates the key pairs locally, writes the private halves into the protected profile on that machine, and sends only the public halves up. The token burns on that first use.

The connection is attested, and the badge flips

The device connects and proves it holds the private keys it claimed. In the device list the badge moves from PQ pending to PQ enrolled, and that flip is the confirmation that matters. From there the identity feeds certificate lifecycle management and every access decision above it.

Before you start

You need an SMTP server configured, because the token goes out by email, and the QNova Client on the machine. Nothing else is installed, and no hardware is required.

In detail

The badges, and where each key half lives

Badges

The six states a device can be in

The device list carries six status badges: Online, VPN connected, Pending removal, Revoked, PQ enrolled and PQ pending. Devices tied to a declared asset also carry an asset tag with the name on it.

PQ pending means the token is out and the device has not used it yet. PQ enrolled means the public keys are registered and that device now has a post-quantum identity. When more than one badge applies, the colour follows a fixed order: pending removal beats revoked, revoked beats an expired certificate, expired beats online, and online beats VPN connected. The worst news wins the colour.

Keys

What is generated, and where it is written

Two key pairs per device, both created on the machine. ML-KEM for key exchange and ML-DSA for signatures, with the private halves written into the protected profile on that machine and never sent anywhere.

Regeneration is idempotent, so a second run reconciles rather than duplicating. Only the public halves are registered against the device in the console, and everything the device reports about itself is treated as a claim to be verified rather than as fact.

Where this earns its place

Four mornings this changes

A new starter on their first morning

The token is in their inbox before they sit down. They paste it once, the client does the rest, and nobody has to read a fingerprint down the phone.

A laptop is replaced after a failure

The old device is revoked and the new one gets its own token. The identity does not move between machines, because it never could.

Somebody forwards the invite to a colleague

The second attempt is refused. The token burned on first use, so the forward is worth nothing rather than worth a second device on your network.

An auditor asks where the private key was generated

On the device, and it has never been anywhere else. That is one sentence, and it is the same sentence every time.

Works better with

What the identity feeds, once the device has one

Certificate lifecycle management

Enrollment is the first certificate. This is the whole life of it after that, including a revocation that sticks.

Multi-factor authentication

Enrollment proves the device. It does not prove the person, and this is the control that does.

Mobile device management

A profile is a person and a person carries several devices. Enrollment is how each one of them joins.

Post-quantum cryptography

The key pairs generated here are the post-quantum ones, which is why the badge says PQ enrolled rather than just enrolled.

What this does not do

The limits, because they are what make the rest believable

It does not prove a person

It proves a device holds a private key that was generated on that device. Who is sitting in front of it is a different question, answered by the profile and by multi-factor authentication, not by enrollment.

It does not work without email

The token reaches the user over your SMTP server. If that is not configured, the invite never goes out and nothing else on this page happens.

It does not reach a machine that is switched off

The console record is authoritative the second you save it. Getting it out to the gateways and the device is best effort, so a green tick proves the intent was recorded, not that a laptop in a drawer has acted on it.

It is Windows, Linux, macOS and Android today

iOS is planned. You will not find a date on this page, because we do not have one to give you yet.

Questions people ask

The ones that come up first

What is device enrollment?

It is how a new machine gets a cryptographic identity on your network. An admin creates the device in the console, one single-use token goes out by email, the device generates its own post-quantum key pair locally, registers the public halves, and connects. The private keys never leave that machine.

Where is the private key generated?

On the device. It is written into the protected profile on that machine and is never sent anywhere. We never hold a copy, so there is no copy of ours for anyone to take. If a system generates the key on a server and sends it down, it existed in two places and travelled between them, and it no longer proves that only that device can hold it.

Can the enrollment token be used twice?

No. It is single use, stored as a hash rather than in the clear, and it burns the moment it is used. It also dies at 48 hours whether anyone used it or not. A forwarded invite is therefore worth nothing.

What happens if I run the enrollment twice on the same laptop?

Nothing bad. Regeneration is idempotent, so the second run reconciles rather than leaving you with two identities for one machine.

How do I know the enrollment finished?

The badge in the device list flips from PQ pending to PQ enrolled. That means the public keys are registered and the device has a post-quantum identity. You do not have to go hunting through a log for it.

Which operating systems does it cover?

Windows, Linux, macOS and Android today. iOS is planned, and there is no date on this page because we do not have one.

Bring a laptop. We will enroll it while you watch.

An engineer, a console shaped like yours, and as long as you need. You send the token, the machine makes its own keys, and you try to use the token a second time. It is free and there is nothing to sign.