QNova Client · The vault

The enterprise password manager that never uploads a password

Every credential is sealed on the device that uses it. Each secret gets its own envelope: key encapsulation against a local ML-KEM-768 public key, a content key derived by HKDF-SHA256, and AES-256-GCM with a random 96-bit nonce. Storage is local only. No cloud, no sync, and no vault of ours to breach.

What it is

The spreadsheet everybody agreed was temporary

Nearly every company has one. The shared login for the invoice portal, the router password, the account nobody can remember signing up for, all sitting in a file called something like logins final version three. It was a stopgap for one afternoon, and that afternoon was three years ago.

Every secret sealed on its own

Not one large encrypted blob holding everything. Key encapsulation runs against a local ML-KEM-768 public key, the content key comes from HKDF-SHA256 with domain separation per widget and version, and the secret itself is sealed with AES-256-GCM under a random 96-bit nonce.

Secure notes in the same envelope

Titles are list metadata, bodies are encrypted secrets. It is the place for recovery codes, licence keys and the sensitive fragments that were never going to fit in a password field.

The extension fills the form

Form detection that survives single-page apps, inline fill control anchored to the field you are standing in, a verification step before it offers to save anything, and open windows that update immediately instead of after a restart. Chrome and Edge.

Import and export both work: in from Apple Passwords and Safari, Chrome, Edge, Firefox, Bitwarden and generic CSV with automatic header detection, and out in a format Bitwarden or a browser will read. Nothing here is a trap on the way out.

The mechanism

A secure password manager is mostly a question about where the copy lives

Switch the vault into a vendor cloud and watch what leaves the machine. Then switch the extension onto a local HTTP port and watch who else can reach it.

No copy of your vault exists anywhere else.

Every secret is sealed on its own rather than kept in one large encrypted blob: key encapsulation against a local ML-KEM-768 public key, a content key derived by HKDF-SHA256 with domain separation, and AES-256-GCM under a random 96-bit nonce. Storage is local only, so there is no vault of ours to lose. Switching to a vendor cloud shows the copy leaving the machine. The browser extension reaches the application over a channel the operating system brokers to one registered executable; switching to a local HTTP port shows the other process that can then reach it too.

Why this exists

Four things that go wrong without it

The shortlist is a data residency decision

Almost every option asks you to move the secrets into somebody cloud, in a data centre you cannot point to. For a regulated buyer that is not a feature comparison, it goes to legal.

An encrypted vault copied today can be opened later

Kept now, opened once the maths that sealed it stops holding. Passwords are the worst thing to lose on a delay, because people reuse them for years.

The recovery flow is somebody else design

Account recovery is the soft edge of every hosted vault, and it is the part you do not control and cannot audit.

The extension usually talks over an open port

A local HTTP server is the common shortcut, and it means any process on that machine can knock on the door and start a conversation.

What you get

A self hosted password manager without the server to defend

The person who runs the endpoints wants one less service to patch. The person who signs for it wants the residency question to disappear. Same design, read two different ways.

For the endpoints

There is no server for you to run

A self hosted password manager gets you the same control and hands you a server to patch, back up and defend. This skips the server. The vault lives on the endpoint, inside the QNova Client.

The extension channel is brokered by the operating system

A direct channel to one registered executable, with no HTTP server on localhost in a production build. It is worth opening a terminal and checking what your current one does.

A widget people can put where they want

The vault sits on the client desktop beside secure notes. Positions survive a restart, and removing a widget does not destroy what is in it.

For the business

A company that never holds your vault cannot lose it

It cannot be subpoenaed for it either, and it cannot have a bad Tuesday that turns into your incident report.

The residency question stops being a question

The secrets are on the endpoints you already own, in the country those endpoints are in. There is nothing to negotiate with legal about where they sit.

The secrets are sealed against a later machine

The envelope is post-quantum on every secret, not just on the connection around them, which is the part that matters for something copied today and opened in ten years.

How it works

Three steps, and none of them leave the machine

The secret is sealed where it is created

You add a credential in the vault widget and it is encapsulated against the local public key on that machine. The content key is derived per widget and per version, so two secrets never share an envelope, and nothing about the operation needs a network.

The extension asks the application, not a port

When you land on a login form, the extension reaches the client over a channel the operating system brokers to one registered executable. It detects the form, offers to fill the field you are standing in, and verifies before it offers to save anything new.

It stays there, and leaves when you ask it to

