A cryptographic discovery pilot is a short, bounded exercise that inventories the cryptography behind one business service, environment or regulated function, scores what it finds, and decides where to look next. Run over 30 days, it proves the discovery method on something real before anyone has to commit to covering the whole estate. This post sets out a four-week structure, and how it lines up with what the UK’s National Cyber Security Centre (NCSC) expects a discovery engagement to deliver.
Most organisations that try to start a cryptographic inventory stall at the same point: “discover everything” is not a project, it’s an unbounded commitment, and nobody signs off on unbounded commitments. The result is a lot of intent and very little inventory. The fix is not to shrink the ambition, it’s to shrink the scope.
Week 1: scope a boundary, not the estate
Pick something specific and bounded: a payment-processing chain, a customer-facing web tier, a single business unit already in scope for a compliance deadline. The boundary should be small enough to finish discovery on in two weeks, but real enough that the findings matter to someone. Define what “done” looks like before you start – a concrete, checkable outcome, not an open-ended search.
PCI DSS Requirement 12.3.3 is a useful model for what a finished inventory should contain. It requires cryptographic cipher suites and protocols in use to be documented and reviewed at least once every 12 months, including an up-to-date inventory of all of them, with their purpose and where they are used. It was a best practice until 31 March 2025 and is now required. Not just “we use TLS”, but which versions, which cipher suites, what for, and where.
Write the boundary down. The most common way a pilot fails is scope creep in week one, where “just the payment API” quietly becomes “also the three services it talks to and the database behind them”.
Week 2: run discovery across the boundary, using more than one method
No single discovery method sees the whole picture, even within a small boundary:
- Network discovery finds live TLS negotiations and the certificates services present, but says nothing about what is hard-coded in an application’s source.
- Source-code and repository scanning finds algorithm calls, key sizes and embedded keys or secrets in the codebase, but says nothing about what a service actually negotiates in production.
- PKI and certificate-store discovery maps issued certificates, their validity periods and their signature algorithms.
- HSM and key-management discovery reaches keys that never appear on the wire at all.
A pilot that only runs one of these will come back with a partial answer and mistake it for a complete one. That is a worse outcome than not running the pilot, because it produces false confidence. Cover the boundary from at least two angles. If the scope includes both an application and the certificates it presents, run both a repository scan and a certificate discovery against it, and reconcile what each one finds.
Week 3: score the findings, don’t just list them
A list of findings is not a risk position. A count of RSA-2048 keys and TLS 1.2 endpoints tells you volume, not priority. Score each finding against what it actually protects. Does it sit in front of data with a long confidentiality requirement, where a harvest-now-decrypt-later attacker gains from capturing it today? Does it sit on a system that is easy to remediate, or one wired into a decade-old integration nobody wants to touch? Business context, not raw count, is what turns a findings list into a decision about what to fix first.
Week 4: report, then decide the next boundary
Close the pilot with a short report: what was found, what matters most and why, and what the next 30-day boundary should be. The report is not the end product – the decision about where to point discovery next is. A pilot that ends with “here’s what we found” and no follow-on scope has proven the method works and then stopped using it. A pilot that ends with “here’s what we found, and here’s boundary two” has started a programme.
What the NCSC expects from a discovery engagement
The NCSC’s timelines for migration to post-quantum cryptography put, in its words, “a strong initial focus on carrying out a full discovery exercise” and then building an initial migration plan. To help organisations find skilled support for that work, it runs a post-quantum cryptography pilot within its Assured Cyber Security Consultancy scheme. The pilot has two offerings. Every company in it is assured for Discovery & Migration Planning, supporting cryptographic discovery exercises, identifying priority services for migration and helping develop an initial migration plan. Some are also assured for Advice on the use of post-quantum cryptography. The pilot is expected to run until 31 March 2027, and the NCSC has closed expressions of interest because of high levels of interest.
The pilot’s Standard (version 1.1, June 2026) describes the purpose of the discovery offering as identifying and prioritising “data and services protected by cryptography that will be at risk from a future cryptographically-relevant quantum computer”. It requires the outputs of an engagement to be clear and detailed enough for the customer to make technical and business decisions about migration, including:
- assessing risks to data based on its value and expected information lifetime;
- identifying the system or cryptographic components that should be early migration priorities, because they process higher-risk data, because migration is technically complex, or because they have slow refresh cycles;
- suggesting additional discovery activities, including identifying supply chain dependencies; and
- where proprietary tools are used, presenting conclusions and risks in a way that supports decision-making by executives.
Those requirements map closely onto the structure above. Week 3’s scoring is the risk assessment by data value and lifetime. Week 4’s report names the early priorities and the next discovery boundary, which is where supply chain dependencies belong. Whether you run a pilot yourself or buy one from an assured consultancy, the Standard is a useful checklist for what a good discovery output should contain.
What a pilot proves, and what it doesn’t
A well-run 30-day pilot can show three things: that discovery across several methods finds real, previously undocumented cryptography; that the findings can be scored by business impact rather than left as a raw list; and that the process can be repeated on the next boundary without reinventing it. It does not prove estate-wide coverage, and it shouldn’t be reported as if it does. The honest framing is “here is what one boundary looks like, discovered properly”, not “here is our cryptographic posture”. Confusing the two is how a useful pilot gets mistaken for a finished programme and quietly shelved.
The pilot’s real value is in what it removes as an excuse. Once one boundary has gone from unknown to inventoried and scored in a month, “discovery is too big to start” stops being a credible reason to wait.
Where Quantum Sentinel fits
Quantum Sentinel’s discovery is agentless and read-only across networks, certificates and PKI, key managers and HSMs, cloud platforms, databases and source code repositories, with Kubernetes the one deliberate exception, using a read-only sidecar. Findings land in an Enterprise CBOM with a quantum risk score, migration priority and recommended replacement for each entry, and exposure is scored with business context through the Cryptographic Exposure Score. Evidence exports as CycloneDX 1.7 and as a report set in PDF, Word, Excel and CSV. See automated cryptographic discovery and exposure assessment for detail.
Frequently asked questions
What is a cryptographic discovery pilot?
It is a short, bounded exercise that inventories the cryptography behind one business service, environment or regulated function, scores the findings by business impact and decides where discovery should go next. It proves the discovery method on something real before committing to the whole estate.
How should a 30-day discovery pilot be structured?
One workable structure is a week per stage: scope one boundary and define what done looks like; run discovery across it using at least two methods; score the findings against what they protect; then report what was found, what matters most and what the next boundary should be.
What is the NCSC post-quantum cryptography pilot?
It is a pilot within the NCSC’s Assured Cyber Security Consultancy scheme that assures consultancies for post-quantum work. All companies in it are assured for Discovery & Migration Planning, and some also for Advice. It is expected to run until 31 March 2027, and the NCSC has closed expressions of interest because of high levels of interest.
What should a discovery engagement deliver, according to the NCSC?
The pilot’s Standard requires outputs clear enough for technical and business decisions, including assessing risks to data by its value and expected information lifetime, identifying early migration priorities, suggesting additional discovery activities including supply chain dependencies, and presenting conclusions in a way that supports executive decision-making.
Does PCI DSS require a cryptographic inventory?
Yes, for the cryptography used to meet PCI DSS requirements. Requirement 12.3.3 requires an up-to-date inventory of all cryptographic cipher suites and protocols in use, including purpose and where used, reviewed at least once every 12 months. It became mandatory after 31 March 2025.
Sources: NCSC, Post-quantum cryptography (PQC) pilot; NCSC, ACSC Standard for the Post-Quantum Cryptography (PQC) Pilot Offering, version 1.1, June 2026; NCSC, Timelines for migration to post-quantum cryptography; PCI Security Standards Council, PCI DSS v4.0 Self-Assessment Questionnaire D for Merchants (Requirement 12.3.3) and Summary of Changes from PCI DSS 3.2.1 to 4.0.
Further reading: the NCSC’s post-quantum migration timeline, what a cryptography bill of materials is and automated cryptographic discovery.