Built for organizations, not just individuals
Everything QNSQY does for a single user, it also does for a team: post-quantum hybrid encryption, signatures, and the full Business feature set, governed centrally. An owner sets up the organization, adds members, assigns roles and sets a signed encryption policy, and we connect your identity provider for single sign-on. QNSQY on each device fetches that policy and applies it before any data is touched.
Honesty note. QNSQY is not SOC 2 audited and not FIPS 140-3 validated. It implements the NIST-standardized algorithms (FIPS 203, 204 and 205, and SP 800-208). The algorithm libraries it ships pass the NIST ACVP test vectors, and NIST vectors are also replayed through QNSQY's own code; passing test vectors is not the same as a certified module. Current certification status, and what is planned, lives on the Certifications page.
Organizations, members & roles Shipping
Create an organization with an owner and add members by email. Roles are owner, admin, and member. Owners and admins manage members in the org-admin portal; only the owner can add admins or change the organization's settings. A person belongs to one organization at a time, and your plan's seat limit is enforced. In the portal you add people who already have a QNSQY account; when we set up your organization, we can also create accounts for people who do not have one yet.
Magic-link onboarding Shipping
New members do not receive a password in their inbox. They receive a single-use sign-in link that is valid for 72 hours. During setup we can create an organization and its owner in one step; each new person then comes in through their own link.
- During setup, we create the person's account, or the organization together with its owner.
- The person receives a single-use sign-in link by email. No password is ever emailed, and we cannot choose one for them.
- They follow the link within 72 hours, set their own password, and join the organization with their assigned role.
Single sign-on: OIDC Shipping
Each organization can sign in through its own identity provider over OpenID Connect. To set it up, contact us: we configure and test the connection for your organization. SAML 2.0 is not available yet. For terminals and automation, the command line signs in with the RFC 8628 device-code flow: it shows a short code, you approve it in a browser within 10 minutes, and the session is bound to your organization. No long-lived secret is copied onto a server.
Two ways your people authenticate
Browser SSO (OIDC): standard OpenID Connect against your identity provider.
Command line and headless (RFC 8628): device-code flow for terminal-first and SSH-only environments.
Signed, client-enforced encryption policy Shipping
An organization sets a versioned encryption policy in the org-admin portal. Our server signs it with Ed25519, and QNSQY on each device checks that signature with a public key built into the program, so a policy changed in transit or on disk is ignored, and the device then applies only its local policy. QNSQY merges the organization policy with any local policy and applies the stricter of the two, so a non-compliant operation is refused before any data is processed.
In practice you can require, for example, a key-exchange level, an allowed list of algorithms, or a signature on every file across the whole team, and each device enforces it where the data is. A device fetches policy changes when its cached copy is more than an hour old and it next reaches our server, or at once with qnsqy policy sync.
Per-organization audit log Shipping
Changes to members, roles, organization settings, policy and single sign-on are recorded in a per-organization audit trail that owners and admins can review. This is the organization-level record of who changed what; it is distinct from the tamper-evident, hash-chained operational audit log that the client produces for cryptographic operations (see Security).
Recovery: escrow, threshold, and vault Shipping
QNSQY's zero-knowledge design means we cannot recover a forgotten password for you. For organizations that need continuity anyway, QNSQY ships recovery controls you operate yourself: escrow, threshold sharing and recipient groups on the Business plan, and the vault on Pro and up.
01
Key Escrow & Recovery
An organizational escrow key pair lets you recover data without the user's password. Escrow works only in an organization build of QNSQY that carries your escrow public key; the standard download has escrow switched off, so contact us to set it up. Each recovery is recorded in the local audit log. qnsqy escrow-keygen, qnsqy escrow-decrypt.
02
Threshold Recovery (Shamir M-of-N)
Split a secret into N shares and require any M to rebuild it, or encrypt a file to N recipients so that any M of their keys open it. Constant-time GF(28) arithmetic with a BLAKE3 MAC authenticating each share. For splitting recovery authority across trusted people. See Shamir's Secret Sharing.
03
Encrypted Vault
A built-in AES-256-GCM secret store behind an Argon2id-derived master key, for the credentials and keys your team needs to keep but not expose. Pro and up. qnsqy vault (init, add, get, list, edit, remove, rekey, export, import).
04
Recipient Groups & Policy
Define named recipient groups for threshold encryption and enforce organization-wide encryption baselines, so the right people can decrypt and the wrong configurations are refused. qnsqy group, qnsqy policy.
Where the controls live
Organization, identity, and policy controls map to concrete surfaces in the product. This is the same vocabulary you will see in the org-admin portal and the CLI.
| Capability |
Where |
Status |
| Organization & identity |
| Organizations, members, owner / admin / member roles | Org-admin portal | Shipping |
| Magic-link onboarding (single-use, 72h) | Organization setup, with us | Shipping |
| SSO via OpenID Connect | Set up with us | Shipping |
| SSO via SAML 2.0 | — | Not available yet |
| RFC 8628 device-code login (command line, headless) | Command line | Shipping |
| Policy & audit |
| Ed25519-signed, versioned encryption policy | Org-admin portal → each device | Shipping |
| Enforcement on the device (stricter of organization and local policy) | QNSQY on each device | Shipping |
| Per-organization audit log (members, roles, settings, policy, SSO) | Org-admin portal | Shipping |
| Recovery |
| Key escrow & recovery (Business; needs an organization build) | Command line (escrow-keygen, escrow-decrypt) | Shipping |
| Threshold recovery, Shamir M-of-N (Business) | Command line (split / combine, threshold-encrypt / threshold-decrypt) | Shipping |
| Encrypted vault (Pro and up) | Command line (vault) | Shipping |
| Not shipping yet |
| HSM key wrapping (YubiKey, TPM, cloud HSM) | — | Not available |
| Offline licence for disconnected networks | CNSA 2.0 edition | Built and tested internally, not released |
Not shipping yet Not yet
Two enterprise controls are not shipping yet. We list them so procurement teams can plan, and so nobody buys on a promise. There are no release dates.
- HSM key wrapping. Keeping the data-encryption key in hardware, such as a YubiKey, a TPM or a cloud HSM. It is not a shipped, supported feature.
- Offline licence. The CNSA 2.0 edition runs on an offline licence file, signed with ML-DSA-87 and bound to one device, so a disconnected network never reaches our billing server. It is built and tested internally and not released. The Standard edition checks in online; after a check, paid plans keep working offline for up to 7 days.
Approved-mode and CNSA 2.0 builds
Built and tested internally. Not yet released.
For teams that need approved algorithms only, we have built an approved-mode build. The choice is fixed when the program is built, the program runs start-up self-tests before first use, and features that are not approved are refused. For defense and national-security users, the CNSA 2.0 build narrows it to ML-KEM-1024, ML-DSA-87, AES-256-GCM and SHA-384/SHA-512, signs every encrypted item with ML-DSA-87 (opening an item requires the sender's public key), and runs with an offline licence bound to one device and no network use. Both run on Linux x86-64 and Windows x64; on Windows they were tested in a Windows 11 virtual machine.
QNSQY is not FIPS 140-3 validated. QNSQY holds no CMVP certificate, and no lab has tested it. The CNSA 2.0 build carries no NSA, NIAP or CSfC approval. There is no release date yet; contact us about availability and pricing. What each edition allows and refuses: the three editions.
Certifications, honestly
We do not claim certifications we do not hold. QNSQY is not SOC 2 audited and not FIPS 140-validated. It implements the NIST-standardized post-quantum algorithms, and its algorithm libraries pass the NIST ACVP test vectors. That is a different and weaker claim than a validated cryptographic module. For the current state of each, see the Certifications page.