How crypto-agile is your organization?

Inventory 1/9 — We maintain an up-to-date inventory of the cryptographic algorithms in use across the organization (a CBOM).

Inventory 2/9 — Our inventory is built around which data and systems the cryptography protects — not just a flat list of algorithm names.

Inventory 3/9 — Cryptographic discovery is automated — built into vulnerability management or development tooling — rather than a manual, one-off effort.

Inventory 4/9 — Our inventory covers third-party libraries, vendor products, and supply-chain dependencies, not just internally written code.

Inventory 5/9 — Inventory ownership is a defined, documented responsibility — assigned to a role or team — not something that depends informally on one person's knowledge.

Inventory 6/9 — Our CBOM is actively maintained and reflects a recent snapshot — not a one-time audit that's gone stale.

Inventory 7/9 — Our inventory explicitly covers hardware-embedded cryptography (HSMs, TPMs, secure elements, firmware) — not just software that's easy to scan automatically.

Inventory 8/9 — Our inventory tracks certificate and key metadata — expiration dates, rotation history — not just which algorithm is in use.

Inventory 9/9 — Our CBOM uses a standardized, machine-readable format (e.g., CycloneDX) rather than an ad hoc spreadsheet.

Architecture 1/9 — Cryptography is implemented behind a crypto API that separates application logic from the underlying algorithm.

Architecture 2/9 — In the past two years, we've actually swapped or patched a cryptographic algorithm or library in response to a real vulnerability — not just believe we theoretically could.

Architecture 3/9 — Crypto APIs are centralized, rather than each team implementing its own cryptographic calls independently.

Architecture 4/9 — We've tested, piloted, or deployed hybrid (classical + post-quantum) algorithms in at least one system.

Architecture 5/9 — Key length, signature size, and ciphertext size are not hardcoded assumptions in application logic (fixed buffers, byte counts, etc.).

Architecture 6/9 — When an algorithm is disallowed, we actually remove it from our systems — not just add newer options alongside the old one.

Architecture 7/9 — Our algorithm negotiation (e.g., TLS cipher suite selection) has integrity protection against downgrade attacks.

Architecture 8/9 — We have automated CI/CD checks (linting, static analysis) that flag hardcoded or disallowed cryptographic calls before code merges.

Architecture 9/9 — We test cryptographic implementations for correctness and side-channel resistance before deploying — including hybrid or composite algorithms, not just the classical half.

Risk & Prioritization 1/9 — We have a defined internal deadline for retiring 112-bit-security-strength algorithms (e.g., RSA-2048), aligned with NIST's disallowance timeline.

Risk & Prioritization 2/9 — We prioritize which systems to migrate first based on data sensitivity and criticality — not just which is easiest to implement.

Risk & Prioritization 3/9 — We've identified which systems handle long-lived, confidentiality-sensitive data and prioritized those for earlier migration, given the risk that encrypted data collected today could be decrypted once quantum computers arrive.

Risk & Prioritization 4/9 — We actively track regulatory and standards deadlines relevant to our sector and the jurisdictions we operate in (e.g., NIST's US timelines, the EU's Coordinated PQC Roadmap, or sector-specific mandates).

Risk & Prioritization 5/9 — We measure crypto-agility progress with defined metrics (e.g., time or cost to migrate a system), not just informal status updates.

Risk & Prioritization 6/9 — We actively track whether our critical vendors and suppliers have published PQC migration timelines, and factor that into our own planning.

Risk & Prioritization 7/9 — For our most sensitive data, we've compared how long it must stay confidential against how long migration would take and current quantum timeline estimates — i.e., we know whether we're already behind.

Risk & Prioritization 8/9 — We require crypto-agility as an explicit criterion in vendor RFPs and security questionnaires for new purchases.

Risk & Prioritization 9/9 — We've run a tabletop exercise simulating an algorithm being urgently broken or deprecated, to test our actual response.

Governance 1/9 — Executive leadership is aware of our post-quantum migration timeline, and crypto-agility shows up in the organization's risk register.

Governance 2/9 — We have a documented, organization-wide cryptographic policy — not just informal, team-by-team practices.

Governance 3/9 — Engineers — not just the security team — are trained on crypto-agility practices as part of onboarding or ongoing education.

Governance 4/9 — We have a defined cryptographic architecture — documented standards, protocols, and key-management practices — not just ad hoc, per-project decisions.

Governance 5/9 — We have a plan for handling already-encrypted data or already-signed documents when the algorithm that protected them is retired.

Governance 6/9 — There's a dedicated budget line item for crypto-agility work — not just verbal executive support.

Governance 7/9 — We have a defined key and certificate rotation cadence that's followed outside of major migration events.

Governance 8/9 — Cryptographic algorithm compromise or deprecation is explicitly part of our incident response / business continuity plans, not handled as a special case when it happens.

Governance 9/9 — We can demonstrate our crypto-agility practices to external auditors, customers, or regulators when asked.