Qopanza — Frequently asked questions

Last updated: 9 September 2026

The short version

Qopanza finds the cryptography in your systems that a quantum computer will eventually break, tells you what to do about it, and gives you post-quantum encryption and signing you can call from nine languages.

You can scan a site right now, without an account, at qopanza.com.

The basics

What is a quantum-safe API?

An API that helps you find the cryptography in your systems that a quantum computer would break, tells you what to replace it with, gives you post-quantum encryption and signing to replace it with, and keeps watching after you have finished.

What is post-quantum cryptography?

Ordinary cryptography — running on ordinary computers — using mathematical problems that a quantum computer is not known to solve efficiently. It replaces RSA and elliptic curve, which a quantum computer would break, and it runs on the hardware you already own.

Is this the same as quantum encryption?

No, and the confusion is worth clearing up before anyone sells you the wrong thing.

Post-quantum cryptography is classical software designed to resist quantum attack. It runs on your existing servers, laptops and phones.

Quantum key distribution (QKD) is different technology entirely — it transmits keys using quantum states, and needs dedicated fibre or line-of-sight optics between the two endpoints. It is not a software upgrade, it does not run over the public internet, and it is not what NIST standardised.

Qopanza does post-quantum cryptography. If someone offers you QKD for a web application, they are describing physics you cannot deploy.

Does this replace AWS KMS or Azure Key Vault?

No — it works with them. This one matters, because the answer changes what you are evaluating.

Those are key management systems: they store and wrap keys, and they do it well. Qopanza is about cryptographic risk — finding where quantum-vulnerable algorithms are, planning the migration off them, and proving progress.

In fact we integrate with them. Key material is envelope-encrypted, and KMS backends are supported for the wrapping key — Vault's transit engine, or AWS, GCP and Azure KMS. Bring your own. On the hosted service the wrapping key is currently held in the service environment rather than a KMS; see "Where is the wrapping key?" below.

Is this a real problem, or hype?

Both halves of that question deserve a straight answer.

The machine that breaks RSA and elliptic-curve cryptography does not exist. Anyone who tells you it is two years away is guessing, and anyone who sells you on a countdown clock is selling the clock.

What is real is narrower and harder to argue with: encrypted traffic recorded today can be decrypted later. An adversary who captures your traffic now and stores it does not need the machine to exist yet — only to exist before your data stops mattering. If what you transmit has a confidentiality life measured in years, the deadline is not when the computer is built. It already passed.

The second real thing is that the replacement algorithms are finished. NIST standardised them in 2024, and migrations of this size take years of inventory, testing and rollout before they take a day of switching. The work is the discovery, not the swap.

Why do anything about it now?

Because the first step is knowing what you have, and almost nobody does.

Most organisations cannot answer "where do we use RSA?" without a project to find out. That project is the same project whether you start it this year or in four years — except that starting now means doing it calmly, and starting later means doing it against a deadline set by somebody else.

Scanning is free here for exactly that reason. Finding out what you have should not require a purchase order.

What does it actually do?

Three things, and they are separate products that happen to fit together.

It finds quantum-vulnerable cryptography. Source code, dependency manifests, live TLS endpoints, cloud accounts and connected git repositories. The result is an inventory and a risk score, and it diffs against your previous scan so you can see what changed.

It finds ordinary application-security problems. Exposed API keys, database credentials, tables anyone can read. This one is not about quantum at all — it is about the thing that is going to hurt you this month rather than this decade.

It does post-quantum cryptography. Encrypt, decrypt, sign and verify through an API, with key management, rotation and versioning behind it.

Is the cryptography real?

Real. ML-KEM-768 for key encapsulation, ML-DSA-65 and SLH-DSA-SHA2-128S for signatures, through liboqs — the NIST-standardised algorithms as implemented by the Open Quantum Safe project.

There is a simulated backend, for developing on a machine without a C toolchain, and the service refuses to start on it outside development. That refusal is deliberate: cryptographically inert code that returns correctly-shaped values looks perfectly healthy while providing none of what this product is sold for. It is the failure mode worth engineering against, because it is silent.

