Aisle of server racks in a data centre, representing the enterprise estate a cryptographic exposure management platform must discover

How to Choose an Enterprise Cryptographic Exposure Management Platform (ECEM)

On 27 October 2026 NIST published the final version of IR 8547, Transition to Post-Quantum Cryptography Standards. It goes further than the 2024 draft: NIST will now deprecate all quantum-vulnerable digital signature and key-establishment algorithms (RSA, ECDSA, EdDSA, Diffie-Hellman and their relatives) after 2030 and disallow them after 2035. Every organisation that has to plan against those dates first needs to know where that cryptography lives, and that is why so many security teams are now shortlisting a cryptographic exposure management platform.

The category is young and crowded. Certificate managers, network scanners, code analysers and new specialist tools all describe themselves in similar language, and the demos look alike. This guide sets out what to look for, the questions that separate a serious platform from a dashboard, and the red flags we see most often when helping clients through PQC readiness work.

What a Cryptographic Exposure Management Platform Is For

Quantum Sentinel’s whitepaper Understanding Enterprise Cryptographic Exposure Management defines ECEM as “the discipline of discovering, understanding, and reducing cryptographic exposure”, where exposure is the business risk created by unknown, weak, outdated or quantum-vulnerable cryptography. It frames the work as a continuous lifecycle: discover, inventory, assess, prioritise, transition and monitor.

That definition is a useful yardstick, because it shows what the platform is not. A certificate lifecycle tool manages certificates it already knows about. A TLS scanner reports what an endpoint negotiates today. A spreadsheet inventory is out of date the week after it is finished. An exposure management platform has to join these views together, keep them current, and turn them into a ranked list of work that a CISO can defend to a board or a regulator.

Regulators are asking for exactly that. The UK NCSC’s migration timelines (20 March 2025) expect organisations to carry out a full discovery exercise and build an initial migration plan by 2028. In the US, OMB Memorandum M-26-15 (24 June 2026) describes the foundation of an agency migration plan as “a dynamic, continuously updated inventory of all cryptographic assets”, created through automated tools wherever possible and feeding a central Cryptographic Bill of Materials (CBOM).

Eight Criteria to Evaluate

1. Discovery coverage that matches your estate

CISA’s Strategy for Migrating to Automated Post-Quantum Cryptography Discovery and Inventory Tools (15 August 2024) groups discovery into four types: network, file system, database system and software package. Add the systems that hold your keys and certificates (PKI, HSMs and key management systems) plus source code repositories and cloud services, and you have the realistic scope. Ask each vendor to map its connectors against that list, in writing. No single method gives the full picture: a network scan sees protocols in use but not the algorithm hard-coded into a batch job, and a code scan sees the reverse.

2. Read-only, metadata-only collection

A discovery tool touches the most sensitive parts of your infrastructure, so its own data-handling model is part of your risk assessment. Look for read-only credentials, agentless collection where possible, and an explicit statement of what is and is not collected. As one example of the bar to expect, Quantum Sentinel’s security and trust model states that it collects cryptographic metadata only and never copies private keys, certificates, sensitive files or application data.

3. A CBOM that stays current and can leave the tool

The inventory is the asset you are really buying. It should update on rescans rather than duplicating entries, record when each item was first and last seen, and export in an open format. CycloneDX 1.7 (released 21 October 2025) is the current version of the main open standard for CBOMs. If the inventory can only be read inside the vendor’s console, you are renting your own data. Our article on building a CBOM covers what a good inventory should contain.

4. Exposure and readiness scoring with business context

Raw finding counts tell you very little. Ask how the platform weighs an algorithm’s weakness against what it protects, how long that data must stay confidential (the harvest-now, decrypt-later question), and how exposed the system is. Scores should be explainable: you need to be able to show an auditor why one system ranks above another.

5. Prioritisation that produces work, not just charts

A ranked list is only useful if it reaches the teams who fix things. Check whether findings carry a recommended replacement algorithm, whether they can be pushed into your ticketing system, and whether the platform tracks progress against deadlines such as the NIST 2030 and 2035 dates.

6. Migration planning support, with honest limits

No tool writes your migration plan for you; dependencies, budgets and change windows are business decisions. What a platform can do is supply the evidence the plan rests on. Ask what planning outputs exist today and what is still on the roadmap.

7. Deployment that fits your sovereignty requirements

Banks, healthcare providers, operators of critical infrastructure and government suppliers often cannot send an inventory of their cryptographic weaknesses to a vendor’s cloud. Confirm whether the platform can run on-premises or in your private infrastructure, whether it supports segmented and air-gapped networks, and where every byte of collected data is stored.

8. Evidence a regulator will accept

