Cryptography Maturity Action Plan (CMAP)

Level 1 – Ad Hoc

Cryptographic training is informal or absent. Development and operations teams may not understand the organization’s cryptography policies or the looming quantum threat. Any expertise in cryptography resides in a few individuals, and there is no program to share knowledge.

Level 2 – Developing

Basic training initiatives begin. The security team provides introductory sessions to developers and IT staff on secure use of encryption libraries and the basics of post-quantum concepts. Management circulates internal memos or briefs about the importance of preparing for PQC (often referencing external mandates like NIST’s PQC project). Training is still ad hoc (e.g., part of a broader security awareness program) but quantum risk is now mentioned. Some staff (especially in security roles) attend external webinars or conferences on PQC to build knowledge.

Level 3 – Defined

A formal cryptography training program is implemented. The organization conducts regular workshops or courses for relevant teams (engineering, architecture, risk) on cryptographic implementations, crypto-agility principles, and specific PQC algorithms. Training content is kept up-to-date with the latest NIST standards and includes hands-on labs (for example, using new PQC libraries in development). Specific role-based training is deployed (e.g., PKI administrators trained on new certificate formats, developers trained on using crypto-abstraction APIs for agility). The effectiveness of training is measured (quizzes, certification of completion) and tied into personnel development plans.

Level 4 – Optimized

Continuous education and community involvement. The organization not only trains its staff but also contributes to the wider community’s knowledge base (e.g., publishing learnings or open-source tools related to cryptographic migration, contributing to industry-specific working groups, or speaking at conferences). Internal cryptography experts mentor others and a culture of cryptographic awareness is ingrained (developers instinctively consider cryptographic impacts in design discussions). Training is continuously refined based on feedback and emerging threats – for instance, incorporating lessons learned from pilot PQC deployments or new attack techniques. The organization may host or sponsor cryptography competitions, hackathons, or advanced training for talent development. Additionally, the organization includes cryptographic learnings/knowledge into other functions, such as security assessments and architectural patterns.

Level 1 – Ad Hoc

The organization lacks a centralized cryptographic inventory. Knowledge of where encryption, digital signatures, certificates, and cryptographic libraries are used is patchy, often confined to individual system owners. There is no formal process to catalog cryptographic assets (e.g., algorithms, key lengths, libraries, certificates) across the IT environment. Quantum-vulnerable algorithms (RSA, ECC, SHA-1, etc.) may be present but not tracked.

Level 2 – Developing

An initial cryptography inventory effort is underway. The organization has started to identify and document cryptographic components in critical systems (e.g., an inventory of TLS, VPN, SSH key exchange algorithms or digitally signed documents algorithms exposed to public internet.). This may be a manual spreadsheet or part of broader asset management. Some automated discovery tools might be piloted on a limited scope (e.g., scanning code for usage of crypto APIs). The inventory is not complete yet, but there is awareness that having a full crypto portfolio is important.

Level 3 – Defined

A comprehensive cryptographic inventory is established and maintained as a living artifact. The inventory covers hardware, software, and services: it documents all places where cryptography is used (protocols, applications, databases, IoT devices, etc.), including details like algorithm types and key lengths in use. The inventory is kept up-to-date via automated discovery tools and periodic audits avoiding information from becoming stale and outdated. The inventory is formally recognized as a critical asset for risk management, feeding into decision-making for upgrades and PQC transition. For example, the team can quickly query which systems use RSA-2048 or which use elliptic curves, etc.

(Source)

Level 4 – Optimized

Crypto inventory management is fully integrated into enterprise asset management and change management processes. Any new system or software introduced must be cataloged for cryptographic use. Inventory data is leveraged in real-time: e.g., dashboards show the organization’s current cryptographic posture (what percentage of systems use quantum-safe algorithms, etc.). The inventory is enriched with metadata like data sensitivity and system criticality. This allows mapping of crypto assets to business impact (for instance, identifying which encrypted data would be most sensitive in a quantum-compromised future). The inventory also extends to dependencies on third-party components, cloud services, or open-source libraries, noting their cryptographic use.

