QS-WAN · Company Policy

Security policy management, signed before it leaves the console

Security policy management here means one signed policy per device. The console merges three scopes, gateway, user and device, into a single envelope, signs it, then sends it. The client hands those exact bytes to a system service, which checks the signature before a single rule applies.

What it is

The gap between what you set and what actually runs

Every administrator has had this moment. You set a rule in the console. The console turns green. And you still do not know whether the laptop living in the back of a car has ever heard of it. That gap is where IT security management usually breaks, and it is rarely a bad tool. It is that the two halves of the job sit in different places: the rule gets decided centrally, and it gets enforced on a machine you cannot see, by an agent a local administrator can argue with and usually wins. So you end up with a security management system that reports intent and calls it enforcement.

Three scopes, merged before anything is signed

A rule can be set on the gateway, on the user, or on one device. The three get merged first, so a device receives one policy instead of three that contradict each other.

Four mandate levels, chosen per rule

Not mandated, Soft, Enforced and Reactive. Soft sets a default the person can still change. Enforced takes the choice away. Reactive goes further, and it has its own section below, because it does not cover every rule.

Twelve rules in the catalogue

That is the whole catalogue. We would rather write the number than say granular controls and let you find out later. The envelope is signed with ML-DSA and carries a version that only ever goes up.

Is that rule on quietly becomes: it should be.

The mechanism

Ask the device to be stricter. Then ask it to be looser.

One of those two is accepted and one is refused, and the difference between them is the rule the whole engine is built on. Then replay an old envelope and watch the version number do its job.

merged to Enforced, version 7, applied

One rule, removable storage, set on three scopes at once: the gateway says Enforced, the user scope says Soft, and the device scope says not mandated. The three merge before anything is signed, so the device receives one policy rather than three that contradict each other, and the merged answer here is Enforced. The envelope carries the allowlist, the device id, the time it was issued and a version number, and it is signed with ML-DSA. On the device a system service verifies that signature against a pinned key before a single rule applies. A device asking to be stricter than its mandate is accepted and the merged level rises. A device asking to be looser is refused and nothing changes. An envelope replayed with version 5 while the device already holds version 7 is refused, because the version only ever goes up.

Why this exists

Four things that go wrong without it

Three scopes that disagree arrive as three answers

When the gateway, the user and the device each hold a version of the same rule, the device has to pick, and whatever it picks was nobody decision.

The agent rewrites the policy it was given

When an agent reads a policy, turns it into its own config format and enforces that, whoever can reach that config file has become the policy author.

An old policy can be handed back to a device

Without a version that only goes up, yesterday envelope is as valid as today one, and a tightening can be undone by replaying what came before it.

The person on the laptop has no idea what changed

When the policy is a rumour, every change becomes a support call that starts with somebody saying they cannot do something any more.

What you get

One envelope, two people who need it to be true

The person who sets the rule wants it to be the rule that runs. The person who signs for it wants to know what the word enforced is actually worth on a machine nobody can see.

For the fleet

One policy per device, not three

The merge happens before signing, so a device never has to reconcile a gateway rule, a user rule and a device rule at the moment it needs to enforce one.

The bytes that get checked are the bytes that were signed

The client relays the envelope verbatim. It does not parse it, re-serialise it or sign its own version, so there is no config file in between for anyone to edit.

Stricter yes, looser no

Someone who wants more protection than the company asked for can have it. Someone who wants less cannot. That is one rule sitting above all the mandate levels.

For the business

A number instead of the word granular

Twelve rules. You can read the catalogue before you buy, rather than discovering its edges during a rollout.

Replay stops being a way back

The version is strictly increasing per device, so an old policy handed back to a device arrives carrying an old number, and old numbers lose.

The person can read their own policy

The device keeps a readable snapshot on disk, so when a colleague says they cannot do something any more, the answer is already on their computer, naming the rule and the scope it came from.

How it works

Three steps, and the middle one is the one that matters

You set one rule, in whichever scope it belongs to

Gateway, user or device. QS-WAN merges the three before anything is signed, so what leaves the console is a single deterministic envelope carrying the allowlist, the device id, the time it was issued, the rules and a version number. It is signed with ML-DSA, the post-quantum signature standard, the same as everywhere else here.

The client carries it, and never reads it

The QNova Client does not parse the policy. It does not re-serialise it, tidy it up, or sign its own version. It relays the exact bytes, verbatim, to a system service, and that service verifies the signature against a pinned key before anything is applied. The engine on the device then has three strengths, Enforced, Soft and None, with one rule above all of them: a device can always be stricter than its mandate, never looser.

