Questions, answered plainly.

Almost all encryption in use today protects its key exchange with mathematics a large quantum computer would solve quickly. Nobody is known to have built one. The difficulty is that traffic recorded today can be stored and decrypted later, so data whose confidentiality has to outlast the arrival of such a machine is already exposed — the recording happens now, the decryption happens whenever it becomes possible. This is usually called harvest now, decrypt later.

No. A cryptographically relevant quantum computer is not known to exist, and the US Office of Management and Budget said so in writing. Today’s TLS is doing its job against today’s attackers. The question is not whether it is broken but how long the data behind it has to stay secret. Traffic that stops mattering in a year is a different problem from a medical record or a signing key. The dated positions are on the timelines page.

That depends entirely on who regulates you, and the honest answer is that most published guidance recommends rather than requires. A few instruments do bind — a US executive order, and one Swiss canton’s directive for its own administration — and most do not. Every date we could verify is on the timelines page, marked binding or not, because the difference between the two is routinely lost when these dates are repeated.

There is no single answer, which is itself the useful thing to know. Authorities disagree: one mandates a single parameter set and nothing else, another approves a wider set including algorithms built on different mathematics, and one cantonal administration permits two that the first forbids. A product compliant in one place can be non-compliant in another. The positions are set out side by side.

It depends who is asking. A hybrid key exchange combines a classical algorithm with a post-quantum one so that breaking either alone is not enough, and several authorities require exactly that. At least one framework gives it no credit at all and counts anything short of fully post-quantum as not aligned. It also matters that a quantum-safe handshake in front of a classical certificate is not the same as being ready, and a report that counts it as ready is measuring the wrong thing.

More than the algorithm name in a configuration file. Post-quantum signatures are considerably larger than the ones they replace, and that size lands on every certificate, every chain and every handshake — which breaks buffers, embedded clients and hardware long before it breaks anything cryptographic. The work is usually a dependency-mapping exercise that ends in cryptography, rather than a cryptography exercise.

Because the work is spread across everything that terminates or validates a connection: certificates, protocol libraries, appliances, embedded devices, code-signing, and anything holding archived data. Historically the journey from a standard being published to it being fully integrated has been measured in decades rather than years. The migration page sets out the phases and where each one usually goes wrong.

With an inventory, because every later decision depends on it. You cannot prioritise what you cannot see, and in most estates the gap between what the configuration management database says exists and what the network actually answers to is the finding. Ranking by how long the data must stay secret comes next, not by how easy a system is to change. The six phases are described here.

It finds the certificates, protocols, cipher suites and key exchanges in use across an estate, keeps them in one inventory, grades them against a policy you control, and reports readiness against published frameworks. It is a measurement and governance tool: it tells you what you have and how far it is from where it needs to be.

It is not a certificate authority and does not issue or renew anything. It is not an internet-wide scanner — it only scans the target list you curate, and every destination is checked against a guard before a connection is made. It is not a SIEM. It measures and grades; the remediation is yours to carry out.

No. It opens a TLS connection and reads what the endpoint offers — protocols, cipher suites, certificate chain, key exchange — and records the result. There is no path in the software that issues, renews, deploys or reconfigures anything on a scanned host. The host scanner reads certificate stores and configuration on the machine it runs on; it does not modify them either.

Four ways, and most estates need more than one. It performs an active TLS handshake against endpoints you list or discover by sweeping a network range. A host scanner runs on the machine itself and submits an inventory of certificates, keys, libraries and services. A remote engine covers segments the server cannot reach. And anything you cannot scan at all can be imported as certificate files, a CBOM, or a pasted host list.

Not for network scanning, which needs nothing on the target. A host scanner is only needed where the network cannot see inside — Windows certificate stores, internal certificate authorities, machines with no listening service. It can be run permanently, or once and removed, or run remotely over SSH or PowerShell Remoting without installing anything at all.

A remote engine — a small container you deploy inside the segment. It opens one connection outward to Post Quantum Leap and receives its work down that connection, so no inbound firewall rule is needed and the server holds no address for it. It runs the same scans there, and host scanners inside that segment submit to it rather than needing their own route out.

Wherever you run it. Self-hosted, everything stays in your database on your infrastructure. If we host it for you, it runs in a Swiss region and the data stays in Switzerland under Swiss law. The deployment options are set out here.

No. There is no telemetry and no licence check-in. The only outbound connections the software makes are ones you configure yourself — your identity provider if you enable single sign-on, and a certificate authority if you ask it to obtain its own certificate automatically. Nothing reports to us.

Yes, and that case shaped several decisions. Endpoints download the host scanner from Post Quantum Leap itself rather than from the internet, the trust anchors it validates against ship with it, and there is no licence call to fail. Scan profiles for offline and air-gapped machines are included.

Three roles, each containing the one before it: a reader who can view the inventory, dashboards and reports; an operator who can add targets, run scans, import certificates and set governance attributes; and an administrator who can change policy, users, sign-on and the schedule. Every configuration change is recorded with who made it and what it was before, and that record is searchable.

With local accounts, or through your identity provider using OpenID Connect — including Microsoft Entra ID, with accounts provisioned on first sign-in. SAML is not supported yet and is on the roadmap.

Several, including the NIST post-quantum standards, CNSA 2.0, BSI TR-02102, PCI DSS and FINMA’s guidance for Swiss institutions, each as a separate report with its own rules. Each states what it cannot establish as plainly as what it can — the FIPS report cannot confirm that a module was formally validated, and says so rather than implying it. Reports are independent of your own grading policy, so an auditor sees the framework’s rules rather than yours.

It can if you let it, so the scan rate is configurable down to a deliberately slow mode, and scheduled scans use the same setting. Scans traverse your existing proxies where you have them. It is still worth telling whoever watches the intrusion detection system before the first full sweep.

Yes. Any filtered view exports to Excel or to a CycloneDX CBOM, either the whole selection or just the rows you picked, and every compliance report exports as well. The entire configuration and inventory can be moved between instances as a single file. There is no format here you cannot read without us.

As containers, with a database and a reverse proxy that terminates TLS and obtains the instance’s own certificate. That runs under Docker or Podman, on a container host in your own cloud, or in a data centre. A Kubernetes chart is on the roadmap rather than available today. The architecture is drawn out here.