Level 1 – Ad Hoc

No specific  quantum risk assessment-focused threat model is performed. The organization’s risk management processes do not account for the quantum computing threat. Cryptographic risks might be mentioned in generic terms (e.g., “encryption failure” in a risk register), but there is no analysis of how soon quantum advances could compromise specific systems, or which data is at most risk from long-term confidentiality exposure (like sensitive data with long shelf life).

Level 2 – Developing

Preliminary quantum risk assessments are conducted. The security or risk team has started to include the quantum threat in its horizon scanning. For example, they have identified which systems hold data that must remain confidential for many years (and thus are susceptible to “harvest-now, decrypt-later” attacks ). The organization might adopt a simple risk model or qualitative scoring to rate quantum vulnerability of various systems (e.g., factoring in algorithm strength, data sensitivity, system lifespan). However, this process is informal or infrequent and not yet integrated into enterprise risk management.

Level 3 – Defined

A formal quantum risk assessment framework is in place, integrated with overall risk management. The organization uses established frameworks or models (such as Michele Mosca’s Quantum Risk Assessment or the Crypto Agility Risk Management Framework (CARAF)) to measure quantum risk . Each cryptographic asset (from the inventory) is evaluated for quantum impact: likelihood timelines (using the latest expert projections for when certain algorithms might be broken) and impact severity are analyzed. Systems are categorized, e.g., Tier 1: must be quantum-safe ASAP (high sensitivity data, long-term need), Tier 2: moderate risk, etc. The output is a risk-based prioritization for PQC migration – a list of what to tackle first. This quantum risk perspective is updated regularly (e.g., annually or when significant advancements occur).

Level 4 – Optimized

Quantum risk is baked into standard, already-established assessments and workflows—not treated as a separate or one-off activity. Teams routinely evaluate quantum impact within existing processes such as threat modeling/architecture risk analysis, design reviews, change management, portfolio planning, vendor risk assessments, and control attestations. Continuous, tool-assisted analytics (e.g., crypto-health dashboards) quantify exposure and track reduction over time. The program ingests the latest research and government guidance on quantum timelines and automatically normalizes it into the enterprise risk model so assessments stay current without special projects. Results directly drive budgets and roadmaps (project charters reference quantum risk scores), and the organization periodically conducts cryptographic tabletop exercises (e.g., sudden algorithm break or accelerated CRQC arrival) to validate response playbooks. Outcome metrics—such as remaining high-risk crypto assets, remediation velocity, and control coverage—are first-class enterprise risk indicators reported alongside other cyber KPIs.

(Source)

Level 1 – Ad Hoc

Little consideration is given to vendors or partners in terms of PQC. Contracts and security questionnaires do not address cryptography updates or quantum resistance. The organization is essentially blind to whether critical third-party products (e.g., VPN appliances, cloud platforms, IoT devices, CAs issuing certificates) are using strong cryptography or have plans for PQC. This poses a hidden risk – if a vendor’s product is not agile, the organization may be stuck with quantum-vulnerable tech.

Level 2 – Developing

The organization begins inquiring about vendor PQC posture. For key suppliers, they may ask questions about PQC roadmaps or include PQC-related criteria in RFPs and vendor assessments (often based on guidance like the DHS PQC roadmap or industry questionnaires). Some contracts for new procurements start to include language about cryptographic agility or requirements to support NIST-approved PQC algorithms once available. However, this is not yet consistent across all vendors or built into procurement processes enterprise-wide.

(Source)

Level 3 – Defined

Supply chain cryptography criteria are integrated into vendor management and procurement. Standard contract clauses or SLAs require vendors to disclose their cryptographic mechanisms (i.e. Cryptographic Bill of Materials) and commit to providing PQC-compatible solutions within defined timelines. As part of the cryptographic asset inventory, the organization maintains a register of critical suppliers and their PQC readiness status (e.g., which vendors’ products support larger key sizes, which have announced support for NIST PQC algorithms). Regular vendor risk assessments include cryptography-specific checks. Third-party PQC readiness questionnaires or audits are conducted for high-risk partners.