The person on the device can see what changed

The device keeps a readable snapshot of its current policy on disk, and the client reports its own state back rather than waiting to be polled. When policy changes, it arrives as a notification like any other event on the machine. Support calls get a lot shorter when the policy is not a rumour.

Before you start

You need the client on the devices you want governed. The catalogue is twelve rules, so the useful preparation is deciding which of them you actually want to mandate, and at which level.

In detail

Who is allowed to author the policy, and where Reactive stops

Transport

The client is transport, not authority

This is the part that decides whether everything above it is real. When an agent reads a policy, rewrites it into its own config format and then enforces that, the signature covers the document that arrived rather than the thing that runs. Whoever can reach the config file of that agent has just become the policy author.

Here the bytes that get checked are the bytes that were signed. The client relays them verbatim to a system service, and that service verifies against a pinned key. It is a quiet failure mode in plenty of security policy management, and it is worth being fussy about.

Reactive

The mandate that acts without waiting for you

On a critical alert, the VPN access of the device is revoked and the control channel closes with code 4008. A device that slept through the revocation wakes up without the capability rather than with it, which is the only way fail-closed means anything.

Now the honest bit. Only 8 of the 12 rules arm the reactive engine. On the other four the console still offers Reactive, and what you get behaves like Soft. That is an asymmetry in the product, and you should know which four rules before you build a process around them. Ask on a call and we will name them.

Where this earns its place

Four mornings this changes

A rule has to be tighter for one team only

You set it on the user scope and leave the gateway alone. The merge happens before signing, so that team gets one policy and everybody else keeps theirs.

Somebody wants to be stricter than the company asked

They can. A device may always exceed its mandate. The only thing it may never do is fall below it.

A laptop comes back after three weeks in a bag

It gets the current envelope, not the one it left with, because the version it is holding is older than the one that arrives.

A colleague says they cannot do something any more

The readable snapshot on their own machine names the rule and the scope it came from. That is a two-minute call instead of a twenty-minute one.

Works better with

What travels in the envelope, and what signs it

USB device control

One of the twelve rules, and the one people ask about first. It travels in exactly the envelope described here.

Endpoint detection and response

The protection settings behind the agent are policy too, which is why they arrive signed rather than as a visit to each desk.

Post-quantum cryptography

What the envelope is signed with, and why the signature is worth checking against a pinned key in the first place.

Endpoint security

The problem this gets bought for, with the rest of what happens on a machine you will never physically see again.

What this does not do

The limits, because they are what make the rest believable

It does not prove that an offline device complied

The database is authoritative for intent and propagation is best effort. A green response proves the instruction was recorded, and it converges when the device comes back.

It does not promise automatic revocation on every rule

Only 8 of the 12 rules arm the reactive engine. On the other four the console still offers Reactive and what you get behaves like Soft. We would rather print the number than the word always.

It governs twelve rules, not every setting on a machine

This is policy for the things the catalogue covers. It is not a general device management suite and it does not pretend to be one.

Nobody here is watching your fleet

This is a product, not a managed service. There are no analysts of ours looking at your network, and a policy engine is not a replacement for someone reading the alerts.

Questions people ask

The ones that come up first

What is security policy management here?

One signed policy per device. Three scopes, gateway, user and device, are merged into a single envelope in the console, the envelope is signed with ML-DSA, and a system service on the device verifies that signature against a pinned key before a single rule applies.

What happens when two scopes disagree?

They are merged before anything is signed, so the device receives one policy rather than three that contradict each other. Nothing is left for the device to reconcile at the moment it has to enforce something.

Can a device be stricter than the company policy?

Yes, and that is deliberate. A device can always be stricter than its mandate and never looser, so somebody who wants more protection than was asked for can have it, and somebody who wants less cannot.

Can an old policy be replayed at a device?

No. The version is strictly increasing per device, so an old envelope arrives carrying an old number, and old numbers lose.

Does Reactive work on every rule?

No. Only 8 of the 12 rules arm the reactive engine. On the other four the console still offers Reactive and the behaviour you get is Soft. Ask us which four before you build a process around them, and we will name them.

Can the person on the device see the policy?

Yes. The device keeps a readable snapshot of its current policy on disk, and changes arrive as a notification. When somebody says they cannot do something any more, the answer is already on their computer, naming the rule and the scope it came from.

Ask us which four rules, and we will name them.

We walk the twelve rules with you, set one on three scopes at once and show you the merge, then try to loosen it from the device so you can watch it be refused. It is free, it lasts as long as you want, and there is nothing to sign.