Cryptography Audit Checklist

1. Define the audit scope and authority

Begin by recording the organisation, business units, systems, jurisdictions, data classes, trust domains, suppliers, and assessment period in scope. A cryptography audit is not a single algorithm check: it covers cryptographic mechanisms, their implementation, the keys and certificates that support them, the protocols that negotiate them, and the operational processes that govern their use. The audit record should identify the authority relied on for each conclusion and preserve the source’s document status, version, publication date, and any stated limitation. This prevents a recommendation, forecast, or informative technical report from being presented as a universal legal obligation.12

2. Build an evidence-backed cryptographic inventory

The first substantive audit test is completeness. Identify every service and infrastructure component that depends on cryptography, including public-key key establishment, digital signatures, certificates, protocol negotiation, application libraries, hardware or validated modules, backup and recovery processes, and supplier-managed services. Record the algorithm or mechanism, parameter set, purpose, implementation, version, key owner, lifecycle state, location, data protected, retention period, dependencies, and evidence of actual use. Include systems that are difficult to change: embedded devices, industrial control systems, long-lived archives, partner connections, and products with fixed protocol behaviour.16

• Asset and service identifier, owner, environment, jurisdiction, and business criticality.
• Cryptographic purpose: confidentiality, integrity, authentication, key establishment, signing, hashing, or key derivation.
• Algorithm, parameter set, protocol, certificate chain, implementation or module, and configuration source.
• Key and certificate lifecycle: generation, storage, distribution, rotation, revocation, backup, destruction, and access evidence.
• Data sensitivity, expected confidentiality lifetime, transaction lifetime, and consequences of compromise.
• Supplier, dependency, upgrade path, interoperability constraint, and evidence that the mechanism is actually negotiated or invoked.

Inventory evidence should be reproducible. Compare source configuration with observed traffic, application behaviour, certificate usage, logs, and endpoint measurements. A declared capability is not proof of deployment. NCSC guidance specifically recommends testing that systems use standardised PQC cipher suites rather than falling back to traditional cryptography, and recommends metrics that quantify how many software clients use PQC and identify those that do not.1

3. Identify quantum-vulnerable uses and prioritise them

Separate symmetric cryptography from public-key dependencies in the risk analysis. The cited NIST standards describe the risk to commonly used public-key key-establishment and digital-signature schemes whose security depends on integer factorisation or discrete logarithms, including finite-field and elliptic-curve settings, if large-scale quantum computers are realised. FIPS 203 describes ML-KEM as an approved alternative presently believed secure against an adversary with a large-scale fault-tolerant quantum computer, and specifies three parameter sets with different security-strength and performance trade-offs. That description does not by itself establish that every deployment is secure or that ML-KEM is appropriate for every use case.34

Prioritise systems according to the value and required lifetime of the protected information, exposure of the protocol, replacement difficulty, criticality, and dependency concentration. Give early attention to information that must remain confidential for many years, critical communications and systems, business-sensitive or personally sensitive data, and public-facing or partner-facing trust relationships. Preserve uncertainty: the evidence supports planning for quantum risk, but it does not provide a date on which a cryptographically relevant quantum computer will exist.341

4. Check algorithms, implementations, and assurances separately

An audit should distinguish an algorithm standard from the security of a product or system. FIPS 204 and FIPS 205 state that protecting signing private keys is essential, that conformance to the standard does not ensure a particular implementation is secure, and that a conforming product does not guarantee security of the overall system. The responsible authority must assess whether the overall implementation provides an acceptable level of security. Therefore, test secure construction, private-key protection, side-channel and fault considerations where relevant, random generation and entropy dependencies, access control, module boundaries, logging, recovery, and change management rather than recording only the algorithm name.45

For ML-KEM, verify the exact FIPS 203 parameter set, implementation provenance, approved use context, validation or assurance evidence required by the applicable programme, and secure application integration. FIPS 203 aims to provide sufficient implementation information to pass validation and refers users to general KEM definitions and secure-use requirements. The audit should not infer validation merely because a library claims compatibility with a standard.3

1. Confirm that the selected mechanism is within the applicable authority, policy, contract, accreditation, or system scope.
2. Verify parameter-set selection against security, bandwidth, computation, latency, and interoperability requirements.
3. Inspect key generation, storage, access, backup, rotation, revocation, destruction, and private-key exposure controls.
4. Review implementation assurance, testing, vulnerability management, secure update paths, and separation of duties.
5. Test end-to-end system behaviour, including certificate validation, negotiation, error handling, downgrade resistance, and recovery.

