Methodology · Rubric v2.0
How the Q-Signal™ score is calculated
The Q-Signal™ score is an external evidence score from 0 to 100. This page documents exactly what a scan observes, how points are awarded, what earns no points and what the score does not establish — so any organization can check, reproduce or challenge its own result.
Scope
An evidence score, not a verdict.
Every scan submitted to the PlancKey Q-Signal™ Index receives a Q-Signal™ score from 0 to 100. The score measures the post-quantum cryptography (PQC) evidence visible on the domain’s public HTTPS endpoints at the time of the scan.
Points are awarded only for positive, provider-reported observations. Missing evidence lowers the score and reduces a separate measure called evidence coverage, but it is never reported as a vulnerability.
- The score is not a NIST certification or a conformance statement against FIPS 203 / 204.
- It is not a prediction of compromise or a general security grade.
- It covers only the public HTTPS endpoints returned during the scan — not an organization’s whole attack surface.
Inputs
What a scan observes.
- DNS records (A, AAAA, MX, CAA) resolved through public DNS-over-HTTPS resolvers.
- TLS assessments of the domain’s public HTTPS endpoints, performed by an independent third-party assessment provider. Provider results may be cached for up to 24 hours; a fresh scan may therefore repeat a recent observation.
- The domain’s public homepage metadata, read only after the domain resolves to public addresses, and used solely to suggest a sector for anonymous benchmarking.
PlancKey connects only to public endpoints. We do not install software, request credentials, or access internal systems.
Rubric v2
Hostnames weigh equally.
Each scan assesses the submitted domain plus common public hostnames — www, api, app, login and portal — when they resolve exclusively to public addresses.
Both components below are calculated per hostname, then averaged across hostnames with equal weight. A hostname served from many addresses counts no more than one served from a single address, so a partial rollout (for example the website but not the API) shows as a partial score. Version 1 scores, which assessed the submitted domain only, are not comparable with version 2.
Component 1 · 70 points
Key exchange.
70 points × the fraction of each hostname’s returned endpoints with provider-reported PQC key-exchange support.
An endpoint earns its share of these points only when the assessment provider actually tested the endpoint’s supported key-exchange groups and reported at least one post-quantum or hybrid group (ML-KEM-based exchange, such as X25519MLKEM768). Endpoints that were never tested earn nothing — the gap is recorded as unverified evidence, not as classical-only support.
Component 2 · 30 points
Certificate authentication.
30 points × the fraction of each hostname’s endpoints where every returned leaf certificate has both a recognized PQC public key and a recognized PQC issuer signature.
Recognized algorithms are ML-DSA (44, 65 or 87) and SLH-DSA (SHA-2 or SHAKE basis, 128, 192 or 256 security level, plain or fast variants). Classical keys and signatures — RSA, ECDSA, Ed25519 and related — earn no certificate points. Both conditions must hold for every returned leaf certificate on the endpoint; a mixed chain earns nothing for that endpoint.
Rules
How evidence is counted.
- All returned endpoints stay in the denominator. A score cannot be improved by having fewer endpoints observed.
- Untested checks earn zero and are labeled unverified — never vulnerable. Zero means “no positive evidence was observed”.
- Rounding happens once, at the end. The two weighted components are summed and only the total is rounded.
- No usable PQC evidence means no number. When TLS evidence is still pending or the provider returned no usable checks, the report shows “Pending” or “Unscored” instead of a score.
- These items never earn points: conventional TLS protocol versions and grades, HSTS headers, certificate expiry dates, DNS record counts and mail routes. They appear in the report as operational context only.
Interpretation
Score bands.
Scores are grouped into five bands. Band names describe observed evidence, not safety.
| Score | Band | What it reflects |
|---|---|---|
| 0 | No PQC evidence | No positive PQC evidence was observed on any assessed endpoint. This is not a statement that the domain is vulnerable. |
| 1–39 | Early signals | PQC signals on a minority of assessed endpoints. |
| 40–69 | Partial adoption | PQC signals on a majority of assessed endpoints, not yet near-complete. |
| 70–99 | Strong signals | PQC signals on most assessed endpoints; at least one endpoint still lacks full evidence. |
| 100 | Full observed support | Every assessed endpoint reported PQC key exchange and PQC certificate authentication. |
Change control
Versioning.
This rubric is version 2.0. Every report and Index profile displays the rubric version that produced its score.
Scores are comparable only within the same rubric version. If we change how points are measured or weighted, the version number increases; earlier scores remain attached to the version that produced them, and sector benchmarks never mix scores across versions.
Recourse
Questions and disputes.
If your organization believes its score does not reflect current reality:
- Re-run the free scan. Provider results can be cached for up to 24 hours, so a change you just made may need a day to appear.
- Verify with your CDN, hosting or certificate provider which key-exchange groups and certificate algorithms your endpoints actually advertise.
- If you believe a specific observation is factually wrong — for example the wrong domain was assessed or evidence was mapped to the wrong endpoint — contact us through a demo request with the domain and the report in question.
We correct demonstrated factual errors, such as domain resolution or evidence-mapping mistakes. We do not adjust points outside this published rubric, and listed organizations are treated exactly like any other scan.
Boundaries
What the score does not establish.
- That clients actually negotiate post-quantum key exchange — advertised server support is not negotiated support.
- Migration of the full certificate chain, including intermediate and root authorities.
- Mail encryption, VPN gateways, subdomain inventory, internal applications, libraries and key stores.
- Resistance to every current or future attack. A 100 does not mean “quantum-proof”, and PlancKey makes no such promise.
Inventory of internal cryptography, migration planning and continuous monitoring are offered as separately scoped engagements described on the product page.
Rubric v2.0
