For EU financial entities under DORA’s full ICT risk framework
Know what cryptography your code runs — before your ICT auditor asks.
A free first report against RTS 2024/1774 Article 6. You run our open-source scanner, read the one masked file it writes, and send it to us. Within two working days you get a PDF that maps the findings clause by clause, by your national authority’s rules.
See it before you ask for it
This is what you get: Cryptographic inventory and evidence under Articles 6 and 7(4)
A real report on the public project paramiko, made with qrp-dora 0.13.0 and qrp-mcp 0.44.0 on 5 November 2026. No form, no email. Yours will show your code. This sample was made from the source tree, so it also shows two sections that need the code itself: a control planted into a copy of the tree (section 1c) and the date each finding’s line entered the code (section 2b). The free first report is made from your masked scan file and leaves both out; the report we produce on your code includes them.
Summary and scopeCounts, coverage, the national profile used, and the clauses that need action — page 1.
What was foundEvery algorithm family, classified, with masked evidence by file and line.
Articles 6 and 7(4), clause by clauseReplacements under your national profile — in the sample, BSI TR-02102-1.
Download the sample report (PDF) and its CBOM (CycloneDX 1.6)
When the cryptography is in the chip
We measure your code. Your hardware supplier declares its cores. The report keeps the two apart.
A source-code scan does not observe hardware. When a hardware supplier ships a CycloneDX CBOM for its cores, the report carries it next to the scan: attributed to the supplier, identified by the SHA-256 of the file received, and never added to what the scan measured.
SOURCE 1
Code
Measured by the scan
Source, CI and infrastructure-as-code, read on your machine. Every finding tied to a file and line, masked.
In this example: a one-file demo standing in for the client’s own code, not Vicip’s. RSA found at app.py:2, quantum-vulnerable.
SOURCE 2
Hardware
Declared by the supplier
The supplier’s CBOM, carried as supplied. Each component keeps its source, and each file its hash.
In this example: Vicip Ltd. (Cyprus), ML-KEM (FIPS 203) hardware cores delivered as RTL. Three files, release 1.0.0, six components.
SOURCE 3
Network
Observed by another tool
What is negotiated on the live network.
Not part of this example.
THE SUPPLIER IN THIS EXAMPLE
Vicip Ltd. · Cyprus
Post-quantum hardware IP: ML-KEM (FIPS 203) cores delivered as RTL, in single (768), dual (512/768) and multi-mode (512/768/1024) versions, for automotive, IoT and embedded edge systems. From release 1.0 each core ships with a CycloneDX CBOM.
Announced by Vicip Not available now: an ML-DSA-44 (FIPS 204) signature core is in development, with a full release targeted for January 2027. It has no CBOM file yet and is not part of this example.
What the scan read
RSA, quantum-vulnerable, to be planned for under Art. 6(4).
What the supplier declared
Each file declares itself complete. The report records its completeness as unknown, whatever the source declares.
The six are reported beside the count, not inside it: the count covers only what this scan read.
Extract from the report, as printed
From the report built on 27 October 2026 over Vicip’s three files. Wording and hashes are the report’s own.
Cryptographic inventory and evidence under Articles 6 and 7(4)
1a. Documents received from other tools
Declared by the supplier. Carried into cbom.json as supplied, each component attributed to its source. Nothing in them was measured or verified here; their completeness is recorded as unknown, whatever the source declares.
cbom-fragment-mlkem-core.json · declared by the supplier · produced by cbom-fragment-mlkem-core.json (the document does not name its tool) · supplier named in the document: Vicip · declares itself complete
Product described: ML-KEM-768 hardware core · version stated: 1.0.0
SHA-256 of the document received: e80e156c76d27b25996e7607ff452cad529a0fda751b3298e8de4ba15bf11885
| Component | Parameter set | Execution environment |
|---|---|---|
| ML-KEM-768 | ML-KEM-768 | hardware |
cbom-fragment-mlkem-double.json · declared by the supplier · produced by cbom-fragment-mlkem-double.json (the document does not name its tool) · supplier named in the document: Vicip · declares itself complete
Product described: ML-KEM dual-mode core (512/768) · version stated: 1.0.0
SHA-256 of the document received: 76daf63b2dab0ef2411ad340f1ac2dba78a0511f1e5e415688167f7cff27c9dd
| Component | Parameter set | Execution environment |
|---|---|---|
| ML-KEM-512 | ML-KEM-512 | hardware |
| ML-KEM-768 | ML-KEM-768 | hardware |
cbom-fragment-mlkem-triple.json · declared by the supplier · produced by cbom-fragment-mlkem-triple.json (the document does not name its tool) · supplier named in the document: Vicip · declares itself complete
Product described: ML-KEM multi-mode core (512/768/1024) · version stated: 1.0.0
SHA-256 of the document received: 4edb983bbe4546cc4895dd2e6ac2f3fcce83e2ae2cb4b77fe17001082bf7076d
| Component | Parameter set | Execution environment |
|---|---|---|
| ML-KEM-512 | ML-KEM-512 | hardware |
| ML-KEM-768 | ML-KEM-768 | hardware |
| ML-KEM-1024 | ML-KEM-1024 | hardware |
· · ·
2. What was found
Total findings: 1. Distinct algorithm families: 1. By category: broken today: 0 · quantum-vulnerable: 1 · post-quantum: 0.
Separately, declared by suppliers: 6 post-quantum components in 3 documents received (ML-KEM-1024, ML-KEM-512, ML-KEM-768); see 1a. Carried as declared, not measured or verified here, and not included in the count above, which covers only what this scan read.
| Algorithm | Classification | Posture | Severity |
|---|---|---|---|
| RSA | classical, quantum-vulnerable | quantum-vulnerable | high |
3. Evidence
RSA — 1 occurrence
| File and line | Excerpt |
|---|---|
| app.py:2 | *** = rsa.********_*******_***(******_********=*****, ***_****=****) |
The one finding, RSA at app.py:2, is in the demo client code; Vicip’s six ML-KEM components are declared separately and are not counted as findings. Illustrative example. Information declared by the vendor. Elkan does not evaluate, validate, certify or endorse the product. Validation status: as declared by the vendor.
e80e156c…4ba15bf1188576daf63b…88167f7cff27c9dd4edb983b…1082bf7076d
The same three hashes were checked by Vicip and by us.
24e5a8672c05f317818a312c9172d706c2c3a5d96a336a0b5da0843b14783f7e
Same input, same timestamp: same bytes, same digest.
What this example does not show
- That the cores do what the files say. A declaration is the supplier’s statement; the report shows it as declared and does not test the hardware.
- A certificate. Vicip’s files declare
certificationLevel: noneand state: “No CAVP certificate and no FIPS 140-3 module validation.” - Your code. The measured side here is a one-file demo; yours will show your code.
- The network. A third source is not part of this example.
Our relationship with Vicip, stated openly
Elkan has a separate commercial referral relationship with Vicip outside its regulated-client assessment activities.
- Referrals involving banks, investment, payment and crypto firms carry no fee, in either direction.
- While a paid referral arrangement is active, Vicip is not put on a vendor list in a financial client’s report.
- The report’s suggested replacements name an algorithm and a standard; no product or vendor is named.
- Vicip’s files appear here with Vicip’s written permission.
Vicip ships a CycloneDX CBOM with its cores from release v1.0 onwards, declared by Vicip, in the CycloneDX standard format.Vicip’s sentence, as agreed between Vicip and Elkan
You run the scanner, read the one masked file it writes, and send it. Within two working days you get the PDF, mapped to Articles 6 and 7(4).
Check a supplier’s CBOM against its server
More suppliers now answer “what cryptography does your product use?” with a CycloneDX cryptographic bill of materials (CBOM). The file alone does not tell you whether the server you connect to does what it says.
qrp-dora asks the supplier’s server directly and compares every item with the supplier’s CBOM. For TLS it offers each candidate alone: key-exchange groups, including the ML-KEM hybrids, cipher suites and signature schemes. For SSH it reads the algorithms the server announces, without logging in.
Each item gets one result: declared and offered; offered but not declared; declared but refused; parameter differs; not expressible in CycloneDX; declared but not asked for.
No source code is needed: the supplier’s CBOM and the server’s address are enough. You receive a report in PDF and HTML with one sentence per difference, the evidence (the SHA-256 of the supplier’s file and of the observation, and when the server was asked) and what the check cannot see.
What it does not do: it is not a verdict on the supplier or on compliance. It sees one server, from one place, at one time. SSH key-exchange, host-key and MAC algorithms are listed but not judged, because CycloneDX cannot yet declare them for a server.
Tested against all 58 declaration/observation pairs of the public ShorList set.
The question your auditor will ask
The rule has been in force since 17 January 2025
DORA’s cryptographic requirements are not in the Regulation itself. They are in Commission Delegated Regulation (EU) 2024/1774, Article 6 — Encryption and cryptographic controls. It asks you to update your cryptography “on the basis of developments in cryptanalysis”, and to justify every place where you cannot. You cannot do either without knowing what you actually run.
| RTS 2024/1774 | What it asks | What the report gives you |
|---|---|---|
| Art. 6(4) | Update or change cryptography on the basis of developments in cryptanalysis | Every quantum-vulnerable algorithm in your code, with a suggested replacement by your national profile |
| Art. 6(3) | Mitigation where leading practice cannot be followed | The places where it cannot be followed, listed — the input to your exceptions |
| Art. 6(5) | A record of the measures, with justified explanations | A dated, reproducible inventory to attach the justifications to |
| Art. 7(4) | A register of certificates and the devices that store them | The certificates found in source and configuration — a start for the register (devices are not observed) |
Applies to entities under the full framework (RTS Title II). Under the simplified framework (DORA Art. 16), Title III has no cryptography article. DORA does not require an algorithm inventory as such; the inventory is the practical way to the records above.
What else is out there
Questionnaires measure your answers. This measures your code.
| Self-assessment questionnaire | This report | |
|---|---|---|
| What is measured | What you say you run | The code you actually ship |
| Time to result | Instant | Two working days |
| Sample report you can download first | Rarely | Yes — above, no form |
| What leaves your premises | Your answers | One masked file you read first |
| Regulation | General PQC guidance | RTS 2024/1774 by clause, your national authority’s rules |
| What it could not see | — | Listed, file by file |
Three steps, one file
STEP 1
Run the scanner
One command on the machine where the code lives. No account; the scan makes no network calls. --profile picks your authority: de-bsi, fr-anssi, nl-ncsc, uk-ncsc, eu-eccg.
uvx qrp-mcp scan ./your-repo --level masked --profile de-bsi --out result.jsonSTEP 2
Read it, then send it
The file is plain JSON, masked by the flag above. Open it, check it, send it. The scanner prints its SHA-256 so we can quote back exactly what we received.
STEP 3
Get your PDF
Within two working days, reviewed by a person. If you want, we walk you through it in 15 minutes.
No request needed
Every team can check its own code today
You don’t have to send us anything to find out whether you are exposed. The scanner is free and open source. Run it on any repository and you get the list of quantum-vulnerable algorithms, file by file, with what it could not read.
uvx qrp-mcp scan ./your-repo --level masked --profile de-bsi --out result.jsonThe scan tells you whether you are exposed. The report tells you what goes in your Article 6 record: each finding mapped to its clause, the replacement by your authority’s rules, what nobody looked at, and a person’s review. Send us the same file; the first report is free.
Privacy, shown rather than promised
What leaves your machine — and what does not
stays here
runs locally
you read it
and send it
the PDF comes back
In the file
- Algorithm names and key sizes
- File paths and line numbers
- Each matched line, masked:
rsa.********_*******_***(...)— only the algorithm name survives - What the scanner could not read, and why
Not in the file
- Your source code
- Keys, tokens or passwords on a matched line — masked out
- Anything from outside the folder you named
Want even less? --level trimmed drops the lines and keeps only file and line number. File paths remain in every mode.
We use your file only to write your report, delete it 30 days after we deliver the report (sooner if you ask, longer only if you ask us to keep it as your baseline), and store it on our own server — never in a third-party form service. The scanner is open source: read exactly what it emits.
One report, two readers
For the CISO or compliance lead
- An answer to “what cryptography do you run?” that is dated and reproducible
- Findings tied to RTS 2024/1774 Art. 6, clause by clause
- Replacements by the rules of your national authority, not a US list
- What the scan could not see, stated, so nobody is surprised later
- Input to your policy — never a replacement for it. Your management body still approves it.
For the engineer who runs it
- Python, via
uvx— Linux, macOS, Windows - Works offline and air-gapped
- Reads source, CI, infrastructure-as-code, configuration, certificates and keys
- Output: JSON you can diff; CycloneDX 1.6 CBOM on request
- Source on GitHub · PyPI
uvx qrp-mcp scan ./your-repo --level masked --profile de-bsi --out result.jsonWhat this report is not
- Not an attestation, and not a compliance verdict. It maps evidence to clauses. Whether your policy is adequate is for you and your auditor.
- Not complete. It reads the code under the folder you scan. Runtime keys, deployed certificates and hardware are not observed, and the report says where.
- A snapshot. One codebase, one scanner version, one date. That is the baseline everything later is measured against.
What is free, and what is not
Free
One report on one codebase. No obligation, no call required.
Subscription
Repeat scans as your code changes, and proof of what was closed since the baseline. Ask us for the price.
Who this is for
EU financial entities under DORA’s full ICT risk framework that maintain their own code: credit institutions, investment firms, authorised payment and e-money institutions, crypto-asset service providers. If you are under the simplified framework (DORA Art. 16), Article 6 does not apply to you as such; the scanner is still free.
Every report is reviewed by a person before it leaves us, so we take 10 requests a month to keep the two-working-day promise.
Request your free report
Three fields are needed. We reply with the instructions; nothing is scanned until you run it.
Next: you get the scanner instructions by email. When you send result.json, your PDF
arrives within two working days. We use what you send only to answer you.
It is stored on this server and is not passed to a third-party form service.
Questions
Is it really free?
Yes. The first report on one codebase costs nothing and commits you to nothing.
Does my code leave my machine?
Your source code does not. You send one JSON file with algorithm names, file paths, line numbers and masked lines, and you read it before you send it. Want less? --level trimmed drops the lines.
Is this an attestation?
No. It is evidence mapped to the clauses of RTS 2024/1774 Article 6. Whether your policy is adequate is for you and your auditor. The report ends by saying who may use it: you, and you may share it with your auditor, your supervisor and your insurers.
Which national rules can the report follow?
BSI (Germany), ANSSI (France), NCSC (Netherlands, UK), ECCG (EU), or NIST by default. You choose it with --profile when you run the scan.
Can we run it air-gapped?
Yes. Install once, then it needs no network. The file goes out only when you send it.
Who is behind this?
Elkan Electronic Ltd, a small company. The scanner and the reports are made by Stanimir Tenev. We also publish the Q-Day Index, a public-evidence forecast of when today’s cryptography breaks, with its method and model history in the open.
ShorList — the open catalogue we measure against
ShorList is an open, versioned catalogue of the forms in which cryptography appears in source code and configuration: 2035 rows, each with a primary source, scored on three axes (quantum, classically weak, misuse), with results for eight scanners. Data CC BY 4.0, code Apache-2.0.