FIPS 203/204 Compliance Checklist for Federal Agencies

FIPS 203 and FIPS 204 are no longer draft standards awaiting finalization. They are published, assigned, and mandatory for new federal system procurements. FIPS 203 standardizes ML-KEM for key encapsulation. FIPS 204 standardizes ML-DSA for digital signatures. Together with FIPS 205 (SLH-DSA for hash-based signatures), they form the complete post-quantum cryptographic toolkit that federal agencies must implement according to the timelines established by CNSA 2.0 and OMB M-23-02.

This checklist provides a step-by-step implementation guide for federal agencies and government contractors working toward FIPS 203/204 compliance.

Phase 1: Cryptographic Inventory (Weeks 1-4)

1.1 Identify All Public-Key Cryptographic Usage

Catalog every system that uses RSA, ECDSA, ECDH, DSA, or other public-key algorithms. Include TLS configurations, VPN endpoints, code signing certificates, document signing systems, email encryption (S/MIME), key management systems (KMS), hardware security modules (HSMs), and application-level encryption. Use automated scanning tools where available, but do not rely solely on automation. Manual review of critical systems is essential.

1.2 Document Algorithm Details

For each system, document the specific algorithms and key sizes in use: RSA-2048 vs RSA-4096, ECDSA P-256 vs P-384, X25519 vs X448. Record the TLS library version, the cipher suite configuration, and whether the system supports algorithm agility (the ability to add new algorithms without code changes).

1.3 Classify Data Sensitivity and Retention

For each system, classify the data sensitivity (CUI, PII, PHI, classified, FOUO) and the data retention period. Systems with long retention periods and high sensitivity are the highest priority for migration. Data that must remain confidential for more than ten years is already at risk from harvest-now-decrypt-later.

1.4 Map Interconnections

Identify systems that communicate with external entities (other agencies, contractors, cloud providers, international partners). These connections are the most likely targets for traffic interception and have the highest priority for hybrid key exchange.

Phase 2: Risk Assessment and Prioritization (Weeks 3-6)

2.1 Score Each System

Assign a quantum risk score to each inventoried system based on data sensitivity, retention period, external exposure, and algorithm vulnerability. Weight the scoring toward systems that combine high sensitivity with long retention and external exposure.

2.2 Create Migration Priority Tiers

Tier 1 (Immediate): Systems processing classified data, long-retention PII/PHI, inter-agency communication, financial data. These systems should implement hybrid key exchange within 30 days and post-quantum attestation within 90 days.

Tier 2 (Near-term): Systems processing CUI, internal communications with sensitive content, authentication systems. Migration within six months.

Tier 3 (Planned): Systems processing non-sensitive data with short retention periods. Migration aligned with system lifecycle refresh.

2.3 Document Exceptions

For systems that cannot be migrated within the specified timeframe (legacy systems, vendor dependencies, contractual constraints), document the exception including the risk accepted, the compensating controls in place, and the planned remediation date. Exceptions should be reviewed and approved by the agency CISO.

Phase 3: FIPS 203 (ML-KEM) Implementation (Weeks 4-12)

3.1 Select Parameter Set

ML-KEM-512 (Level 1), ML-KEM-768 (Level 3), or ML-KEM-1024 (Level 5). For most federal systems, ML-KEM-768 provides the appropriate balance of security and performance. Systems processing classified information at higher security levels may require ML-KEM-1024. CNSA 2.0 specifies ML-KEM-1024 for National Security Systems.

3.2 Update TLS Libraries

Ensure all TLS implementations use libraries that support ML-KEM: OpenSSL 3.x with the oqs-provider, BoringSSL (Google), AWS-LC (Amazon), or liboqs. Validate that the library version includes FIPS-validated ML-KEM implementations.

3.3 Enable Hybrid Key Exchange

Configure TLS servers to support hybrid key exchange (e.g., X25519+ML-KEM-768). Hybrid mode ensures security under both classical and post-quantum assumptions. This is the recommended deployment mode during the transition period. Verify that hybrid handshakes complete successfully with major clients (Chrome, Firefox, Safari, Edge).

3.4 Test Performance Impact

Measure handshake latency with ML-KEM enabled. Expected increase is 2-3 KB in handshake size and sub-millisecond latency addition on modern networks. Document performance baselines before and after ML-KEM enablement. Monitor for any client compatibility issues, particularly with older systems or embedded devices.

