Compliance and Cryptography

1. What “compliance and cryptography” means in the post-quantum context

A compliance analysis should begin by separating four questions: what threat is being addressed, what technical standard applies, what authority or jurisdiction is in scope, and whether the cited text is binding, advisory, or a forecast. The evidence here includes final NIST Federal Information Processing Standards, current government resources and guidance from the NSA, UK NCSC, and German BSI, and a final ETSI technical report. They do not establish one cross-jurisdictional rule for every organisation. In particular, a government standard describing protection of sensitive U.S. federal information should not automatically be treated as a legal obligation for a private organisation or for an organisation outside the United States.123

The central technical concern is the future effect of sufficiently capable large-scale quantum computers on commonly used public-key cryptography. The NIST standards explain that key-establishment and digital-signature schemes relying on integer factorization and discrete logarithms—including those over finite fields and elliptic curves—would be at risk in that scenario. This is a risk statement about cryptographic assumptions and future capability; it is not evidence of a current universal date by which every organisation must complete migration.24

2. What the cited standards and authorities actually establish

NIST’s FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard, is final version FIPS 203 and was published on 2024-08-13. It specifies ML-KEM and three parameter sets with different trade-offs between security strength and performance. The cited passage states that all three parameter sets are approved to protect sensitive, nonclassified communication systems of the U.S. federal government. FIPS 203 also states that ML-KEM is an approved alternative to the key-establishment schemes in SP 800-56A and SP 800-56B, which the passage describes as vulnerable to attacks using sufficiently capable quantum computers.2

FIPS 204, Module-Lattice-Based Digital Signature Standard, and FIPS 205, Stateless Hash-Based Digital Signature Standard, are also final NIST standards published on 2024-08-13. The cited context says NIST selected its first four algorithms for standardization after three rounds of evaluation and analysis, and that the algorithms are intended to protect sensitive U.S. government information into the foreseeable future, including after cryptographically relevant quantum computers. FIPS 204 identifies ML-DSA as derived from CRYSTALS-Dilithium; FIPS 205 specifies a stateless hash-based signature scheme associated in the passage with SPHINCS+.54

The compliance significance is precise but limited. A final standard can provide a defined technical baseline for the systems and authorities to which it applies. It does not, without an additional rule, contract, procurement condition, sector requirement, or other applicable authority, establish a universal obligation for all organisations. The source set does not supply such a universal rule. Teams should record the document title, version, publication date, authority, system scope, and applicability decision rather than citing “PQC compliance” as an undifferentiated status.123

3. The cryptographic baseline: key establishment, signatures, and assurance

A practical inventory should distinguish public-key uses rather than treating cryptography as one control. Key establishment protects the process by which communicating parties establish keying material; digital signatures support authentication, integrity, and assurance about signed data. FIPS 203 addresses a key-encapsulation mechanism, while FIPS 204 and FIPS 205 address signature standards. This distinction matters for migration sequencing because replacing a key-establishment mechanism does not automatically replace certificate, signing, validation, archival, code-signing, or other signature uses.254

The NIST material also shows why algorithm selection is not the whole compliance analysis. FIPS 203 refers to implementation information intended to support validation, and FIPS 204 and FIPS 205 state that conformance does not ensure that a particular implementation is secure. They place responsibility on the implementer to build a secure module and on the responsible authority to ensure that the overall implementation provides an acceptable level of security. Protecting private signing keys is expressly identified as necessary.54