Level 4 – Optimized

The enterprise is a leader in driving crypto-agility across its ecosystem. It works closely with vendors, sometimes in joint pilot projects, to test PQC integrations (e.g., testing a vendor’s beta PQC-enabled firmware in the enterprise environment). Supplier risk management is dynamic – if a critical vendor lags in quantum readiness, the organization has contingency plans (such as alternate suppliers or compensating controls). The organization might even influence standards by participating in supply chain security initiatives or working groups to develop best practices for vendor PQC migration. All new technology acquisitions undergo a strict cryptography review to ensure compatibility with current and anticipated standards. In essence, third-party crypto risk is managed with the same rigor as internal risk.

Level 1 – Ad Hoc

Systems are largely crypto-rigid: cryptographic algorithms might be hard-coded, and there is no consideration for future change. Applications directly call crypto libraries without abstraction, making it hard to update algorithms. The concept of crypto-agility is not understood by development teams – designs do not account for potential algorithm changes or dual algorithms.

Level 2 – Developing

Awareness of crypto-agile design principles grows. New systems start adopting modular cryptography approaches – for example, using configuration files or centralized services to specify which algorithms to use, rather than hard-coding them. The enterprise has begun inventorying where crypto libraries are used and ensures new projects use approved libraries that support multiple algorithms. Some pilot efforts test dual-stack solutions (e.g., implementing both a classical and a PQC algorithm in a protocol in anticipation of future switch). However, older systems remain inflexible. Documentation of cryptographic components in software architecture diagrams becomes more common, hinting at integration of crypto-agility considerations in design reviews.

Level 3 – Defined

The organization has established crypto-agility standards for architecture and coding. There are documented guidelines (for architects and developers) on how to achieve crypto-agility: e.g., “use interface X from our crypto library to call encryption functions, so that algorithms can be changed under the hood”. Security protocols and applications are designed to be algorithm-neutral, supporting multiple cipher suites or algorithm identifiers as needed. Crypto-abstraction layers or APIs are widely used – for instance, developers use a company-approved crypto API that can dynamically select between RSA or a PQC algorithm. The enterprise may have refactored some critical systems to remove hard-coded crypto and instead rely on central cryptographic services or libraries. Design reviews and threat modeling now include a check for crypto-agility (ensuring no new system is built with an immutable dependency on a single algorithm).

Level 4 – Optimized

Seamless cryptographic adaptability is achieved. Systems and infrastructure can undergo cryptographic transitions without code change, and this capability is regularly tested. For example, the organization can perform a live switch from one algorithm to another (perhaps using feature flags or toggling library settings) in a controlled manner. Protocols in use support algorithm agility to the extent that even urgent deprecations (like a sudden break of an algorithm) could be handled quickly by switching to alternatives. The architecture supports hybrid cryptographic modes (combining classical and PQC algorithms) where necessary to ensure security during transition. The organization keeps track of cryptographic versioning and compatibility – e.g., it can detect which endpoints have upgraded to new algorithms and which haven’t. This ensures interoperability during migrations. Cryptography is treated as a configurable aspect of systems, and engineers routinely practice “exchanging” cryptographic components in test environments to verify agility.

Level 1 – Ad Hoc

No concrete migration plan exists. The organization has not yet thought through how it would actually replace or upgrade cryptographic algorithms in practice. There may be an assumption that when PQC is needed, normal project management processes will handle it, but nothing specific is prepared.

Level 2 – Developing

Initial planning begins for the PQC migration. A high-level roadmap or strategy document is drafted, identifying broad phases of the effort (e.g., inventory → pilots → full deployment). The organization identifies some candidate areas for pilot projects – for instance, a non-critical internal application where a PQC algorithm could be trialed with minimal impact if issues arise. Timelines are still rough, but there is an understanding that migration will be a multi-year effort. The plan might include milestones aligned with external events (e.g., “When NIST announces draft standards, we will begin phase X”). However, detailed resourcing and playbooks are not fleshed out yet.