There is no sync step, because there is nowhere to sync to. When you want the secrets elsewhere, export writes a file a browser or Bitwarden will read. The way out is as plain as the way in, on purpose.

Before you start

You need the QNova Client on the machine, and the extension from the Chrome or Edge store if you want form filling. There is no server to stand up and no account to create with us.

In detail

The envelope, and the channel nobody checks

Envelope

What sealing one secret actually involves

Key encapsulation runs against a local ML-KEM-768 public key. The content key is derived with HKDF-SHA256, with domain separation per widget and per version so two secrets never end up under the same derived key. The secret is then sealed with AES-256-GCM under a random 96-bit nonce.

The consequence of doing it per secret rather than per vault is that opening one thing does not open everything, and re-encrypting one thing does not mean rewriting the whole store. Secure notes use exactly the same envelope: the title is list metadata, the body is an encrypted secret.

Channel

How the extension reaches the application

A desktop vault and a browser extension have to reach each other somehow, and the usual shortcut is an HTTP server listening on localhost. It works, and it also means any process running on that machine can knock on that door.

This one uses the browser native messaging channel instead: brokered by the operating system to one registered executable, framing JSON over a pipe rather than opening a port on the machine it is supposed to be protecting. There is no HTTP server on localhost in a production build.

Where this earns its place

Four mornings this changes

The shared spreadsheet finally gets retired

The router password and the invoice portal login move into sealed entries on the machines that use them, and the file called final version three stops being the system of record.

Legal asks where the credentials are stored

On the endpoints, in the country those endpoints are in. There is no third party holding a copy, so there is no transfer to paper over.

Somebody leaves and takes their laptop knowledge with them

Export writes a readable file, so the handover is a file rather than a negotiation with a vendor about getting your own data back.

An auditor asks how the browser extension talks to the vault

Over a channel the operating system brokers to one registered executable, with no port open on the machine. That is checkable from a terminal in about a minute.

Works better with

What sits around the vault

Multi-factor authentication

A password manager removes reuse. This removes the value of a password that leaks anyway.

Post-quantum cryptography

The envelope on every secret, which is what protects a vault copied today and opened much later.

Data loss prevention

Stops the credential file leaving by the other routes, which is how these things usually travel.

User management software

Who has a client at all, and therefore who has a vault. The membership question sits one level up.

What this does not do

The limits, because they are what make the rest believable

There is no sync between your own devices

Storage is local only, and that is the design rather than a gap in it. A secret added on the laptop is not on the desktop. If you need the same credential in two places, you put it in two places, or you export and import.

We cannot recover a vault for you

We never hold a copy, so there is nobody here who could. Losing the device without an export means losing what was in it. That is the honest price of the rest of this page, and you should read it before a demo rather than after.

It does not manage secrets for machines

This is a vault for people at a keyboard. Service accounts, API keys held by servers and automated rotation are a different product category and we do not pretend otherwise.

The extension is Chrome and Edge

Those are the two shipped today. Anything else is a browser you would be filling by hand, and there is no date on this page for others because we do not have one.

Questions people ask

The ones that come up first

What makes this an enterprise password manager rather than a personal one?

It is deployed and governed with the rest of the fleet through QS-WAN and the QNova Client, rather than being something each person signs up for separately. What it does not do is put the secrets in a company cloud, which is the usual meaning of the word enterprise here.

Where are the passwords stored?

On the device that uses them, sealed one secret at a time. There is no cloud copy and no sync service, so there is no vault of ours that could be breached, subpoenaed or lost.

Is this a self hosted password manager?

It gets you the same control without the server. Self-hosting means standing up something you then have to patch, back up and defend. Here the vault lives on the endpoint and there is nothing in the middle.

What happens if I lose the device?

If you have an export, you restore from it. If you do not, the secrets are gone. We hold no copy and cannot recover one, which is the direct consequence of the storage being local only.

How does the browser extension talk to the application?

Over the browser native messaging channel, which the operating system brokers to one registered executable. There is no HTTP server listening on localhost in a production build, which is worth checking against whatever you use today.

Can I bring my existing passwords in, and take them out again?

Both. Import reads Apple Passwords and Safari, Chrome, Edge, Firefox, Bitwarden and generic CSV with automatic header detection. Export writes a format Bitwarden or a browser will read.

Bring the spreadsheet. We will seal the first ten entries.

An engineer, a machine shaped like yours, and as long as you need. Bring a terminal too and check whether anything is listening on a local port. It is free and there is nothing to sign.