Hybrid mode (X25519 combined with ML-KEM-768) is available for the common case where you want post-quantum protection without betting solely on a new algorithm.

Does it modify my code?

Only if you ask it to, and only after you approve the change. Scanning never changes anything. On App Security, Qopanza shows you the exact change to make and you (or your developer, or your AI coding agent) make it. On Pro, Fix it for me writes the change for you — and still publishes nothing until you press Approve on the exact change you were shown.

Can Qopanza fix my website for me?

Yes, on Pro, with Fix it for me. You connect where your site lives — GitHub for its code, or Netlify if that is where you publish it — and Qopanza:

1. writes the fix into your own code (or, for a Netlify site with no code repository, prepares it on Netlify),
2. shows you what it will change, in plain words, and waits for you to press Approve,
3. publishes it, then checks your live site for the next 20 minutes,
4. and puts everything back exactly as it was if your site stops working.

You can undo it yourself with one click at any time. Today it fixes missing security headers and published source maps. A leaked API key still needs you: only you can replace a key in the dashboard of the service that issued it (Stripe, AWS, Supabase and so on), and Qopanza tells you exactly where.

I can't code. Can I still use Qopanza?

Yes. The scan is written in plain English and needs no account. To fix what it finds, choose Fix it for me (Pro): you sign in to GitHub or Netlify on their own pages, choose your site, and approve the change — there is no code for you to write or paste. If someone else builds your site, every fix also comes with a ready-made message you can forward to them, or to your AI coding tool, as it is.

Does it work with sites built on Lovable, Bolt, Replit or Cursor?

Yes. The scan works on any live website, whatever built it. For Fix it for me, turn on the GitHub connection in your builder's project settings, then connect the same GitHub account to Qopanza. If you publish on Netlify without GitHub, connect Netlify instead.

Can it migrate my app automatically?

Not autonomously, and you should be wary of anyone who says otherwise.

What it does: turns an inventory into a migration plan you can approve and track, and gives you the exact fix per finding — the code edit, the config file, the SQL policy, the console steps. You can hand that to your AI coding agent and have it applied.

What it does not do is push changes to your cryptography without a human approving them. Fix it for me, which does write changes, works the same way: nothing is published until you approve the exact change you were shown. Automated, unsupervised rewriting of the code that protects your data is not a feature, it is an incident waiting for a maintenance window.

Does the AI do the scanning?

No — and this is better than if it did.

Detection is deterministic. Pattern and manifest analysis, explicit rules, a fixed algorithm taxonomy (RSA, ECDSA, ECDH, AES, 3DES, MD5, SHA-1, ML-KEM, ML-DSA, SLH-DSA). The same scan on the same input produces the same findings every time. You can diff two scans and trust the difference.

The AI does the part that follows: explaining a finding in plain English, writing the migration narrative, and producing the specific remediation. That is where a language model is genuinely good and where being non-deterministic costs nothing.

An AI that found your cryptography would be a scanner you cannot reproduce, cannot regression-test, and cannot use to gate a build. The pipeline is:

`` code + config → deterministic discovery → context and reachability → risk classification → AI explanation → remediation → monitoring ``

Marketing this as "AI-powered detection" would be a better slogan and a worse product.

How accurate is it?

Accurate enough to be useful, and not a substitute for judgement — which is the only honest answer any tool in this category can give.

Detection is rule-based, so it is consistent rather than clever: it finds what it has rules for. It produces false positives (RSA in a vendored test fixture) and false negatives (a secret with no recognisable shape, cryptography reached through an indirection no rule models).

Findings are ranked by reachability, which is what makes the list usable — RSA on your login path and RSA in a fixture are not the same problem, and a list sorted purely by severity buries the first under a hundred of the second.

Review findings before making production security changes. Anyone quoting you a percentage is quoting a number from a benchmark, not from your codebase.

Does it guarantee we are quantum-safe?

No. No tool can, and one that says it can is telling you something about itself.

