Unit 3 · Level 2 → Level 3 · Inventory, CBOM & Crypto Agility
The Corporate Migration
Checklist in Context
The corporate migration checklist is the most directly reusable asset in this course. Every item on it should now feel familiar, because you have spent three lessons building the vocabulary to understand why each one is there.
Part 1
From Inventory to Action — How the Checklist Connects
In Lessons 3.1 through 3.4, we built the foundational layer: understanding what a CBOM is, how to read it, how to assess agility, and how discovery tooling produces it. Those lessons were about seeing clearly. This lesson, and Lesson 3.6, are about acting decisively.
The Corporate Migration Checklist in your course workbook translates the CBOM inventory into an organized sequence of actions. It is structured in six categories that map directly to the migration chain from Lesson 3.1: governance, inventory, assessment, remediation, validation, and ongoing monitoring.
Every item on the checklist has a "why", a reason it exists that connects back to something you have already learned. This lesson walks through the checklist item by item and makes those connections explicit. By the end, the checklist should not feel like a set of tasks handed down from above. It should feel like the logical conclusion of everything in Units 1–3.
📌 How to Use This Lesson
The interactive checklist below is organized by category. Click any item to expand it and read the explanation of why it exists. You can also check off items to track which ones apply to your own organization or context. Your check state persists during this session. The progress bar shows how much of the checklist you have reviewed.
Part 2 — Interactive
The Corporate Migration Checklist
Post-quantum migration is an organization-wide project that spans IT, security, compliance, legal, and vendor management. Without a named owner who has executive visibility and authority to prioritize, the project will stall at the first cross-departmental conflict. This person does not need to be a cryptographer, they need to be able to make decisions and escalate blockers.
Why it's on the checklist: PKIMM Level 3 requires evidence of active management. A named migration owner is the governance artifact that demonstrates the organization has moved from awareness to accountability. Without this, every other checklist item is someone's side project.
The migration affects systems owned by different teams. A working group with representation from each affected area ensures that decisions are made with full context, blockers are surfaced early, and ownership for each CBOM item is clear. Legal and compliance representation is particularly important, regulatory timelines may impose migration deadlines that the IT team is unaware of.
Who should be in the room: IT infrastructure, application development, security operations, compliance/legal, and, for organizations with third-party vendors, procurement. At small organizations, this may be two or three people wearing multiple hats.
A migration policy formalizes what the organization has decided to do, by when, and who is responsible. It converts the CBOM from an inventory into a commitment. The policy does not need to be long, it needs to be explicit about: which algorithms are being deprecated, what the replacement targets are (referencing FIPS 203/204/205), what the migration timeline is by priority tier, and what the escalation process is when a migration item is blocked.
PKIMM connection: This document, combined with the CBOM, is the primary evidence package for a PKIMM Level 3 assessment. The assessor is looking for evidence that the organization has committed to a plan, not just performed a one-time scan.
Several regulatory frameworks now include or are expected to include explicit PQC migration requirements. U.S. federal agencies must migrate per OMB memoranda and CISA guidance. Financial institutions face DORA requirements in the EU and sector-specific guidance from regulators. Healthcare organizations face HIPAA technical safeguards that may be interpreted to require quantum-resistant encryption for protected health information.
Why this is governance, not assessment: Regulatory timelines create hard deadlines that override the organization's internal priority triage. If your organization is subject to a regulatory deadline of 2028 for specific asset classes, that deadline supersedes any internal decision to defer those assets to "medium-term." Governance must capture these external constraints before the internal migration plan is finalized.
This is the foundational deliverable, the output of Lessons 3.1 through 3.4. The CBOM must cover all in-scope systems: network infrastructure, applications, certificates, keys, and vendor-managed assets (with documented scope boundaries for the latter). It must include the six fields defined in Lesson 3.2: asset name, algorithm, vulnerability status, proposed replacement, priority tier, and location/owner.
Minimum viable CBOM: Even a partial CBOM, scoped to the highest-risk systems, is better than none, because it enables triage to begin. Document the scope explicitly and plan to expand coverage iteratively.
→ Covered in depth: Lessons 3.1, 3.2, 3.4
TLS certificates are the most visible and most immediately actionable cryptographic assets in most organizations. They have known expiry dates, which create natural migration windows. Certificate inventory should include: subject name, issuer (CA chain), algorithm and key size, expiry date, location/system, and renewal method (manual vs. automated).
Why expiry dates matter: A certificate expiring within 12 months is a migration window, if PQC certificates are available from your CA by then, you can migrate at renewal rather than forcing a separate off-cycle replacement. Certificate expiry data turns migration planning from a theoretical exercise into a calendar.
→ Certificate fields covered in Lesson 3.2 (certificateProperties)
Code signing certificates carry special risk because they establish trust in software distributed to others. A compromised code signing certificate does not just affect the organization, it affects everyone who installs or runs software signed by that certificate. This makes code signing migration high-priority regardless of the certificate's expiry date.
Distribution scope: "How widely is this software distributed?" is the key question for code signing priority. Internal-only tools are lower risk than software distributed to clients, partners, or the public. The Meridian Agency's code signing certificate, distributed to clients, is Immediate priority precisely because of its distribution scope.
Every SaaS platform, cloud provider, and managed service in your environment uses cryptography you do not directly control. These assets belong in the CBOM with a "vendor-managed" designation and a monitoring plan, not because you will migrate them yourself, but because you need to verify that the vendor does.
What a monitoring plan looks like: Identify the vendor's published PQC roadmap (AWS, Google, and Microsoft have all published theirs). Note the expected migration date. Set a calendar reminder to verify completion. If the vendor has no published roadmap, request one in writing, that request becomes part of your compliance record.
→ Vendor-managed gap type covered in Lesson 3.4
Every CBOM entry must have a quantum vulnerability classification. This is the field that drives priority triage. The three-tier classification: Broken by Shor's (RSA, ECC, DH), Weakened by Grover's (AES-128, SHA-256), Not affected (AES-256, SHA-384), is what converts the CBOM from a list into a prioritized action plan.
Common error: Misclassifying AES-128 as "not affected" because it is a symmetric algorithm. Grover's algorithm halves the effective key length of all symmetric ciphers: AES-128 drops to approximately 64-bit post-quantum security, which is below acceptable thresholds. AES-128 is weakened, not safe.
→ Vulnerability classification covered in Lessons 2.3, 3.1, 3.2
For every asset classified as Immediate priority (Shor's-broken algorithms in high-exposure or high-value systems), the agility score must be assessed before the migration plan is finalized. The agility score determines the realistic timeline and effort. A Level 0 asset with an agility score of 7 can be migrated in weeks. The same asset with an agility score of 1 may require months or years.
Priority order: Start with Immediate assets. Assess agility for Medium-term assets during the planning phase, their agility scores will determine whether their timeline is truly medium-term or needs to be accelerated because migration lead time is long.
→ Agility assessment covered in Lesson 3.3
Harvest Now Decrypt Later (HNDL) is the attack scenario where an adversary collects encrypted data today and decrypts it when a cryptographically relevant quantum computer becomes available. Data with long-term sensitivity, medical records, financial data, legal communications, intellectual property, long-term contracts, is at risk right now, even before quantum computers exist.
What to flag: Any data that (a) is encrypted with RSA or ECC, (b) has sensitivity that will persist for 5+ years, and (c) is transmitted or stored in a way that could be intercepted. This includes archived encrypted emails, long-term database backups, and historical VPN traffic logs.
Action: HNDL exposure may elevate assets from Medium-term to Immediate priority, specifically for key exchange algorithms protecting long-lived data. This assessment must be completed before finalizing the priority tier for any encryption-in-transit or encryption-at-rest CBOM entry.
→ HNDL concept covered in Unit 1, Lesson 1.3
Cryptographic assets are rarely standalone. A TLS certificate has an associated private key, which is managed by a key management system, which may itself rely on an HSM, which has a firmware-embedded algorithm. When you migrate the certificate, you may need to migrate the key management system and the HSM firmware along with it. If you only plan for the leaf certificate, you will discover the dependency mid-migration, the most expensive place to find it.
Dependency mapping tool: The relatedCryptoMaterialRefs field in the CycloneDX CBOM (Lesson 3.2) is specifically designed for this. A well-structured CBOM includes these links, which makes the dependency graph visible before migration planning begins.
The replacement algorithm for each CBOM entry must be selected from NIST's finalized post-quantum standards. The mapping by asset type is straightforward: key exchange (previously ECDH/RSA-KEM) → ML-KEM (FIPS 203); digital signatures (previously ECDSA/RSA-PSS) → ML-DSA (FIPS 204) or SLH-DSA (FIPS 205) for highest assurance; hash-based signatures for firmware → XMSS or LMS.
During the transition period: Use hybrid algorithms, classical + PQC in combination, so that migration to PQC does not break backward compatibility with systems that have not yet migrated. NIST IR 8547 formalizes this hybrid approach for TLS and related protocols.
→ Algorithm selection covered in Unit 2, Lessons 2.1–2.3
The Immediate priority tier is not aspirational, it means migration planning and, where technically feasible, migration execution should begin now. For assets with sufficient agility, "beginning migration" may mean updating a configuration file. For assets with low agility, it means beginning the procurement, vendor negotiation, or architectural redesign process that will enable migration.
Where to start: VPN key exchange (especially for organizations handling sensitive data in transit), externally facing TLS certificates (at next renewal where hybrid PQC is available), and code signing certificates (given supply chain implications). These three categories typically represent the most urgent CBOM items for a corporate environment.
Every CBOM item with a low agility score and a non-zero migration requirement has a vendor dependency. The organization needs a plan for each one: either the vendor delivers PQC support on a timeline that works, or the organization plans to decommission or replace the system. That decision should be made now, not when the migration deadline is approaching.
Vendor engagement language: Use the procurement questions from Lesson 3.3 (Persona C aside) as the basis for vendor negotiations. Get commitments in writing. A vendor who cannot articulate a PQC roadmap is a vendor whose timeline you do not control, that is a risk to document in your migration plan.
Every new system procured today without crypto-agility requirements is a future migration problem. The organization's procurement process must include PQC readiness criteria, specifically the three questions from Lesson 3.3: what algorithms are used, can they be changed by configuration, and what is the PQC support timeline?
Contract language: Include PQC migration commitments in vendor contracts for systems with cryptographic components. A contract that specifies FIPS 203/204/205 support timelines is enforceable in a way that a verbal assurance is not.
PQC algorithms behave differently from their classical counterparts in ways that can cause unexpected issues: larger key and signature sizes affect performance and packet sizes, some systems have hardcoded buffer sizes that overflow with PQC key material, and hybrid algorithms require both endpoints to support the combined scheme. These issues are discoverable in a test environment; they are disruptive in production.
What to test: Performance under realistic load (ML-KEM keys are larger than ECDH keys, check that latency is acceptable), backward compatibility (can classical clients still connect during the transition?), and key/certificate size limits in any system that handles cryptographic material.
Not all PQC library implementations are equal. The algorithm being correct and the implementation being correct are two different things. For any PQC deployment in a regulated environment, the cryptographic module implementing ML-KEM, ML-DSA, or SLH-DSA must have a FIPS 140-3 validation from NIST's Cryptographic Module Validation Program (CMVP).
Practical check: Search the CMVP database (csrc.nist.gov/Projects/cryptographic-module-validation-program) for the specific module and algorithm. For regulated industries, use only CMVP-listed implementations. For non-regulated environments, prefer CMVP-validated modules where available, they provide assurance of correct implementation that self-declared conformance does not.
After a migration is complete, re-scan the affected system to confirm that the old algorithm is no longer present. This is the verification step that closes the loop, it converts the CBOM entry from "migration planned" to "migration verified." Without this step, the migration is an assertion, not a confirmed fact.
What to check: The nistQuantumSecurityLevel for the migrated asset should now be 3 or 5 (not 0). The algorithm field should reference ML-KEM, ML-DSA, or SLH-DSA. If a hybrid transition is in place, both the classical and PQC algorithms should appear, this is expected and correct during the transition period.
The CBOM is a living document. When a migration is complete, the relevant entries must be updated: the old algorithm entry is marked as deprecated/replaced, and a new entry for the PQC algorithm is added. The version number of the CBOM document should be incremented, and the change should be logged with a timestamp and the responsible team member.
Why this matters for compliance: An auditor reviewing your CBOM needs to see the migration history, not just the current state. The document version history is what demonstrates that the organization has an active, maintained inventory rather than a one-time snapshot. PKIMM assessors specifically look for evidence of CBOM maintenance over time.
A CBOM that is 18 months old is not a current inventory, it is a historical snapshot. New systems are deployed, certificates are renewed, applications are updated, and vendor configurations change. A quarterly rescan using the tools from Lesson 3.4 keeps the CBOM current and ensures that new quantum-vulnerable assets are identified before they accumulate into a backlog.
Trigger-based updates: In addition to scheduled rescans, update the CBOM whenever: a new system is deployed, a vendor issues a major update, a certificate is renewed, or an incident reveals a previously unknown cryptographic asset. These event-driven updates are what keep the CBOM accurate between scheduled rescans.
NIST SP 800-131A (Transitioning the Use of Cryptographic Algorithms and Key Lengths) is updated periodically as algorithms age out. RSA-1024 was deprecated years ago; RSA-2048 has a deprecation horizon. When NIST updates its transitioning guidance, the vulnerability classifications and priority tiers in your CBOM may need to be revised.
Subscribe to: NIST's Computer Security Resource Center (csrc.nist.gov) for standards updates, CISA advisories for critical infrastructure, and your major vendors' security bulletins for algorithm deprecation notices. A monitoring checklist entry is not a passive "we'll see what happens", it requires an assigned team member to actively track these sources.
Vendor commitments are not self-executing. A vendor who commits to PQC support "by Q3 2027" still needs to be followed up with, and if they miss the commitment, the organization needs a contingency plan. The monitoring phase is where vendor-managed CBOM entries get actively tracked rather than passively hoped for.
What to track: For each vendor-managed entry, record the vendor's committed date, the person responsible for follow-up, and the contingency plan if the date slips. Escalate to procurement if a vendor misses a committed migration milestone, a contract with PQC commitments is enforceable if the organization is actively tracking compliance.
The PKIMM (PKI Maturity Model, version 2.0.0) provides a self-assessment framework for tracking migration progress over time across 16 categories, including the Governance Cryptography category. Complete the assessment exclusively via the official web-based tool at pkic.org, not the retired Excel workbooks. An annual PKIMM self-assessment, using the evidence accumulated during the year (CBOM, migration records, policy documents, training records), gives the organization a defensible measure of its maturity level and identifies the gaps between current state and the next level.
Evidence package contents: Current CBOM with version history, migration policy document, completed Mini CBOM Exercise (from the Unit 3 deliverable), vendor PQC commitment records, training completion records for this course, and results of post-migration verification scans. These together constitute a Level 3 PKIMM evidence package.
→ PKIMM self-assessment covered in Unit 4
Persona Perspectives
Using This Checklist at Your Level
The checklist reads differently depending on whether you are building a program, running a business, or managing systems.
Persona A — The Motivated Learner
This checklist is a professional framework you can apply immediately, either to a real organization you work with, or as the basis for a consulting deliverable or case study. The structure (Governance → Inventory → Assessment → Remediation → Validation → Monitoring) is the same structure used in professional PQC migration engagements by major consulting firms. Knowing it means you can speak the language of a client engagement from day one.
For certification purposes: the PKIMM evidence package described in the Monitoring category maps directly to what the PKIMM assessment framework asks for. If you complete this course, complete the Mini CBOM Exercise, and assemble the evidence package described here for a real or simulated organization, you have the foundation of a PKIMM Level 3 self-assessment.
Persona B — The SMB Decision-Maker
For a 48-person marketing agency, the full 24-item checklist is more than you need to manage directly. Focus on the items most relevant to your scale:
Must-do now: Assign a migration owner (even if that's you), complete the organizational CBOM using the MSP prompt, identify your code signing certificate and flag it Immediate priority, and document your Google Workspace and other SaaS providers as vendor-managed with a monitoring note.
Must-do this year: Begin migration of your code signing certificate and legacy invoicing application authentication, these are the two Immediate-priority items in Meridian's CBOM. For the invoicing app, that means a conversation with your vendor or accountant software provider about their PQC roadmap.
Can defer to medium-term: The validation and monitoring categories are important but can be addressed as part of annual IT review cycles rather than as immediate actions.
Persona C — The IT Professional
This checklist is your project plan template. Each category maps to a project phase, and the items within each category are your work breakdown structure. The checklist is organized in dependency order: Governance must precede Inventory (you need a policy before you scope a CBOM), Inventory must precede Assessment, Assessment must precede Remediation.
Two items to prioritize first, even before the CBOM is complete: (1) The HNDL assessment, identifying data that has long-term sensitivity and is currently protected by RSA or ECDH. This can elevate priority tiers and change your timeline before you even finish the full inventory. (2) The vendor engagement plan for your lowest-agility Immediate-priority assets, starting those vendor conversations now buys time on the longest-lead items.
On tooling integration: The monitoring category items, quarterly CBOM rescan, NIST monitoring, vendor tracking, are candidates for automation. A CI/CD pipeline integration for code scanning, a scheduled Qualys scan, and a calendar-driven vendor review process convert the monitoring checklist from manual tasks into a managed program. That program is what PKIMM Level 4 looks like.
Comprehension Check
3 QuestionsQuestion 1 of 3
An organization has completed a CBOM and classified all assets. They have one Immediate-priority asset: a code signing certificate using RSA-2048 with an agility score of 6 out of 7. A second Immediate-priority asset is a legacy authentication module with RSA-2048 hardcoded in source code with an agility score of 1. How should the migration plan sequence these two items?
Question 2 of 3
The Corporate Migration Checklist includes "Identify Harvest Now Decrypt Later exposure" as an Immediate-priority assessment item. Why is this assessment item in the Assessment category rather than the Remediation category?
Question 3 of 3
A PKIMM assessor reviews an organization's evidence package. The CBOM is complete and current. The migration policy is documented. Three migrations have been completed. However, the CBOM has no version history and no record of post-migration verification scans. What does this gap indicate to the assessor?