3.5 Update Key Management Procedures

Update KMS and HSM configurations to support ML-KEM key generation and encapsulation. If HSMs do not support ML-KEM natively, implement software-based ML-KEM with the session keys then wrapped by the HSM. Document the key lifecycle management procedures for ML-KEM keys.

Phase 4: FIPS 204 (ML-DSA) Implementation (Weeks 6-16)

4.1 Select Parameter Set

ML-DSA-44 (Level 2), ML-DSA-65 (Level 3), or ML-DSA-87 (Level 5). ML-DSA-65 provides Level 3 security and is appropriate for most applications. ML-DSA-87 is specified by CNSA 2.0 for National Security Systems.

4.2 Implement Code Signing

Update software and firmware signing pipelines to produce ML-DSA signatures alongside existing signatures. Dual-signed packages allow verification with either classical or post-quantum signatures, supporting backward compatibility during transition.

4.3 Implement Document Signing

Update document signing workflows to produce ML-DSA signatures. For agencies using ArchiveSign or similar long-term signing solutions, ML-DSA signatures ensure that signed documents remain verifiable in the quantum era.

4.4 Implement API Authentication

Add ML-DSA signatures to API authentication tokens. The H33-74 overlay provides this capability as an API call, adding three-family post-quantum attestation to any data flow without modifying the underlying application.

4.5 Update Certificate Infrastructure

If the agency operates its own CA (common for internal PKI), update the CA to issue ML-DSA certificates. For agencies using external CAs, coordinate with the CA on their ML-DSA certificate issuance timeline.

Phase 5: FIPS 205 (SLH-DSA) Implementation (Optional but Recommended)

5.1 Add Hash-Based Signatures for Defense in Depth

SLH-DSA provides signatures based on hash functions rather than lattice problems. Adding SLH-DSA alongside ML-DSA provides defense against potential future advances in lattice cryptanalysis. This is the approach H33 uses: three independent signature families (ML-DSA, FALCON, SLH-DSA) based on three independent hardness assumptions.

5.2 Target Long-Lived Artifacts

SLH-DSA is particularly valuable for artifacts that must remain verifiable for decades: root certificates, legislative records, land titles, treaty documents, and archival materials. The larger signature size (17 KB for SLH-DSA-SHA2-128f) is acceptable for these low-frequency, high-value signing operations.

Phase 6: Testing and Validation (Ongoing)

6.1 Interoperability Testing

Test ML-KEM key exchange with all client types that access agency systems. Test ML-DSA signature verification with all consuming systems. Document any interoperability failures and mitigation strategies.

6.2 Performance Regression Testing

Establish performance baselines for all migrated systems. Monitor for latency increases, throughput decreases, or resource utilization changes after migration. Most implementations show minimal performance impact, but monitoring confirms this.

6.3 Known Answer Tests (KATs)

Run NIST-provided Known Answer Tests for all ML-KEM, ML-DSA, and SLH-DSA implementations. KAT validation is essential -- implementations that pass functional tests but fail KATs may have subtle bugs that compromise security.

6.4 Penetration Testing

Include post-quantum controls in penetration testing scope. Verify that hybrid mode cannot be downgraded to classical-only. Verify that ML-DSA signatures cannot be bypassed. Verify that key management procedures for PQ keys are enforced.

Phase 7: Documentation and Reporting

7.1 Update System Security Plans (SSP)

Update SSPs to reflect post-quantum cryptographic controls. Document the algorithms implemented, parameter sets selected, migration status, and any exceptions.

7.2 Report to CISA and OMB

Per M-23-02 requirements, report migration progress to CISA and OMB. Include the percentage of systems migrated, the timeline for remaining systems, and any challenges or resource requirements.

7.3 Update ATO Documentation

Update Authority to Operate (ATO) documentation to include post-quantum controls. For FedRAMP-authorized services, coordinate with the FedRAMP PMO on incorporating PQ controls into the authorization package.

This checklist is not exhaustive -- each agency's specific systems, data types, and operational requirements will dictate additional steps. But it provides the framework that OMB M-23-02, CNSA 2.0, and the FIPS standards collectively require. The standards are final. The deadlines are approaching. The checklist turns policy into action.