It gives you discovery, risk analysis, migration guidance and continuous monitoring. It improves your quantum readiness and lets you demonstrate that it improved. It does not certify you, and it cannot see cryptography it has no rule for.

What happens to my data?

The full answer is on the security page and in the Privacy Policy. The parts people ask about first:

Your private keys are never stored beside the key that protects them. They are envelope-encrypted, and the wrapping key is never in the application database — so a database compromise alone does not yield usable keys. Where that wrapping key lives is worth being precise about, so it has its own answer below.

If you would rather we could not read it at all, we can't. Keys can be registered public-key-only. We hold no private half, so we cannot decrypt your data. There is no escrow, which means losing that key loses the data. That trade is real, and it is stated here rather than in a footnote.

API keys are stored as hashes and shown once. We cannot recover one for you. They can carry an IP allowlist.

The audit log is tamper-evident. Each entry carries a hash of its predecessor, so an alteration breaks the chain detectably. That is tamper-evidence, not tamper-proofing — anyone able to rewrite the whole table could recompute the chain. Export to your own SIEM if you need an independently held copy.

Do you store my source code?

Not your repository — but yes, a fragment of it, and vagueness here would be the wrong thing to give you.

We do not keep a copy of your code. Cloned repositories are read and discarded; nothing persists a working tree.

What we do store, per finding: the algorithm detected, the key size, the file path, the line number, and the matched line itself, truncated to 200 characters. That excerpt is the evidence — it is what lets you see why something was flagged instead of taking a scanner's word for it, and removing it would make findings unreviewable.

Three qualifications, since that is the sort of answer that needs them:

• It is one line, not a file. 200 characters, containing the cryptographic call that matched.
• It is never sent to the AI. The excerpt is excluded structurally from the object serialised to Anthropic — not filtered out of one that was.
• It is not currently field-encrypted. It sits in a managed Postgres with disk encryption, but unlike support-ticket bodies it is not additionally encrypted at the column level. If your matched lines would themselves be sensitive, that is worth knowing before you scan.

If you use Fix it for me (Pro), we also keep a copy of each file it changes, before and after the change, so that an undo restores exactly what was there. Those copies are encrypted at the column level, cover only the few files the fix touches, and are deleted with your account.

Delete your account and it goes, along with everything else, in a hard delete across every table.

Where is the wrapping key?

On qopanza.com today: in the service environment, not a KMS. Worth stating plainly, because the distinction is the whole point of asking.

Your private keys are envelope-encrypted. The key that wraps them is held in the running service's environment — separate from the database, so stealing a database backup does not yield usable keys, which is the attack this defends against. It is not, today, in a hardware security module or a managed KMS, so it is not protected from someone who already has the host.

The KMS backends are implemented and tested — HashiCorp Vault's transit engine, AWS, GCP and Azure KMS — and are what we recommend for self-hosted deployments, where you already have one. Moving the hosted service onto one is planned rather than done, and this page will say so when it changes.

If key material never leaving your control is a requirement rather than a preference, the stronger answer is client-side encryption: register a key public-half-only and we hold no private key to protect in the first place.

Is my data used to train an AI?

No. Two reasons, and the second is the one that matters:

We do not train models. There is no Qopanza model; the AI features call Anthropic's API.

And what we send to Anthropic is limited to what each feature needs — see the answer below for exactly what that is.

Do you send my source code to an AI?

Only if you use Fix it for me — and then only the few files the fix changes. This is the question worth reading carefully, because the honest answer has a shape.

Fix it for me (Pro, only when you start it) sends Anthropic's Claude the files it needs to change — at most 8, such as your server file and your build config — together with the fix our rules worked out, so it can put that fix into your code the way your code is written. Nothing is sent until you press Fix it for me, and every change it proposes is checked by our own code and shown to you before anything is published.

Everything else sends no code. AI explanations are generated by Anthropic. What we send, per finding: the algorithm name, the file path and line number, the severity, the quantum status, the standard recommendation, the detected hosting platform, our replacement recommendation, and a production/non-production/sensitive classification of the path. A prioritised plan sends up to forty findings, and so up to forty file paths, in one request.

