Annual Cryptographic Discovery Report

Scope, date, and evidence method

Review date and posture. This article is presented as a dated primary-source desk review. It synthesizes the cited passages from NIST, CISA, NSA, the UK National Cyber Security Centre, NIST’s Cybersecurity Framework, OWASP CycloneDX, and NIST’s AI Risk Management Framework where relevant to governance context. The sources are identified in the source set as primary, authority-tier-one material. The review does not report interviews, a sample of enterprises, original survey responses, or independently collected telemetry. Consequently, statements below describe what the cited documents say and what can reasonably be inferred from them, rather than the prevalence of any practice in the market.123

How the evidence was read. The synthesis separates direct observations from implications. A direct observation is a statement explicitly made in a cited passage—for example, that NIST released three principal PQC standards in August 2024, or that discovery tools may fail to identify embedded cryptography. An implication is a practical interpretation of those observations—for example, that an annual discovery process should preserve uncertainty and assign follow-up work to suppliers. Implications are deliberately framed as recommendations or inferences, not as measured outcomes.1234

Why cryptographic discovery is the central finding

The strongest cross-source finding is that an organization cannot sensibly prioritize post-quantum migration without first understanding its cryptographic estate. The joint CISA, NSA, and NIST material says an inventory of quantum-vulnerable technology and the criticality of associated data enables risk assessment and migration prioritization. It also describes the inventory as a way to identify outside access to datasets and to inform analysis of data that could be targeted now and decrypted when a cryptographically relevant quantum computer becomes available.4

The UK NCSC guidance gives discovery a similarly practical starting point: identify key services and applications; record the data held, including expected lifetime and value to an adversary; identify how data is protected in transit and at rest; and map the systems through which the data is processed. This is broader than making a list of algorithms. It is an estate-mapping exercise connecting services, data, protocols, certificates, software, hardware, firmware, and operational dependencies.2

The evidence also indicates why discovery is difficult. Older systems may have cryptographic services that evolved over many years in a haphazard way, making components difficult to find and mitigation strategies difficult to identify and execute. The joint fact sheet recommends examining network protocols, end-user systems and servers, applications and libraries, firmware and software updates, and cryptographic code or dependencies in the CI/CD pipeline.4

A further limitation is particularly important for an annual report: automated discovery is not complete by definition. The joint fact sheet cautions that tools may not identify embedded cryptography used internally within products. It recommends asking vendors for lists of embedded cryptography and recording where vulnerable cryptography protects sensitive or critical datasets, together with estimates of the required protection period. An annual report should therefore distinguish discovered facts, vendor assertions, inferred dependencies, and unresolved blind spots.4

Standards, threat context, and what is observable

NIST describes post-quantum cryptography as protection against a future threat from quantum computers that may be years or decades away but could eventually break many widely used cryptographic systems. The cited overview explains the concern through public-key cryptography: a sufficiently capable quantum computer could change the difficulty of problems such as factoring large numbers. The same material emphasizes uncertainty about how formidable quantum computers will become, while treating preparation as necessary because the impact on present-day encryption could be substantial.5

The cited NIST project material records a concrete standards milestone. In August 2024, NIST released its principal PQC standards as Federal Information Processing Standards: FIPS 203 for ML-KEM, a module-lattice-based key-encapsulation mechanism; FIPS 204 for ML-DSA, a module-lattice-based digital-signature standard; and FIPS 205 for SLH-DSA, a stateless-hash-based digital-signature standard. NIST also states that additional standards are being developed as backups or alternatives.1

The project material further states that NIST expects ML-KEM, ML-DSA, and SLH-DSA to provide the foundation for most deployments and says they can and should be put into use now. It also records continuing evaluation of innovative algorithms, including ongoing standardization work involving the Falcon digital-signature algorithm and the HQC key-encapsulation mechanism. This means a discovery report should record both current standards dependencies and the organization’s ability to accommodate future algorithm or protocol changes; it should not imply that standard publication eliminates implementation, interoperability, performance, or lifecycle work.1

Migration is a systems transition, not an algorithm swap

The NCSC characterizes migration to PQC as a mass technology change that will take a number of years. Its guidance says organizations may need to operate traditional and PQC mechanisms simultaneously for a period, using protocols such as TLS and IKE that allow negotiation of certificates when both communicating parties have been upgraded. It also describes an alternative involving a new PQC root of trust that cross-signs the old one, while warning that the security implications must be assessed case by case.2

The same guidance makes an important authentication distinction: a system generally will not provide quantum-secure authentication until PKI migration is complete and traditional certificates have expired or been revoked. Planning and sequencing should therefore be informed by the readiness of robust, standards-compliant implementations of algorithms and protocols. The NCSC states that fully PQC-ready protocols and global cryptographic infrastructure will take a number of years and that trusted implementations of everything required will also take time.2

Crypto agility supplies the architectural lens for this transition. NIST CSWP 39 Update 1 defines cryptographic agility as the capabilities needed to replace and adapt cryptographic algorithms in protocols, applications, software, hardware, firmware, and infrastructures while preserving security and ongoing operations. In practical terms, an annual discovery report should track whether cryptographic choices are centralized or scattered, whether dependencies can be changed without redesigning an entire service, and whether replacement can be tested and controlled. Those are implications of the definition, not measurements cited by the evidence.3

