Purpose of the Template
Estimates for breaking RSA-2048 are dropping. Alice & Bob now suggests fewer than 23,000 physical qubits could factor RSA-2048 in as little as three days. This is a significant reduction from Google Quantum AI's 2025 estimate of 1 million qubits. Although these claims come from a preprint that hasn't been peer-reviewed and real-world scaling is unproven, the trend is clear.
For compliance officers, the concern is "harvest now, decrypt later." Data stolen today can be decrypted in the future. While three days to break a key may not impact live transactions, it poses a risk for Controlled Unclassified Information (CUI), export-controlled technical data, or personnel records with long confidentiality horizons.
This template provides a Cryptographic Risk Register entry and prioritization rule. It helps identify which systems to migrate first and creates the documentation an assessor will need.
Prerequisites
Before using this template, gather:
- A current system inventory with data categories mapped to each system, including CUI Basic and CUI Specified.
- Your System Security Plan and any Customer Responsibility Matrix for cloud services.
- Cryptographic Module Validation Program certificate numbers for every FIPS 140-2 validated module in use.
- A list of Public Key Infrastructure components, including X.509 Certificate issuers, key lengths, and Certificate Revocation List practices.
- Data retention schedules to understand how long each data set must remain confidential.
- Relevant contract clauses, such as DFARS 252.204-7012 and its Flow-Down Requirements.
The Template
Copy one block per system or data flow.
CRYPTOGRAPHIC RISK REGISTER ENTRY
ID: CR-[###]
System / Data Flow: [name]
System Owner: [name, role]
Date Entered: [date] Next Review: [date]
1. DATA PROFILE
Data category: [CUI Basic | CUI Specified | ITAR technical data | other]
Required confidentiality lifespan (years): [value from retention schedule]
Contract / regulatory driver: [e.g., DFARS 252.204-7012; NIST SP 800-171]
2. CRYPTOGRAPHY IN USE
Function: [key exchange | digital signature | [data in transit](/glossary/data-in-transit) | [data at rest](/glossary/data-at-rest)]
Algorithm and key size: [e.g., RSA-2048, ECDH P-256, AES-256]
Protocol / location: [e.g., TLS 1.2 at boundary, VPN, code signing]
CMVP certificate #: [number or "none"]
Public-key dependent: [Y/N]
3. EXPOSURE ASSESSMENT
Traffic traverses networks outside your control: [Y/N]
Ciphertext could be captured today: [Y/N]
Confidentiality lifespan exceeds your migration timeline: [Y/N]
Priority tier: [1 | 2 | 3] (see customization rules)
4. MIGRATION PLAN
Target state: [e.g., hybrid key exchange; NIST-standardized PQC algorithm]
Vendor / product dependency: [name, roadmap status]
Interim compensating measure: [e.g., shorten data retention, add [Two-Layer Encryption](/glossary/two-layer-encryption)]
Milestone dates: [date, date, date]
Owner: [name]
5. AUTHORIZATION IMPACT
Control references affected: [e.g., SC-12, SC-13, SC-8 in NIST SP 800-53 Rev 5;
3.13.8, 3.13.11 in NIST SP 800-171 Rev 2]
FIPS 140-2 validation status of replacement module: [validated | pending | none]
SSP / POA&M update required: [Y/N, ticket #]
6. SIGN-OFF
Compliance reviewer: [name, date]
Risk acceptance (if deferring): [authorizing official, date, rationale]
Customizing the Template
Section 1 sets your priority. Focus on the confidentiality lifespan. Prioritize systems where this lifespan, plus your migration time, extends beyond when an adversary might decrypt stored ciphertext. You don't need a precise Q-Day prediction; the dropping resource estimates are reason enough to act now.
Tiering Rule. Use a straightforward scheme:
- Tier 1: Public-key cryptography protecting long-lived CUI or export-controlled data on external networks.
- Tier 2: Public-key cryptography for shorter-lived data or long-lived data on isolated networks.
- Tier 3: Symmetric-only protections and short-lived transactional data.
Public-key mechanisms like RSA and elliptic-curve cryptography are vulnerable to Shor's algorithm. Symmetric encryption is treated differently, so confirm algorithm-specific guidance from NIST before downgrading anything.
Section 4 interim measures. If a vendor hasn't provided a post-quantum option, note that dependency and any compensating measures. Options include shortening retention or reducing data crossing external links.
Section 5 and your authorization boundary. Don't claim quantum-safe status until the replacement module is validated or you've documented why it's not required. Current validation programs focus on FIPS 140-2. Any cryptographic changes may require an SSP update and coordination with your provider under the Shared Responsibility Model.
Flow-down. If you're a prime contractor, send a simplified version of this template to subcontractors handling CUI. Cryptographic posture is part of what DFARS 252.204-7012 Flow-Down Requirements mandate.
Validation Steps
- Completeness check. Ensure every system storing or transmitting CUI has an entry. Cross-check against the SSP inventory.
- Evidence check. Verify each CMVP certificate number corresponds to a validated module, and the algorithm in Section 2 matches the module's validation.
- Discovery check. Conduct a Vulnerability Assessment-style sweep for certificates and TLS configurations your inventory might have missed.
- Tier review. Have someone outside the system team review each Tier 3 assignment. Long-lived data is often underrated.
- Governance check. Ensure every deferral has a named authorizing official, rationale, and review date.
- Cadence. Re-review the register whenever NIST, CNSS, or your contracting officer issues new cryptographic direction, and at least annually.
If a Third-Party Assessment Organization or Independent Assessor inquires about your quantum readiness, this register provides a dated, evidence-backed record showing you've inventoried, prioritized, and planned accordingly.