What we do not send is the code itself. The evidence excerpt — the actual line we matched — is excluded structurally, not filtered. It is not in the object that gets serialised, rather than being removed from one that was.

File paths are not nothing. If your repository layout is itself sensitive, that is a real consideration, and the AI features are driven by a configuration setting you can leave unset — in which case nothing goes to Anthropic at all.

Who else touches my data?

Four sub-processors, all US entities processing in the United States: Stripe (payments), Anthropic (AI explanations, and writing the change for Fix it for me), Resend (transactional email), DigitalOcean (compute, network, managed Postgres). Each is driven by a configuration setting, and an unset setting means that sub-processor is not used at all.

GitHub and Netlify are not on that list: when you connect them, Qopanza acts as a client of your account, with the access you granted on their own sign-in page, and you can disconnect at any time.

The list, and what each one receives, is at qopanza.com/subprocessors. We give 30 days' notice by email before a new one starts processing customer data.

Who is this for?

• Founders who do not code — scan a live site and let Qopanza fix it.
• Developers — scan an application and its dependencies, get the fix.
• Security teams — find cryptographic exposure across an estate.
• DevOps — gate a build on newly introduced cryptographic risk.
• Enterprises — organisation-wide readiness, policy, SSO.
• Compliance teams — inventory, progress and evidence to show an auditor.

Do I need to know cryptography?

No. That is most of the point.

A finding tells you what was found, where, why it matters, and what to change it to — in plain language, with the specific edit. You do not need to know what a key encapsulation mechanism is to be told that a line in your payment service uses RSA-2048 and what to put there instead.

The depth is available when you want it. It is not required to get value on day one.

Does it work with my CI pipeline?

Yes, and this is where the product earns its keep — a scan you run once tells you about today; a scan in CI stops tomorrow getting worse.

GitHub Actions and GitLab CI integrations exist today (integrations/github-action, integrations/gitlab-ci), and there is a qsafe CLI, so anything that can run a command can run a check — Jenkins, CircleCI, a git hook, a cron job. Only the first two are packaged and tested as integrations; the others work via the CLI, and that distinction is deliberate rather than a gap we are papering over.

A typical flow:

`` git push → CI runs the scan → new quantum-vulnerable crypto? → comment on the PR / fail the build → merge blocked ``

Does it keep checking after the first scan?

Yes. Scheduled and continuous scanning covers repositories, endpoints, dependencies and cloud configuration, and inventories diff against the previous scan — so you get what changed rather than the whole list again.

What if someone adds RSA back in?

You find out.

That is what the inventory diff is for. A new finding that was not in the previous scan is surfaced as new, not buried in a list of two hundred things you already knew about. If it violates your organisation's cryptographic policy, the policy engine can act on it, and the CI check can fail the build that introduced it.

Migrating off RSA is a project. Staying off it is a control, and the second one is the harder problem.

Can I get a report for my auditor?

Yes — cryptographic inventory, identified risks, migration progress and quantum-readiness, exportable as point-in-time attestations with full history.

A report we generate is not a certification. It is evidence you can hand to an auditor, and an auditor's opinion is a different artifact produced by a different party. We are careful about that word and you should be too when a vendor is not.

Can I get the inventory in a machine-readable format?

Yes — a CBOM, exported from the Inventory tab or from GET /v1/inventory/cbom.

A CBOM is an SBOM for cryptography, standardised as CycloneDX 1.6 (also published as ECMA-424). It lists every algorithm found in your estate, one component per algorithm and key size, each carrying its NIST quantum security level and an occurrence list naming every file and line where we saw it. Anything that reads CycloneDX reads it.

The reason to care before anyone asks: Executive Order 14412 names cryptographic inventories in the US federal post-quantum programme, and agencies pass that down to suppliers. The EU Cyber Resilience Act and DORA point the same way. The request tends to arrive with a deadline attached.

