Unit 3 · Level 2 → Level 3 · Inventory, CBOM & Crypto Agility
Crypto-Agility —
What It Really Means for a System
Your CBOM tells you what cryptographic assets you have. Crypto-agility determines how hard it will be to replace them. This is the conceptual bridge between inventory and action, and most systems today fail the test.
Part 1
The Bridge Between Inventory and Action
You now have a CBOM. It lists every cryptographic asset in your organization, classifies each one by vulnerability status, and proposes a PQC replacement. The natural next question is: How hard will it actually be to make those replacements?
The answer depends almost entirely on something that has nothing to do with the algorithms themselves. It depends on how the systems that use those algorithms were designed, specifically, whether they were designed to make algorithm changes easy or hard.
That design property has a name: crypto-agility. And understanding it is the difference between a migration that takes weeks and one that takes years.
The Key Insight of Lesson 3.3
"A system is crypto-agile if changing its algorithm requires a configuration change, not a rebuild."
Derived from NIST CSWP 39: Migration to Post-Quantum Cryptography
Read that definition again slowly. Configuration change, not a rebuild. That single distinction is what determines whether your organization's migration will be a controlled, planned transition, or a series of emergency engineering projects conducted under deadline pressure.
Most systems built before 2020 are not crypto-agile. They were designed when algorithm diversity wasn't a concern. RSA was RSA, TLS was TLS, and nobody imagined needing to swap the underlying math on short notice. The result is a global installed base of systems where the algorithm is baked in, literally compiled into the code, or embedded in hardware that cannot be updated remotely.
⚡ Why This Matters Right Now
NIST's deprecation timeline means many organizations have a 5–10 year window to complete migration. For crypto-agile systems, that is comfortable. For non-agile systems, that window may not be enough, especially if a rebuild requires a full hardware replacement cycle, a vendor's development roadmap, or regulatory approval for software changes. The agility assessment on your CBOM entries is what determines whether your timeline is realistic.
Part 2
The Definition That Actually Matters
The word "agility" appears in a lot of security marketing material, often meaning something vague like "we support multiple algorithms." That is not what crypto-agility means in the context of post-quantum migration. Let's be precise.
Crypto-agility is the property of a system that allows it to switch cryptographic algorithms, the primitives, parameters, and protocols it uses, without requiring changes to the system's fundamental architecture or requiring a rebuild of the software or hardware.
There are three layers to this definition that are worth unpacking:
RSA_encrypt() directly, it calls crypto_encrypt(algorithm="RSA") — or better, reads the algorithm from a config file and calls the appropriate library at runtime.When all three layers are present, a system can move from RSA to ML-KEM by editing a configuration file, updating a library version, and, in a well-designed system, without any downtime. When none of them are present, you are facing a rebuild.
Part 3
The Agility Spectrum — None, Partial, Full
Real systems do not divide cleanly into "agile" and "not agile." They fall along a spectrum. Understanding where a system sits on that spectrum determines how you estimate migration effort and prioritize your CBOM entries.
Select a level to see real-world examples and what migration looks like at each point:
No Crypto-Agility
The algorithm is hardcoded, compiled into the application binary, burned into firmware, or embedded in hardware that cannot receive algorithm updates. Changing the algorithm requires replacing the software or hardware entirely.
Migration path: Full rebuild, hardware replacement, or vendor-driven upgrade cycle. Timeline is measured in years, not months. Cost is high.
⚠ Most Common Category
Non-agile systems represent the majority of the installed base for systems built before 2018. If your CBOM contains legacy on-premise applications, embedded devices, or software with long vendor upgrade cycles, assume no agility until proven otherwise.
Partial Crypto-Agility
The system supports algorithm configuration in some areas but not others. For example, the TLS cipher suite may be configurable via a settings file, but the key generation algorithm is hardcoded in the application. Or the protocol layer is agile but the certificate management pipeline is not.
Migration path: Mixed. Some components can be updated by configuration; others require engineering work or a vendor patch. Timeline is medium, months for the configurable parts, potentially years for the hardcoded ones.
Full Crypto-Agility
The system was designed from the ground up (or significantly refactored) to treat cryptographic algorithm selection as configuration, not architecture. All cryptographic operations go through an abstraction layer. Algorithm identifiers are stored in config files or a secrets management system. Protocol layers support negotiation. A new algorithm can be added by updating a config value and the underlying library, with no code changes.
Migration path: Configuration update and library upgrade. Timeline can be as short as days to weeks. Testing and validation still required, but no engineering redesign.
📌 The Goal State
Full crypto-agility is what NIST CSWP 39 recommends as the target architecture for any system undergoing post-quantum migration planning. It is also the design standard for new systems being built today. If you are procuring software or infrastructure now, crypto-agility should be a procurement requirement.
Part 4 — Practice
Test Your Reading: Classify Four Systems
Below are descriptions of four real-world system types. For each one, classify its crypto-agility level. The scenarios are drawn from the types of systems that appear most frequently in organizational CBOMs.
Agility Classifier
Click the agility level that best fits each scenarioScenario 1: A smart card reader used for physical access control. The card uses RSA-2048 for authentication. The reader's firmware is proprietary, issued by the manufacturer in 2015, and has not received an update since 2018. The manufacturer's support line says they "have no plans for a firmware update at this time."
Scenario 2: A corporate email server running Microsoft Exchange on-premise. TLS is configured via the Exchange Admin Center, cipher suites can be added, removed, and prioritized through a UI. However, the S/MIME certificates used for encrypted email are managed by a third-party PKI system that currently only issues RSA certificates.
Scenario 3: A software-defined WireGuard VPN deployment managed via a configuration management tool (e.g., Ansible). The WireGuard protocol currently uses Curve25519 for key exchange, which is set in a config template. The project's upstream maintainers have released a post-quantum fork that supports ML-KEM hybrid key exchange, it can be adopted by updating the config template and redeploying.
Scenario 4: A document signing platform used to execute client contracts. The platform signs PDFs using RSA-2048, implemented via a commercial SDK. The SDK vendor has announced PQC support in their next major version, due in 12 months. The platform's code calls the SDK through a documented API interface that is consistent across SDK versions.
Part 5
What NIST CSWP 39 Says: The Four Pillars
NIST CSWP 39 — formally titled Migration to Post-Quantum Cryptography: Preparation for Considering the Quantum Computing Threat to Cryptographic Standards — is the U.S. federal government's primary migration guidance document. Published in 2024, it establishes crypto-agility as a formal requirement for any organization planning a post-quantum migration.
CSWP 39 identifies four specific capabilities that a crypto-agile system must have. Think of these as the four pillars of agility, a system needs all four to be fully agile.
📌 How Units 3–4 Map to These Pillars
Pillar 1 (Discovery): Lessons 3.1, 3.2, 3.4: CBOM construction and discovery tooling.
Pillar 2 (Replaceability): This lesson + Lessons 3.5, 3.6: Agility assessment and migration checklists.
Pillar 3 (Hybrid Operation): Unit 4, Lesson 4.1: Hybrid certificates and migration architecture.
Pillar 4 (Lifecycle Management): Unit 4, Lessons 4.3, 4.6: Migration roadmap and PKIMM self-assessment.
Part 6
What Crypto-Agile Architecture Looks Like
The difference between an agile and a non-agile system is most visible in how they handle the algorithm layer. Below is a side-by-side comparison of the same application, a document signing service, in its non-agile original form and its crypto-agile redesign.
To migrate to ML-DSA: rewrite signing module, update key storage, update all callers, regression test, redeploy. Estimated effort: 3–6 engineering months.
To migrate to ML-DSA: update config file, update library version, issue new key, validate. Estimated effort: 1–2 weeks including testing.
The application logic is identical in both versions, it signs a document. The difference is entirely in how the algorithm is specified and where. In the non-agile version, the algorithm is an architectural assumption. In the agile version, it is a parameter.
This is the design principle that NIST CSWP 39 is asking every organization to evaluate, and then build toward, for every new system procured or built going forward.
Part 7 — Self-Assessment
The Agility Self-Assessment Checklist
Use this checklist to evaluate any system in your CBOM. For each item you can confirm, the system has that degree of agility. The more items you check, the more agile the system, and the more manageable its migration will be.
Click each item to mark it, use this as a working tool for a real system you are thinking about.
Items checked: 0 of 7 — Start clicking to assess a system
📌 Using This in Practice
Add an "agility score" column to your CBOM. For each asset, note how many of these seven criteria it meets. A score of 0–2 means the migration will require significant engineering work, plan accordingly. A score of 5–7 means migration is primarily a configuration and testing exercise. The agility score is what converts your CBOM from a vulnerability list into an actionable project plan.
Persona Perspectives
Crypto-Agility at Your Level
What crypto-agility means in practice depends heavily on your role and context. Select your persona.
Persona A — The Motivated Learner
Crypto-agility is one of the most professionally valuable concepts in this course because it crosses both the technical and the strategic. Understanding it deeply lets you contribute to conversations that are currently happening at the senior engineering level in most large organizations, conversations about whether to refactor existing systems or replace them, and how to build new systems so they do not create the same migration problem in ten years.
If you are preparing for SSCP or CISSP, the concept maps directly to the "Cryptography" domain (algorithm lifecycle, key management architecture) and the "Security Engineering" domain (secure design principles). The phrase "crypto-agility as a design principle" is the kind of thing that distinguishes a sharp answer on an exam or in an interview.
Going deeper: The IETF has an active working group on crypto-agility: RFC 7696 ("Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms") is the foundational document. NIST CSWP 39 builds directly on it. If you want to understand how this concept is being operationalized in internet standards, that RFC is the right starting point.
Persona B — The SMB Decision-Maker
For your organization, crypto-agility is primarily a procurement criterion. You are not designing systems from scratch, you are choosing between vendors. The question to ask every software vendor you evaluate is: "Is your product crypto-agile? Can we change the cryptographic algorithm it uses by updating a configuration, or does it require a new version of the software?"
Most vendors in 2025 and beyond will have an answer to this question. A vendor with no answer, or one who says "our algorithm is baked in, but we'll release a PQC version when the time comes", is a vendor whose migration timeline you do not control. That is a procurement risk.
For the Meridian Agency: Looking at the CBOM from Lesson 3.2, the legacy invoicing application is the most concerning asset specifically because it has no agility. Everything else in Meridian's environment is either provider-managed (Google Workspace), has a clear migration path (WireGuard, TLS certificates), or is already safe (AES-256 file server). The invoicing app is the one that requires an architectural decision, replace it, or negotiate with the vendor for a PQC-capable version. That decision belongs in your migration plan, and the agility self-assessment in this lesson gives you the language to frame it.
Persona C — The IT Professional
For you, crypto-agility is the most important column to add to your CBOM. Every CBOM entry should have an agility classification: Full, Partial, or None, alongside the algorithm and vulnerability status. Together, these three fields give you the full picture: what is vulnerable (algorithm), how urgent is it (vulnerability status), and how hard will it be to fix (agility level).
The combination that demands the most immediate attention is Shor's-broken algorithm + No agility. That is your legacy invoicing application, your discontinued IoT firmware, your end-of-life network appliance. These are the assets that cannot wait for a vendor roadmap, they need a plan that may involve decommissioning, network isolation, or architectural replacement.
Practical implementation: When you add agility scoring to your CBOM, use the seven-item checklist from this lesson as your rubric. Document the score and the reasoning for each asset. This creates an audit trail, if a PKIMM assessor asks how you prioritized your migration, the agility scores explain your decision logic. A CBOM with agility scoring is significantly stronger compliance evidence than one without.
On new procurement: Going forward, include crypto-agility requirements in your procurement documentation. Three specific questions for any new vendor: (1) What cryptographic algorithms does your product use, and where are they documented? (2) Can the algorithm be changed without a software rebuild, and how? (3) What is your timeline for PQC support, and which FIPS 203/204/205 algorithms will you support first? These questions, in writing, become part of your vendor compliance record.
There is a distinction that appears constantly in cloud procurement and almost never gets named clearly: the difference between data residency and cryptographic key sovereignty. Data residency describes where data is physically stored. Key sovereignty describes who controls the cryptographic keys that protect it: who generates them, who can access them, under what authority, and through what legal mechanisms. These are not the same thing, and conflating them is one of the most common and consequential mistakes in cloud security procurement.
A vendor can store your data entirely within a specific country while a parent company domiciled in a different jurisdiction retains administrative access to the key management infrastructure. The data is local. The cryptographic control is not. This scenario is not a theoretical edge case: it is a routine finding in cloud service procurement reviews, and it has become more acute as organizations try to reconcile PQC migration requirements with existing cloud contracts that pre-date key sovereignty as a named concern. When those contracts come up for renewal, the question of who controls the root keys under what authority needs to be on the evaluation checklist.
The practical test for key sovereignty has three parts. First: who generates the cryptographic keys, the organization, the vendor, or a shared process? Second: who can access the key material, under what conditions, and does any third party have emergency or compelled access? Third: what legal mechanisms govern that access, specifically, do the laws of a jurisdiction other than the data's home country create obligations that override contractual guarantees? An organization that can answer all three clearly has cryptographic control. An organization that cannot has data residency, which is a weaker and different assurance.
The procurement test
In a cloud service evaluation or contract renewal, ask the vendor these three questions directly:
1. Who holds the root keys for the key management infrastructure protecting our data, and in which legal jurisdiction is that entity domiciled?
2. Under what conditions can your organization, a parent company, or a third-party administrator access our key material without our authorization?
3. Does the legal framework of any jurisdiction other than [our country] create obligations that could compel disclosure of our key material?
A vendor who cannot answer these questions clearly has not separated data residency from cryptographic control. The distinction matters for DORA Chapter V third-party risk assessments, NIS2 supply chain security obligations, and CCCS ITSM.40.001 compliance, all of which require demonstrating control over cryptographic infrastructure, not just data location.
The key sovereignty question adds a fourth dimension to the hardware CBOM extension fields introduced in Lesson 4.4: beyond device model, firmware version, and vendor PQC roadmap status, add a key control field: whether your organization, the vendor, or a third party holds the key material for each system, and in which jurisdiction. A CBOM that does not capture key control is incomplete for any organization subject to DORA, NIS2, or ITSM.40.001 obligations.
Related
Key sovereignty intersects with three other areas covered in this course: the hardware CBOM extension fields in Lesson 4.4, the DORA Chapter V third-party risk assessment obligations in Lesson 2.6, and the vendor evaluation five-question framework in Lesson 2.3. The procurement test questions above are a direct extension of the due diligence framework from Unit 2.
Comprehension Check
3 QuestionsQuestion 1 of 3
A security architect says: "Our application is crypto-agile, it supports AES-128, AES-256, and RSA-2048 in the same codebase." Is this an accurate use of the term "crypto-agile"? Which answer best explains why or why not?
Question 2 of 3
According to NIST CSWP 39, which of the four agility pillars does a completed CBOM directly satisfy, and which pillar does it NOT address?
Question 3 of 3
An organization's CBOM shows that its most sensitive system, a financial transaction processor, uses RSA-2048 with a nistQuantumSecurityLevel of 0. The system has an agility score of 1 out of 7 on the checklist. What does this combination imply for the migration plan?