Enterprise Cryptographic Maturity Report

Scope, date, and evidence method

Review date and status. This article is a dated primary-source desk review based only on the cited source set. The cited source set includes current or final publications from NIST, CISA, NSA, the UK National Cyber Security Centre, NIST’s Cybersecurity Framework program, NIST’s AI Risk Management Framework program, and OWASP. The source record includes publication dates from 2023 through 2025 and updates through June 29, 2026. Where a source has a stated document version or status, this review preserves it rather than treating all materials as interchangeable.12

Method. The review extracted recurring propositions about enterprise cryptographic maturity: why quantum-resistant migration matters; how organizations should discover and prioritize cryptographic dependencies; how governance and enterprise risk management can structure decisions; why crypto agility matters; and which IT, OT, supply-chain, and data-lifecycle constraints complicate execution. Observations are attributed to the cited passages. Practical implications are labeled as inference where they go beyond a source’s direct wording. No cited passage reports a representative enterprise sample, adoption percentage, maturity distribution, aggregate investment, or comparative vendor performance. Accordingly, this article quantifies only the standards, dates, and algorithm counts explicitly present in the evidence.321

Why enterprise cryptographic maturity matters

The cited NIST overview describes quantum computing as a future possibility that could materially affect present-day encryption, while also stating that the field remains in its infancy and that major technical hurdles remain. The evidence therefore supports preparedness, not a claim that a cryptographically relevant quantum computer currently exists or that its arrival date is known. NIST explains that sufficiently capable quantum computers could challenge cryptographic constructions based on factoring large numbers; the source describes the potential change from extremely long classical computation to much faster quantum computation as a reason to prepare.4

CISA, NSA, and NIST frame preparation as a planning and migration problem. Their joint guidance says a successful migration will take time and urges organizations to create quantum-readiness roadmaps, conduct inventories and risk assessments, and engage vendors. It also identifies “harvest now, decrypt later” as a reason to consider data whose secrecy lifetime extends into the future. This does not mean every dataset has the same exposure. It means that data value, secrecy lifetime, integrity requirements, system criticality, and dependency complexity should influence sequencing.2

A mature program therefore treats cryptography as enterprise infrastructure rather than as an isolated algorithm choice. The NCSC evidence describes older cryptographic services as having evolved over many years in sometimes haphazard ways, making discovery and mitigation harder. It also presents migration as an opportunity to simplify the estate and reduce other cybersecurity risks. That is an inference about program value, not evidence that every migration will reduce risk or cost; the actual outcome depends on architecture, implementation quality, testing, and operational controls.5

Standards, readiness, and what the evidence actually establishes

NIST’s cited project material states that, in August 2024, it released three principal post-quantum cryptography standards as Federal Information Processing Standards. FIPS 203 specifies ML-KEM, a module-lattice-based key-encapsulation mechanism; FIPS 204 specifies ML-DSA, a module-lattice-based digital-signature standard; and FIPS 205 specifies SLH-DSA, a stateless hash-based digital-signature standard. The same material says NIST is developing additional standards as backups or alternatives and encourages organizations to begin applying the standards now.6

The NIST project evidence also says the standardization process remains active: Falcon and HQC were selected for ongoing standardization, while additional digital-signature schemes were solicited for longer-term purposes. This matters for maturity assessment because a standards-based program must distinguish final standards from algorithms still undergoing evaluation or standardization. The evidence does not establish that every implementation is interoperable, validated, performant for every device, or suitable for every use case.6

NIST’s overview describes an open evaluation process involving cryptographers and multiple rounds of candidate assessment. One cited passage records that NIST assessed 82 algorithms from 25 countries, identified 15 top candidates, and later describes 69 candidate algorithms submitted by experts. These figures describe stages or formulations of the standardization history in the cited source passages; they should not be combined into a single measure of enterprise readiness. They also do not measure deployment or adoption.4

A practical evidence-based maturity model

The following dimensions synthesize the evidence into a practical assessment lens. They are not an official maturity model issued by any one cited source. The inference is that an enterprise is more mature when it can demonstrate these capabilities consistently, with ownership and evidence, across relevant IT and OT environments.3