The matched source line is deliberately excluded. A CBOM gets emailed to auditors and attached to questionnaires; the file path and line number are enough to find the code, and the code does not need to travel with them.

The output is ordered deterministically, so two exports of an unchanged estate produce an identical file and a diff shows only what really moved.

How do I get told when something changes, without logging in?

Register a webhook. The dashboard's Notifications tab lists every event this platform sends, lets you point an HTTPS endpoint at them, and shows whether deliveries actually arrived. Full reference in docs/webhooks.md.

The quickest way is Slack, and it needs no code: in Slack, Apps → Incoming Webhooks → Add to Slack, pick a channel, copy the URL, and paste it into the Notifications tab. Alerts then arrive as readable messages in a channel your team already watches. Anyone who prefers to receive raw JSON at their own endpoint — a ticket queue, a SIEM, their own code — can choose that instead, and gets a signed payload.

The one worth wiring up first is discovery.new_findings: scheduled discovery re-scans your connected repositories and fires this when the result differs from last time. That is the difference between "we scanned last year" and "two findings appeared on Tuesday" — and it only reaches you if something is listening.

Deliveries are signed with HMAC-SHA256, retried with backoff for up to six attempts, and recorded either way, so you can tell a quiet week from a broken endpoint. Nothing here sends email: an alert in a mailbox beside everything else is an alert nobody acts on.

Which compliance frameworks do you cover?

Three, and each is scoped rather than claimed wholesale:

• NIST PQC readiness — the algorithm transition itself.
• SOC 2 — platform-observable controls only. The subset a tool can actually see: encryption, key management, logging, access. Not the organisational controls, which no scanner can assess.
• ISO 27001 Annex A — cryptography and logging controls. Again a subset, and named as one.

"Supports SOC 2" would be a bigger claim and a false one. A tool can score the controls it can observe; the rest of the framework is about how your company operates.

How long does a scan take?

Small repositories: minutes. Large estates with many repositories, cloud accounts and endpoints: longer, in proportion to what there is to read.

We are not going to quote you a number, because we do not yet have enough production data across enough differently-shaped codebases for an average to mean anything. A published figure derived from three scans would be marketing, not information. Ask us once you have run one and we will tell you what yours did.

What does it cost?

Four plans: Free, App Security, Pro and Enterprise. Current prices are on the pricing page in the dashboard — this page deliberately does not carry a number, because a price in two places is a price that is wrong in one of them.

Free finds the problems. Scanning, the application security scan and the post-quantum crypto API are free, and the findings are never truncated or hidden: every problem, where it is and why it matters. A scanner that will not tell you which of your keys leaked is selling fear rather than a product, and the person who most needs to know is usually the one least able to pay.

App Security shows you how to fix them. The exact fix for each finding, written for your stack — the code edit, the config file, the SQL policy, the console steps — and a message you can forward to your developer or AI tool. You (or they) make the change, and the next scan tells you whether it took.

Pro fixes them for you, and adds what stays scarce: Fix it for me (Qopanza writes the change, publishes it when you approve, checks your site and undoes it if anything breaks); continuous and scheduled scanning with CI gating; migration planning you can execute and track; and audit evidence an auditor accepts.

Enterprise adds SSO enforcement — requiring everyone on the account to sign in through your identity provider, so access is granted and revoked in one place. It is there because it is the thing that most often blocks a purchase outright, not because it is a nice-to-have.

Can I cancel?

Yes, from the billing page, and you keep access to the end of the period you have paid for. If we change the Terms materially you get 30 days' notice, and if you cancel over it we refund the unused remainder.

Do you offer a trial?

The free tier is the trial, and it does not expire. You will know whether the scanner finds anything in your estate within about ten minutes of signing up, which is a better answer than a fortnight of access to features you have not evaluated yet.

Are you SOC 2 certified?

No. SOC 2 readiness is in progress, and the dashboard says "in progress" rather than anything warmer.