The NIST CSF 2.0 provides a governance structure that can help situate this work. It describes organizational profiles as a way to document scope, gather policies and risk priorities, create a current profile, analyze gaps against a target profile, and create a prioritized action plan. It also says the CSF functions should be addressed concurrently and that identify, protect, detect, respond, and recover have related roles. Applied cautiously, this suggests that cryptographic discovery should be maintained as a continuing risk-management activity rather than treated as a one-time spreadsheet exercise.6

Operational technology, constrained devices, and supply chain evidence

The cited NCSC material highlights a special OT concern: in industrial control environments, confidentiality may not always require strong cryptographic protection, but data integrity can be critical because faulty sensor readings or commands can lead to failures. Remote logins over the internet must be securely authenticated, and wireless field devices and sensors also require attention. This widens discovery beyond encryption-at-rest inventories to include authentication channels, commands, firmware, sensor data, and trust relationships between IT and OT zones.2

Industrial IoT devices introduce additional migration constraints. The evidence lists devices that may be resource-constrained, not upgradeable, difficult to service, embedded in larger products, not designed for replacement, or dependent on proprietary or not-yet-PQC-compatible protocols. Internet-connected devices may also provide an entry point into control networks and onward into enterprise IT zones through a demilitarized-zone firewall. An annual report should record these conditions explicitly rather than assigning a generic “migrate” status.2

Supply-chain evidence is therefore part of cryptographic discovery. The joint CISA, NSA, and NIST fact sheet recommends engagement with supply-chain vendors to identify technologies that need migration. OWASP CycloneDX is identified in the cited material as an ECMA-424 full-stack bill-of-materials standard supporting, among other forms, a cryptography bill of materials. The evidence supports treating a CBOM or equivalent supplier disclosure as a potentially useful evidence artifact; it does not establish that every vendor supplies one or that such an artifact alone proves cryptographic completeness.47

A practical annual reporting sequence

The following sequence is an evidence-informed operating model, not a reported industry standard. First, define scope and ownership: include IT, OT, cybersecurity, privacy and risk managers, procurement, application owners, infrastructure teams, and relevant suppliers. Second, assemble or refresh the inventory across services, applications, data, protocols, certificates, software, hardware, firmware, CI/CD dependencies, and embedded components. Third, classify data by sensitivity, expected protection lifetime, value to an adversary, and exposure paths. Fourth, map dependencies and identify where public-key cryptography supports confidentiality, authentication, signatures, updates, or trust establishment.42

Fifth, assess migration conditions: current algorithm and protocol, affected asset, owner, supplier, implementation status, upgrade path, interoperability requirement, operational constraints, and evidence confidence. Sixth, prioritize work using business impact and exposure rather than asset count alone. Seventh, test crypto-agile replacement and staged coexistence where appropriate, while assessing certificate, PKI, protocol, and root-of-trust consequences case by case. Eighth, retain unresolved questions as explicit risks with owners and review dates. This sequence is an inference from the cited discovery, migration, agility, and framework passages; the evidence does not prescribe this exact report template.236

A useful annual comparison should preserve change history. Report newly discovered dependencies, retired dependencies, changed algorithms, newly obtained vendor evidence, assets still lacking embedded-cryptography documentation, changes in data-protection lifetime, completed tests, blocked upgrades, and decisions to accept, transfer, mitigate, or monitor risk. The report should distinguish “not found,” “not applicable,” “not assessed,” and “assessment incomplete.” That distinction is especially important because the cited evidence warns that discovery tools can miss internal product cryptography.4

Evidence gaps, conflicts, and interpretation limits

The evidence is directionally consistent on the need to prepare, inventory, prioritize, engage suppliers, and plan for a multi-year transition. It is not a single synchronized program. NIST’s standards material records a 2024 standards milestone and ongoing standardization; the NCSC guidance describes indicative migration activity and implementation readiness; the joint fact sheet is dated August 17, 2023; and the crypto-agility source is NIST CSWP 39 Update 1, published December 19, 2025 with updates as of June 29, 2026. These dates should remain attached to findings because guidance and implementation conditions can change.1234

The cited source set also contains adjacent governance material, including NIST CSF 2.0, NIST AI RMF 1.0, and CycloneDX. They are useful for framing profiles, gap analysis, supply-chain transparency, and risk management, but they do not constitute direct evidence of PQC adoption. The AI RMF passages in particular concern trustworthy AI and should not be used to infer cryptographic migration results. Likewise, a bill-of-materials standard demonstrates a format and capability in the evidence; it does not demonstrate that an organization’s inventory is complete.678

Finally, the threat itself remains prospective in the cited material. NIST describes advanced quantum computers as a strong possibility and says the field remains in its infancy, with major technical hurdles still to overcome. That uncertainty is not a reason to defer discovery: the joint guidance identifies long-secrecy-lifetime data as a reason to prepare early. It is, however, a reason to avoid unsupported forecasts about when a cryptographically relevant quantum computer will exist or when any particular organization will finish migration.534

Conclusion

The cited primary sources support a clear but bounded conclusion: an annual cryptographic discovery report should be an evidence register and decision instrument, not a market-adoption scorecard. Its central purpose is to connect cryptographic use to services, data lifetime, exposure, ownership, suppliers, operational constraints, and migration options. NIST’s 2024 principal standards provide a concrete standards reference, while NCSC, CISA, NSA, and NIST guidance make clear that discovery, risk prioritization, vendor engagement, PKI planning, and crypto agility are multi-year concerns. The evidence supports beginning and continuously refining this work; it does not support claims of universal readiness, fixed completion dates, or complete visibility from automated tools alone.4123