1. Visibility: The organization maintains inventories of hardware, software, services, systems, suppliers, network communications, data flows, and cryptographic use. It can identify public-key algorithms, certificates, protocols, libraries, firmware, and dependencies rather than relying on product labels alone.
2. Risk linkage: Inventory records connect cryptographic dependencies to data classification, secrecy lifetime, integrity requirements, business impact, asset criticality, exposure, and operational consequences. This permits migration sequencing instead of a purely technology-led replacement exercise.
3. Governance: Risk appetite, tolerance, objectives, responsibilities, communication lines, and a standardized method for calculating and prioritizing cybersecurity risk are established and connected to enterprise risk management.
4. Migration execution: The organization has a roadmap, project ownership, test and deployment sequencing, vendor commitments, exception handling, and measures for systems that cannot be upgraded or replaced quickly.
5. Crypto agility: Protocols, applications, software, hardware, firmware, and infrastructure can replace or adapt cryptographic algorithms while preserving security and ongoing operations.
6. Lifecycle and supply-chain control: Procurement, cloud-provider engagement, supplier inventories, product updates, post-contract activities, and cryptography-related bills of materials support visibility throughout the technology life cycle.
7. Operational resilience: IT, OT, industrial control systems, remote access, wireless sensors, field devices, and safety or integrity-sensitive functions are addressed without assuming that an enterprise IT change can be applied unchanged everywhere.

NIST CSF 2.0 provides a useful governance frame for these dimensions because its stated purpose is to help organizations understand, assess, prioritize, and communicate cybersecurity efforts regardless of size, sector, or maturity. The CSF does not prescribe a single way to achieve outcomes. Its profile process supports documenting scope and assumptions, gathering policies, risk priorities, resources, business-impact information, requirements, practices, tools, and roles, then analyzing gaps between current and target profiles and creating an action plan.3

Inventory is the operational starting point

The joint CISA, NSA, and NIST guidance identifies lack of visibility into public-key dependencies as a common organizational problem. It recommends a cryptographic inventory led by IT and OT procurement experts, with cybersecurity and privacy risk managers involved in prioritizing assets affected by a cryptographically relevant quantum computer. The inventory should include supplier engagement and identify technologies that need to migrate from quantum-vulnerable cryptography to post-quantum cryptography.2

The NCSC passage gives a complementary discovery scope: 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; map systems through which data is processed; and manage software and hardware assets effectively. Together, these passages support an inventory that records both the cryptographic mechanism and the business context around it. A list of algorithms without ownership, data lifetime, protocol location, dependency mapping, and replacement constraints would be materially incomplete.5

OWASP CycloneDX is described in the cited evidence as ECMA-424 and as a full-stack bill-of-materials standard. The evidence lists support for software, SaaS, hardware, machine-learning, cryptography, manufacturing, and operations bills of materials, as well as vulnerability disclosure reports, vulnerability exploitability exchange, and attestations. The narrow inference for this review is that a CBOM-oriented approach may help structure cryptographic component visibility; the evidence does not say that adopting CycloneDX alone creates a complete enterprise cryptographic inventory or proves quantum readiness.7

Migration sequencing, PKI, and crypto agility

The evidence anticipates staged migration rather than a universal “big bang” replacement. The NCSC says that, except for the simplest systems, traditional public-key cryptography and post-quantum cryptography will likely need to coexist for a period. It recommends seeking solutions that offer cryptographic agility and identifying criteria for ending support for traditional algorithms. The evidence also says an organization is fully secure against the quantum-computing threat only once it no longer has sole dependence on traditional public-key cryptography; this is a source-specific condition, not a claim that all residual cryptographic risk disappears at that point.5

For enterprise PKI, the NCSC describes simultaneous operation, staged migration, certificate negotiation in protocols such as TLS and IKE, and a possible new post-quantum root of trust that cross-signs an old one. It cautions that the security implications of the chosen approach must be assessed case by case. The passage further states that quantum-secure authentication is not provided until PKI migration is complete and traditional certificates have expired or been revoked. This makes certificate inventories, trust-anchor ownership, issuance processes, revocation, expiry, and communicating-party readiness central maturity concerns.5

NIST’s crypto-agility white paper defines cryptographic agility as the capabilities needed to replace and adapt algorithms in protocols, applications, software, hardware, firmware, and infrastructure while preserving security and ongoing operations. The cited record identifies the document as NIST CSWP 39 Update 1, final, published December 19, 2025, with updates as of June 29, 2026. The definition supports treating agility as an operational capability rather than merely selecting a second algorithm.1