A defensible compliance record should therefore connect each cryptographic dependency to its purpose, owner, data sensitivity, exposure, key and certificate lifecycle, implementation, validation status, and replacement path. It should also preserve uncertainty: the evidence describes a future quantum threat and migration guidance, but it does not predict when a cryptographically relevant quantum computer will exist. Risk prioritisation should account for information whose confidentiality must remain intact for many years, as well as systems that are difficult to update. [claim-0224

4. Hybrid cryptography: useful transition pattern, not automatic compliance

ETSI TR 103 966 V1.1.1 (2024-10) explains that deploying post-quantum cryptography alongside traditional algorithms in a hybrid scheme or protocol can mitigate potential vulnerabilities in post-quantum implementations or provide backward compatibility during migration. It also cautions that hybrid designs increase protocol, implementation, and key-management complexity. Bandwidth, computation, and latency overheads may be reduced by pairing a post-quantum algorithm with a traditional elliptic-curve algorithm, but the design still needs careful analysis.1

ETSI expressly says that its document does not provide guidance on whether or not to use hybrid schemes. That limitation is important for compliance: a hybrid deployment should be justified by the particular protocol, use case, interoperability need, risk assessment, and applicable validation or accreditation condition. A hybrid label alone does not show that the construction has the desired security property or that it satisfies a governing requirement.1

The report distinguishes hybrid security from hybrid interoperability. A construction intended to remain secure if at least one component remains secure may address a different objective from a construction intended mainly to support mixed populations of traditional, post-quantum-aware, and post-quantum-only clients. Ad hoc constructions can introduce weaknesses, and the security guarantees that remain if one component is broken must be analysed. Negotiation also needs protection against downgrade attacks. Requirements may differ between confidentiality and authentication.1

Protocol constraints can also be decisive. The cited ETSI example says that post-quantum algorithms may be too large for an initial IKEv2 key exchange, potentially requiring a traditional component until fragmentation issues are resolved. It also describes a TLS example in which a post-quantum certificate chain can provide downgrade protection. These are examples of engineering considerations, not a general instruction to retain or remove traditional cryptography.1

5. Turning standards and guidance into an enterprise migration plan

Migration begins with discovery, not replacement. The UK NCSC describes PQC migration as a mass technology change taking a number of years and identifies early activities including defining migration goals and carrying out a full discovery exercise to understand which services and infrastructure depend on cryptography. Its guidance is directed especially at large organisations, critical national infrastructure, industrial control systems, and organisations with bespoke IT, while recognising that sectors have different levels of cryptographic maturity.3

1. Establish applicability: identify jurisdictions, regulators, contracts, procurement conditions, system classifications, and the authority for each claimed requirement.
2. Create a cryptographic inventory: locate public-key algorithms, certificates, trust stores, signing systems, key-management services, protocols, libraries, hardware modules, backups, archives, and externally managed dependencies.
3. Classify use and exposure: separate confidentiality, authentication, signatures, key establishment, code signing, device identity, and long-lived records; prioritise sensitive data and critical communications.
4. Define an architecture and transition strategy: assess direct post-quantum replacement, hybrid options, protocol constraints, interoperability, validation, performance, downgrade resistance, and rollback.
5. Build assurance and governance: protect private keys, test implementations, document approvals, monitor standards and ecosystem changes, and assign owners for each migration dependency.

The NCSC says initial migration plans should be flexible because architectures must evolve around new algorithms and modern key-management solutions, and because future ecosystem developments may change implementation choices. BSI likewise recommends that organisations start early and continue adapting within appropriate risk management. Together, these passages support a staged plan with decision gates rather than a one-time algorithm swap. They do not prescribe one product, protocol, or implementation for every organisation.36

The NCSC’s cited timeline identifies a 2028 milestone for activities such as defining migration goals, completing discovery, and building an initial plan. It presents 2035 as a target date for completing migration to post-quantum cryptography, while acknowledging that some technologies may take longer. The guidance says organisations should prioritise systems processing business and personally sensitive data or managing critical communications and systems. These dates should be recorded as NCSC guidance and planning targets, with their stated audience and limitations—not as a universal statutory deadline.3

6. What to retain as compliance evidence

A migration file should allow an independent reviewer to reconstruct why a cryptographic decision was made. At minimum, retain the applicable authority and document version, the system and data scope, the inventory method, risk assessment, chosen algorithms and parameter sets, hybrid rationale where relevant, interoperability and performance results, downgrade protections, key-management design, implementation-validation evidence, private-key controls, exceptions, owners, and review dates. This approach follows the evidence’s repeated distinction between a standard, an implementation, and the security of the overall system.54

Do not describe an organisation as “compliant with PQC” merely because it has deployed a named algorithm. A more accurate statement identifies the requirement or recommendation, the applicable jurisdiction and system scope, the exact standard and version, the implementation and validation status, remaining traditional dependencies, and accepted residual risks. Where an authority offers a target date rather than a binding rule, label it as a target. Where a technical report is informative and declines to recommend a choice, preserve that limitation.135

Finally, keep the assessment current. The cited NIST standards are final 2024 publications, ETSI’s cited report is V1.1.1 dated 2024-10, the NCSC timeline guidance was published 2025-03-20, and the NSA resource is marked current without a cited publication date. BSI’s resource is marked current, while the ENISA resource is current and dated 2021-05-04. Those statuses and dates matter when determining whether a citation remains the approved basis for a decision.231

7. Important limitations and jurisdictional cautions

The cited evidence does not provide legal advice, a complete survey of national or sectoral regulation, or a universal mapping from any named standard to every compliance regime. It also does not establish that a particular vendor product, module, certificate authority, protocol profile, or hybrid construction satisfies a requirement. Product and implementation assessments must be performed separately, including any applicable validation or accreditation process.51

The NSA material included in the cited source set also distinguishes post-quantum cryptography from quantum key distribution and states that NSA views quantum-resistant cryptography as more cost-effective and easier to maintain for its context; it does not support treating quantum key distribution as a universal compliance solution. That is an authority-specific position and should not be generalised beyond the stated context.54

Conclusion

Compliance and cryptography require disciplined separation of authority, scope, status, and technical purpose. The final NIST FIPS 203, 204, and 205 standards provide important post-quantum baselines within their stated U.S. federal-government context. ETSI’s hybrid analysis identifies transition benefits and risks without recommending hybrid deployment. BSI and NCSC support early, risk-managed, adaptable migration, with NCSC dates serving as guidance rather than a universal legal deadline. The strongest enterprise response is to discover cryptographic dependencies, prioritise sensitive and critical systems, build cryptoagility, validate implementations and key management, document jurisdiction-specific decisions, and preserve uncertainty until applicable authorities establish otherwise.26135