OMB M-26-15 requires agency plans to describe “the methodologies and automated tools used for the cryptographic inventory”. Expect auditors outside government to ask similar questions. The platform should produce dated, repeatable reports and an audit trail showing what was scanned, when and with what coverage, not just a snapshot export.

Questions to Ask Every Vendor

  1. Which of CISA’s four discovery types (network, file system, database, software package) do you cover, and which do you not cover today?
  2. Which PKI, HSM, key management, cloud and code repository platforms do you connect to, and what access does each connector need?
  3. Exactly what data leaves the scanned system? Do you ever read file contents, copy certificates or touch private keys?
  4. Where is collected data stored and processed? Can the whole platform run inside our network, including air-gapped segments?
  5. How do you deduplicate findings across sources and correlate them to an asset and an owner?
  6. Can we export the full CBOM in CycloneDX, and what fields are included?
  7. How is each score calculated, and can we adjust weighting for asset criticality and data lifetime?
  8. How do you detect change between scans, such as a configuration that has been weakened?
  9. Do you detect post-quantum and hybrid algorithms as well as legacy ones, so we can measure progress and not just problems?
  10. What reports do you produce for auditors and boards, and which standards are they mapped to?

Good vendors answer these quickly and in writing. Quantum Sentinel, for example, publishes a product overview with a section titled “Cryptographic coverage, stated plainly”; that kind of plain statement of scope is what you should expect from any shortlisted supplier.

Red Flags

  • “We find everything.” CISA itself notes that software packages with embedded cryptography, customised applications and certain operating systems may not be discoverable with automated tools. A vendor who claims complete coverage has not looked closely.
  • Network scanning presented as an inventory. It is one source among several, not the whole picture.
  • Copying keys or certificates to a central store. That creates a new, highly attractive target and a fresh compliance problem.
  • Scores with no visible method. If nobody can explain why a system scored 72, the number will not survive an audit.
  • A CBOM locked inside the product. No open export means lock-in and duplicated effort later.
  • Problems-only inventories. A tool that lists only weaknesses cannot show where strong or post-quantum cryptography is already deployed, so it cannot measure progress.
  • Vague answers on deployment and data residency. If the answer to “where does our data go?” needs a follow-up call, treat it as a no.
  • A one-off assessment sold as a platform. Your estate changes weekly; the inventory has to keep up.

A Practical Shortlisting Process

Narrow the field to two or three suppliers using the questions above, then test each one against a bounded part of your estate where you already know some of the answers: a business service with known legacy certificates, a repository you know uses older algorithms, a share that holds keystores. Compare what each tool finds, what it misses, how quickly findings become tickets, and what the export looks like. Score the results against the eight criteria rather than the demo.

Weight the criteria to your sector. A UK bank may treat on-premises deployment and regulator-ready evidence as mandatory; a software company may care most about repository coverage. Quantum Sentinel’s cryptographic exposure assessment page is a useful reference for what business-context scoring outputs can look like. If you want a quick view of where you stand before you start, our free PQC compliance check gives a first indication, and our PQC migration readiness guide for 2026 sets out the deadlines your platform will need to report against.

How Sinevis Can Help

Choosing a platform is easier when the requirements are written down first. Sinevis delivers post-quantum cyber readiness assessments that define scope, success criteria and the evidence your regulators will expect, and then help you run a fair, side-by-side evaluation.

For automated discovery and inventory we work with Quantum Sentinel, a Sinevis technology partner whose Enterprise Cryptographic Exposure Management platform covers discovery, a continuously updated CBOM, exposure and readiness scoring, with on-premises deployment and read-only metadata collection. We also bring the consulting work no tool can do: business-service mapping, data-lifetime analysis and a migration roadmap you can take to the board.

Talk to Sinevis about scoping your evaluation.

Sources

  • NIST, IR 8547 Transition to Post-Quantum Cryptography Standards (final), 27 October 2026: csrc.nist.gov/pubs/ir/8547/final
  • Office of Management and Budget, Memorandum M-26-15 Execution of the Migration to Post-Quantum Cryptography, 24 June 2026: whitehouse.gov (PDF)
  • UK National Cyber Security Centre, Timelines for migration to post-quantum cryptography, 20 March 2025: ncsc.gov.uk
  • CISA, Strategy for Migrating to Automated Post-Quantum Cryptography Discovery and Inventory Tools, 15 August 2024: cisa.gov
  • OWASP CycloneDX, CycloneDX v1.7 released, 21 October 2025: cyclonedx.org
  • Quantum Sentinel, Understanding Enterprise Cryptographic Exposure Management (ECEM), whitepaper, accessed 28 October 2026: quantumsentinel.uk