Do you actually know what your cryptographic landscape looks like?

Do you have a single inventory of where public-key cryptography (RSA, ECC, Diffie-Hellman) is used across applications, infrastructure and vendor products?

Does that inventory cover certificates beyond public-facing TLS, including internal CAs, key sizes and expiry dates?

Can you identify which applications embed cryptographic libraries, and which versions?

Do you know what cryptography sits inside the vendor products, appliances, firmware and SaaS services you depend on?

Is each cryptographic finding linked to an accountable system owner?

Do you know which systems protect data that must remain confidential for ten years or more?

Are business criticality and regulatory exposure recorded for those systems?

Have you mapped which systems would break if a certificate chain, protocol version or library changed?

Do your externally facing services support TLS 1.3?

In most of your applications, can algorithms or key sizes be changed through configuration rather than code changes?

Have your key vendors given you post-quantum roadmaps with dates?

Do your PKI, HSM and key-management platforms have a documented path to ML-KEM and ML-DSA support?

Is a named person accountable for cryptographic migration?

Have you agreed criteria for deciding which systems migrate first?

Is your target cryptographic state (approved algorithms, protocols and key sizes) written down?

Are post-quantum requirements included in new procurement and contract renewals?

Have you tested hybrid post-quantum key establishment (for example X25519MLKEM768 in TLS) outside production?

When a cryptographic change is made, can you confirm it actually reached production?

Is your cryptographic inventory updated continuously, rather than as a periodic project?

Could you show your board or auditors current evidence of cryptographic posture and migration progress?