Level 3 – Defined

A comprehensive migration plan (“quantum-ready roadmap”) is formalized. This includes: detailed project plans with owners, timelines, and resources for executing migration across different systems; identification of dependencies and sequencing (for example, update supporting libraries and infrastructure before application changes); and defined entry/exit criteria for each phase. The plan follows a phased deployment approach – possibly starting with hybrid solutions and gradually moving to full PQC. Pilot programs are executed at this stage: observable evidence includes one or more pilot implementations of PQC in controlled environments. For example, a small-scale pilot where an internal service uses PQC algorithms for its communications has been run, and compatibility or performance data gathered . The plan is regularly updated based on pilot feedback. Additionally, communication plans are defined (how to communicate changes to stakeholders, customers, auditors, etc., during the migration).

Level 4 – Optimized

The organization demonstrates smooth, ongoing execution of the transition and is in late phases or has completed most migrations. PQC deployment has expanded from pilots to critical systems and eventually enterprise-wide, following the planned phases (e.g., internal apps → customer-facing apps → widespread infrastructure). Transition is managed with minimal disruption due to careful scheduling and testing. The organization likely has a detailed playbook for migration (sometimes called a runbook or cookbook), covering steps to switch algorithms, rollback plans if issues occur, and coordination steps among multiple teams . For any remaining systems that are not yet migrated (perhaps due to external constraints), there are clear compensating controls or timelines. At this maturity, the enterprise treats cryptographic migration as an ongoing capability – e.g., the team that handled this transition can handle future ones (it’s not a one-off project but a repeatable process in the organization’s muscle memory). The success of the migration is validated and documented, and the organization shares lessons learned internally (or even externally to help others).

Level 1 – Ad Hoc

Cryptographic components are not specifically tested beyond normal QA. There is no particular testing for algorithm strength (aside from relying on standard libraries) and no scenario-based testing for quantum-safe operations. The concept of testing a new algorithm or its integration is not on the team’s radar.

Level 2 – Developing

The need for specialized crypto testing is recognized. The organization begins to include cryptographic considerations in its testing plans. For instance, test cases might be added for ensuring systems can handle larger keys or dual algorithm handshake. If a pilot PQC implementation is underway, the team conducts basic tests for correctness (does data still decrypt properly with new algorithms?) and performance (what is the latency of a PQC handshake?). At this stage, the testing is still mostly internal and functional. Security testing like code review or penetration testing might start to include checks on whether crypto algorithms are implemented and configured correctly (e.g., no usage of weak ciphers, but now also checking if PQC libraries are properly used in pilot code).

Level 3 – Defined

A comprehensive cryptographic testing regimen is established. This includes: Security testing – the organization integrates PQC scenarios into penetration testing and red-team exercises, looking for vulnerabilities like downgrade attacks (could an attacker force the system back to a weak algorithm?), side-channel leaks in PQC implementations, or misuse of APIs. Code analysis and fuzzing are employed on cryptographic code paths, given that PQC algorithms are new and might have undiscovered implementation bugs. Interoperability testing is done if hybrid or multi-vendor systems are in play (e.g., ensuring a PQC-encrypted message by System A can be understood by System B). Performance and stress testing are also crucial: the organization tests how PQC algorithms perform under load, and ensures that any system performance degradation is within acceptable limits. Additionally, the enterprise pursues validation of crypto implementations – for example, getting new cryptographic modules FIPS 140 validated, or using test vectors to verify algorithm correctness. External third-party audits or assessments of the cryptographic implementation might be conducted (engaging crypto experts to review code and configurations).

Level 4 – Optimized