IT, OT, and supplier realities

Industrial control systems and industrial Internet of Things devices require special treatment. The NCSC evidence says OT networks commonly involve IT and OT zones separated by a DMZ firewall, and that remote Internet logins make quantum-secure authentication important. It also says wireless field devices and sensors need protection, while the integrity of their data may be critical even where confidentiality does not require strong cryptographic protection. Faulty sensor readings or commands can lead to industrial-control-system failures.5

The same evidence identifies constraints that complicate migration: devices may be resource-constrained, non-upgradeable, difficult to service, embedded in larger products, not designed for replacement, or dependent on proprietary or not-yet-compatible protocols. Internet-connected devices may also provide an entry point into control networks. The implication is that maturity cannot be judged only by the state of centrally managed enterprise applications; it must account for physical maintenance cycles, safety and integrity requirements, remote access, embedded dependencies, and network segmentation.5

The joint quantum-readiness guidance says vendor engagement is critical and recommends that roadmaps include when and how commercial off-the-shelf vendors plan to deliver updates or upgrades, together with expected migration costs. For cloud-hosted products, it recommends engaging cloud service providers about their quantum-readiness roadmaps and later focusing on configuration changes or application updates once standards are available. These recommendations support procurement controls that capture supplier commitments, product versions, upgrade paths, testing responsibilities, and end-of-support consequences.25

How to measure progress without overstating the evidence

A defensible internal assessment should report evidence of capability rather than assign unsupported industry percentages. Useful measures may include inventory coverage by asset class; the proportion of critical services with identified cryptographic dependencies; the number of certificates, trust anchors, protocols, applications, firmware components, and suppliers with named owners; the proportion of long-lived or high-value data linked to migration decisions; and the number of priority systems with tested transition paths. These are proposed management measures, not metrics reported by the cited sources.3

The principal limitations are substantial. The cited source set does not provide enterprise implementation data, a sampling frame, adoption rates, incident data, cost benchmarks, or a common scoring rubric. Several sources are guidance documents with different purposes: NIST CSF 2.0 addresses cybersecurity risk management broadly; the AI RMF is a voluntary framework for AI trustworthiness; CycloneDX addresses bill-of-materials transparency; and the PQC and NCSC materials address quantum-resistant migration. Their concepts can be aligned for analysis, but they should not be treated as one integrated standard. The evidence also does not establish that a particular vendor, product, protocol, or organization is compliant, quantum-safe, or crypto-agile.3

Practical implications for enterprise leaders

First, sponsor a cross-functional program rather than assigning the problem solely to cryptographers. The cited guidance points to IT, OT, procurement, cybersecurity, privacy risk management, enterprise risk management, suppliers, and cloud providers. Second, define scope and assumptions before collecting data, following the profile logic described in CSF 2.0. Third, make inventory records decision-ready by connecting each dependency to data lifetime, confidentiality and integrity needs, asset criticality, exposure, owner, supplier, upgrade path, and operational constraints.235

Fourth, separate standards adoption from deployment completion. NIST’s 2024 FIPS releases provide an important standards basis, but the evidence says implementation specifics, additional candidates, performance, and protocol readiness remain relevant considerations. Fifth, design transition tests around real communicating parties, certificate lifecycles, firmware and software update paths, remote access, and rollback. Sixth, use procurement and supplier governance to obtain roadmaps and identify dependencies that the enterprise cannot change directly.65

Finally, report uncertainty explicitly. A credible board-level status should distinguish discovered assets from undiscovered assets, tested transitions from planned transitions, standards-compatible claims from validated implementations, and supplier statements from independently evidenced capabilities. That discipline is itself a maturity signal because it prevents a roadmap from being mistaken for completed risk reduction.3

Conclusion

The cited primary sources support a clear but bounded conclusion: enterprise cryptographic maturity is primarily the capability to see, prioritize, govern, and safely change cryptography across the full technology and supplier estate. Post-quantum standards now provide a concrete reference point, but readiness is not demonstrated by naming an algorithm or publishing a roadmap. It requires inventories tied to data and business risk, crypto-agile architecture, staged PKI planning, IT/OT-specific analysis, supplier visibility, testing, and accountable governance. Because the source set contains guidance rather than enterprise survey data, this review should be used as an assessment framework and evidence checklist—not as a market-wide maturity score.6351