5. Audit hybrid designs and crypto-agility

Hybrid schemes or protocols combine post-quantum and traditional algorithms. ETSI reports that they can mitigate potential vulnerabilities in post-quantum implementations or provide backward compatibility during migration. They may reduce bandwidth, computation, and latency overhead when a post-quantum algorithm is paired with a traditional elliptic-curve algorithm, but they increase protocol, implementation, and key-management complexity. The audit must document whether the design seeks hybrid security, hybrid interoperability, or both, and must analyse what security remains if one component is broken.2

Test negotiation and downgrade resistance explicitly. ETSI warns that inappropriate hybrids can be less secure than a non-hybrid post-quantum design, and that algorithm negotiation must be protected against downgrade attacks. Hybrid interoperability can also involve mixed populations: traditional clients, clients that understand both types, and clients that understand only post-quantum algorithms. Protocol constraints may justify retaining a traditional component; ETSI gives IKEv2 message-size and fragmentation as an example. Document the constraint, compensating control, end state, and retirement condition.2

Crypto-agility is an architectural audit criterion, not a promise that algorithms can be changed instantly. BSI recommends making mechanisms sufficiently flexible to respond to developments, implement future recommendations and standards, and replace algorithms that no longer provide the desired security level. Inspect abstraction boundaries, algorithm identifiers, certificate and key-management interfaces, policy distribution, deployment automation, rollback controls, test environments, and supplier commitments. Assess whether a change can be made without redesigning every application or losing inventory and assurance evidence.61

6. Test migration, measure outcomes, and report findings

A defensible audit report should connect each finding to an asset, threat or requirement, evidence, owner, severity, remediation, and due date. Distinguish missing discovery from a known quantum-vulnerable mechanism, an insecure implementation, an untested hybrid, a policy mismatch, and an unavailable supplier upgrade. Record residual risk and assumptions. Where an authority gives only recommendations or indicative timelines, say so; do not write a legal conclusion that the evidence does not support.21

Use migration gates: inventory complete; high-priority dependencies classified; target mechanisms selected; prototypes tested; interoperability and performance measured; downgrade and fallback behaviour tested; production rollout observed; and traditional support retired only after evidence supports retirement. NCSC states that migration plans should remain flexible because architectures and key-management solutions will need to evolve around new algorithms. Its guidance also recommends rigorous assurance and metrics to measure progress and determine when traditional algorithms can be turned off.16

Finally, review the inventory and controls continuously. NCSC describes PQC migration as a mass technology change taking years, while BSI recommends that migration considerations begin early and continue in response to developments. Review triggers should include new standards or amendments, supplier changes, discovered vulnerabilities, protocol changes, material changes in data lifetime, new regulatory or accreditation requirements, and evidence that deployed behaviour differs from approved configuration.16

7. Practical audit sequence

Run the audit as a sequence rather than as an algorithm shopping exercise: establish scope and authority; discover cryptographic dependencies; classify data and trust relationships; identify quantum-vulnerable public-key uses; assess implementation and key protection; evaluate crypto-agility; test hybrid negotiation and downgrade resistance where relevant; define and measure migration gates; and report residual risk. This sequence keeps current control effectiveness, future quantum exposure, and migration readiness distinct while allowing them to be assessed together.126

• Scope: record jurisdiction, sector, systems, data, suppliers, authority, document version, status, and dates.
• Discover: produce an owner-validated inventory and reconcile configuration with observed use.
• Assess: evaluate algorithms, parameters, keys, implementations, certificates, protocols, validation, and operational controls.
• Prioritise: rank by data lifetime, sensitivity, criticality, exposure, replacement difficulty, and dependency risk.
• Migrate: design crypto-agile changes, test approved or authorised mechanisms, and document hybrid rationale where used.
• Assure: measure actual PQC use, detect fallback, track exceptions, and retain evidence for every conclusion.
• Govern: review changes continuously and avoid presenting guidance targets as universal legal requirements.

Conclusion

A cryptography audit is strongest when it proves both what an organisation intended to deploy and what its systems actually do. Start with complete discovery, preserve jurisdiction and document status, distinguish requirements from recommendations and forecasts, and assess implementation and private-key protection independently of algorithm selection. For PQC readiness, prioritise long-lived and sensitive information, make architecture crypto-agile, test hybrid and downgrade behaviour, and measure real client and protocol use. The cited evidence supports structured preparation and risk-based migration; it does not support a universal deadline or a blanket legal conclusion for every organisation.126