What exists today: the control documentation, an incident response policy, a tamper-evident audit log, encryption at rest and in transit, and a described access model. What does not exist is an auditor's opinion on any of it. Those are different things and we are not going to let the first be mistaken for the second — a vendor that lets a prospect walk away believing it is certified has a problem that surfaces later, in due diligence, at the worst possible moment.

If your procurement process requires a SOC 2 Type II report, we do not have one. That is a straight no, not a "coming soon".

Will you sign a DPA?

Yes — ask at support@qopanza.com. It is a negotiated document rather than a published one, so it comes with a conversation.

It commits to notifying you within 48 hours of becoming aware of a breach. That is tighter than GDPR's 72 on purpose: you are the controller, and you cannot start your own clock until we start yours.

Do you offer a HIPAA BAA?

No. HIPAA is not a certification and there is no scan that produces one; signing a BAA is an assertion about how the whole business operates, and we are not in a position to make it. If you process PHI, this is a constraint you need to know before you evaluate anything else.

Where are you based?

Gsente LLC, a Colorado limited liability company, registration 20238145743, at 3750 Blake St, Denver, CO 80205. Colorado law, Colorado courts.

We currently sell to businesses in the United States only. Not to consumers, and not into the UK or EEA — the GDPR gives rights our documents do not yet describe, and we would rather say so than let you assume. If you are outside the US and want to use it, email us and we will tell you where we stand.

Who is behind this?

Gsente LLC — a small company, and small enough that you should ask this question before buying security software from it.

So, plainly: this is not a large team, and there is no 24/7 SOC behind it. What that changes is response times and coverage hours, and it is worth weighing.

What it does not change is whether the engineering is real, and that part you can check without taking anyone's word for it:

• The nine client libraries are published on the public registries under their own names. Read them.
• The cryptography is liboqs. Verify the version the API reports.
• Every claim on the security page names a specific mechanism, not an adjective, precisely so it can be checked.
• The public scanner runs without an account. Point it at something you already know is broken and see whether it agrees.

That last one is the fastest form of due diligence available, and it costs nothing.

What is it not?

Worth being explicit, because a security tool that oversells its scope is worse than one that never ran:

• Not a pentest, and not a substitute for one. It finds classes of problem it knows how to look for.
• Not a WAF, an EDR, or a SIEM. It exports to your SIEM; it is not one.
• Not a guarantee. Redaction, scanning and classification are known-shape work. A secret with no recognisable shape passes through, and we say so rather than implying completeness.
• Not a compliance certificate. The compliance centre scores your estate against SOC-2-shaped controls. That is a scoring tool, not an attestation, and no auditor accepts it as one.

For engineers

The questions that come up once someone has decided the product is plausible and started reading the API.

If you shut down, is my data lost?

No, and this is the most important technical answer here.

Encryption is a standard KEM-DEM construction with no proprietary envelope:

1. ML-KEM-768 encapsulates to your public key, producing ciphertext_kem and a 32-byte shared secret.
2. That secret is the AES-256-GCM key. A random 12-byte nonce and the result is ciphertext_payload.

Every field comes back base64-encoded in the response. Given your private key, liboqs and any AES-GCM implementation, you can decrypt entirely offline — no Qopanza, no network, in about fifteen lines of Python. There is no format to reverse-engineer because there is no format: it is ML-KEM-768 and AES-256-GCM, and the response names both.

That is deliberate. A cryptography vendor whose ciphertext only it can read is selling a hostage situation, and nobody should accept one.

Can I self-host it?

Yes. docker-compose.yml in the repository brings up the API, Postgres and Redis. You supply your own keys and it talks to nothing external unless you configure it to — no Stripe key, no SMTP host and no AI key means those integrations are simply off.

Two things to know if you do: the published policies at /terms and /privacy are ours, compiled into the dashboard bundle, and are not yours — replace them before pointing anyone at those routes. And you own your own key backups.

What are the rate limits?

60 requests per minute on Free, ×10 on Pro, ×500 on Enterprise, keyed on the account.

A throttled response carries Retry-After and X-RateLimit-Limit, both exposed through CORS so browser code can actually read them.