Continuous validation and improvement. At this maturity, the organization has a feedback loop from testing into development: results from cryptographic testing (like a discovered vulnerability or a performance bottleneck) are promptly used to improve systems. Testing for cryptographic issues is automated where possible – e.g., integrated into CI/CD pipelines (every build runs unit tests and static analysis on crypto functions). The company might participate in cryptographic resilience exercises beyond itself – for instance, cross-industry drills to ensure that, say, if algorithm X is deprecated overnight, all participants can switch to Y without issue. The organization maintains a vulnerability response process specifically for cryptography : if a new weakness in a PQC algorithm or library is announced, there’s a practiced procedure to swiftly assess impact and deploy patches or changes (much like emergency patch management, but for crypto). Ultimately, cryptographic assurance is treated as an ongoing requirement, with periodic re-testing (including re-certification of modules) and adaptation as new threats or findings emerge.

Level 1 – Ad Hoc

There is no active monitoring of cryptographic usage beyond basic security operations. The organization does not track which algorithms are being used in real time or if any systems fall out of compliance with crypto policies. Cryptographic incidents (like a certificate expiration or a library vulnerability) might catch the organization by surprise. The incident response plan does not specifically address cryptographic emergencies (e.g., a scenario where a critical algorithm is suddenly found vulnerable).

Level 2 – Developing

Basic monitoring and metrics are introduced for cryptography. The security team sets up some key indicators to watch, such as tracking SSL/TLS configurations across servers (to see if any are using deprecated ciphers) or scanning logs for cryptographic errors. The organization starts incorporating cryptography checks in regular audits – for example, verifying that systems use only approved algorithms during periodic compliance reviews. If a major external event occurs (like NIST announcing SHA-1 deprecation deadlines or an emergency vulnerability in a library), the organization reacts in an ad hoc but somewhat timely manner, perhaps issuing a directive to update configurations. An outline of a cryptographic incident response plan might be drafted, adding to the IR plan scenarios like “what if our primary encryption algorithm is broken?”.

Level 3 – Defined

Active monitoring and formal audit processes cover cryptographic posture. Dashboards or reports provide visibility into cryptographic deployments – e.g., percentage of traffic using hybrid/PQC algorithms, versions of cryptographic libraries in use, expiration dates of certificates – as part of security operations metrics. The organization’s internal audit or compliance function includes cryptographic controls in its scope, ensuring policies (from Practice 2) are followed in practice and that the PQC transition progress is on track. The enterprise stays closely tuned to external updates: there’s a defined process to track standards evolution and threat intelligence around cryptography. For instance, a team subscribes to NIST announcements, academic crypto research feeds, and industry alerts; they evaluate each update for relevance to the organization. Importantly, an incident response playbook for cryptographic events is in place. If tomorrow a flaw in the chosen PQC algorithm is discovered, the team has contingency plans (perhaps switch to an alternate algorithm, enable a fallback mechanism as a short-term patch, etc.). Regular drills or simulations might be conducted to ensure the team is ready to execute these plans.

Level 4 – Optimized

Continuous cryptographic posture management and agile adaptation define this level. Real-time monitoring is in place – for example, systems might automatically alert if an unapproved algorithm is used, or if a new device joins the network using legacy encryption. Cryptography-related metrics are integrated into enterprise risk scoring and trigger automated workflows (like creating a ticket if a weak cipher is detected on a server). The organization undergoes independent audits or certifications of its cryptographic controls as part of wider compliance (demonstrating to customers/regulators its PQC readiness). Moreover, the enterprise exhibits a capability to rapidly adapt: when changes occur (new standards, new threats), it updates its cryptographic implementations on short notice. A practical sign of this could be how quickly the organization applied a patch or config change during the latest crypto vulnerability compared to peers. Finally, lessons learned from monitoring and incidents feed back into strategy – completing the loop. For example, if monitoring shows slow adoption of a new algorithm in one division, that information is used to adjust training or planning (thus improving subsequent cycles). The organization strives for a state where cryptographic risk is continually managed to be as low as possible through vigilant oversight and nimble response.