Rate limiting fails closed. If Redis is unreachable the limiter rejects rather than waves traffic through. That is the correct default for a security product and it does mean Redis is a hard dependency, not a cache.

If I rotate a key, can I still read old data?

It still decrypts. Rotation creates a new key version linked to its predecessor rather than overwriting material in place:

`` Production key ├── v1 superseded (still decrypts) ├── v2 superseded (still decrypts) └── v3 active (encrypts + decrypts) ``

New encrypt and sign operations use the active version; older versions stay usable for decrypt and verify until you explicitly revoke them. Rotation that breaks old ciphertext is not rotation, it is a data-loss event with a reassuring name.

Should I use hybrid mode?

Probably, if you are protecting data with a long confidentiality life. X25519+ML-KEM-768 combines a classical and a post-quantum KEM so the result is at least as strong as the stronger of the two. It costs you bytes and a little latency, and it means a break in either algorithm alone does not expose you.

Pure ML-KEM-768 is the right choice when you are constrained and the threat you care about is specifically quantum.

How do I verify a webhook?

HMAC-SHA256 over the raw request body, sent as sha256=<hex>. Compare against the body before parsing it — re-serialising JSON changes bytes and breaks the comparison.

Retries reuse the original signature rather than re-signing. A retry that re-signed would carry a different sent_at, so a receiver verifying signatures would reject exactly the deliveries that most need to arrive.

What files does the scanner read?

Source and dependency manifests across C, C++, C#, Go, Java, Kotlin, JavaScript, TypeScript, JSX/TSX, Vue, PHP, Python, Ruby, Rust, shell, Terraform, and the usual config formats (JSON, YAML, TOML, INI, XML, HTML). Plus live TLS endpoints, connected cloud accounts and git repositories.

Findings are ranked by reachability, not just severity — RSA in a vendored test fixture is not the same problem as RSA on your login path, and a list sorted purely by severity buries the second under the first. Inventories diff against the previous scan, so you see what changed rather than re-reading the whole thing.

Will it give me false positives?

Some. It is pattern and manifest analysis, not proof. It flags things that look like cryptography in places that look like they matter, and it is wrong in both directions sometimes — a secret with no recognisable shape passes straight through.

Anyone claiming zero false positives on this class of tool is either tuning to miss things or has not run it on a real codebase.

Is there an OpenAPI spec?

Yes, docs/openapi.json, and the dashboard's TypeScript types are generated from it with a CI check that fails on drift. The nine SDKs are generated from the same spec and hand-finished.

List endpoints paginate with X-Total-Count, X-Limit and X-Offset, all CORS-exposed.

How do I export or delete my data?

Export from the dashboard, or DELETE /v1/accounts.

Deletion is a genuine hard delete across every table, not a hidden flag, and it is immediate and irreversible. You can run a dry-run first that shows exactly what would be destroyed. One audit record survives — that a deletion happened, when, and how many rows went, carrying no personal data — because otherwise we could not later prove we did what you asked.

Do you offer an SLA?

Not a contractual one today. Be suspicious of a small vendor that offers a heavily-penalised uptime SLA — either it is not enforceable or it is not honest. Ask for one when your spend justifies negotiating it.

How do I start?

1. Scan something at qopanza.com — no account, nothing to install.
2. Sign up if the results were useful. The free tier stays free.
3. Install an SDK — Python, TypeScript, Go, Rust, Java, C#, Ruby, PHP or C++ — and make your first encrypted call.

Which language should I use?

Whichever you already use. All nine are clients of the same API and the cryptography runs server-side, so none of them implements cryptography itself and none is more "real" than the others.

Go has no registry by design — go get fetches from the repository directly. C++ builds from source, because there is no dominant registry to publish to.

Something is broken. Who do I tell?

• A vulnerability → security@qopanza.com. We will not pursue legal action against good-faith research conducted within our disclosure policy.
• Anything else → support@qopanza.com.

Every 500 the API returns carries a request ID. Quote it and we can find exactly what happened.

Short explainers on post-quantum cryptography and app security are in Learn.