The Recertification Cliff

Post-quantum migration is often described as a software upgrade: find the vulnerable algorithms, replace them with NIST-approved alternatives, test the implementation, and deploy.

That description does not fit voting systems.

A deployed voting system is a certified configuration of hardware, software, firmware, documentation, procedures, and security controls. Cryptography sits inside that configuration. Replacing an algorithm can change key generation, digital signatures, trusted boot, software verification, authentication, election-record protection, communications, storage formats, hardware performance, and recovery procedures. Under the U.S. Election Assistance Commission's certification program, changes to a certified system require review, and material modifications can trigger delta testing, regression testing, integration testing, a new test report, and EAC approval.

That creates a recertification cliff. A jurisdiction may recognize a future cryptographic risk years before it possesses a certified, state-approved, vendor-supported system capable of addressing it.

The difficult part is not selecting a post-quantum algorithm. NIST has already standardized ML-KEM for key establishment and ML-DSA and SLH-DSA for digital signatures, and it recommends that organizations begin migration planning now. The difficult part is moving those algorithms through the institutional machinery that makes election technology lawful, supportable, testable, and safe to use.

Certification is the control

The Voluntary Voting System Guidelines establish the requirements against which voting systems are tested for federal certification. The EAC's program is voluntary at the federal level, but many states require EAC certification or incorporate the federal guidelines into their own certification and procurement processes. States may also impose additional testing and approval requirements that the EAC does not evaluate.

This distinction matters. A local jurisdiction usually does not have unilateral authority to modify the cryptography in a certified voting system. It procures a system certified to a defined version and configuration, then operates that system under state law, vendor instructions, chain-of-custody procedures, and local security controls.

The certification boundary is intentionally restrictive. Election officials should not be able to download an unreviewed cryptographic library, enable an experimental algorithm, replace a signing module, or modify trusted-boot verification immediately before an election. The restriction protects system integrity by ensuring that consequential changes receive independent evaluation.

The same restriction, however, slows cryptographic migration. A voting system manufacturer must first determine what cryptography the system uses and which components depend on it. The manufacturer must then integrate the replacement algorithm, update the technical documentation, assess effects on system performance and interoperability, and submit the change through the appropriate EAC process. An EAC-accredited Voting System Test Laboratory, or VSTL, evaluates the system against the applicable VVSG and the manufacturer's declared specifications.

The jurisdiction enters near the end of this chain, not the beginning.

VVSG 2.0 raises the floor

VVSG 2.0 requires cryptographic functionality to be implemented in a module meeting current FIPS 140 validation and operating in FIPS mode. It also requires voting-system devices to use NIST-approved algorithms with at least 112 bits of security strength.

The guidelines apply cryptography to functions that reach well beyond data encryption. VVSG 2.0 includes requirements involving digitally signed cast-vote records and ballot images, cryptographic software and firmware verification, random-number generation, message authentication, authentication-data protection, and system-integrity verification before the operating system loads.

Consequently, "add post-quantum cryptography" is not one change.

A migration could affect:

Cryptographic modules and their FIPS validation status.
Election-management and device communications.
Digital signatures on cast-vote records and ballot images.
Software, firmware, and configuration-package verification.
Trusted boot and system-integrity checks.
Key generation, distribution, storage, rotation, backup, and destruction.
Authentication protocols and administrator access.
Record formats, signature sizes, storage capacity, and transfer time.
Election evidence, audit tools, and third-party verification utilities.
Recovery media and procedures for authenticating restored software.
Hardware that lacks the memory, processing capacity, or secure storage needed for a new implementation.

A post-quantum signature scheme may therefore touch several subsystems that were tested together. Even if the algorithm is secure in isolation, the modified voting system must still demonstrate that it functions correctly as a complete election system. That is precisely what certification is designed to establish.

A change is not "just crypto"

The EAC distinguishes among changes to certified systems. A change order covers a qualifying change to previously certified hardware, software, documentation, or data and requires VSTL review and endorsement followed by EAC approval. If a proposed change does not qualify for that treatment, it is handled as a modification and submitted for testing and review under the program manual.

A modification is subject to testing of the changed elements, regression testing of affected systems or subsystems, and system-integration testing. The VSTL produces a test report for EAC review after testing is complete.

A narrowly scoped cryptographic-library update might, depending on its effects, be proposed as a limited change. A migration that replaces key-establishment protocols, signature mechanisms, cryptographic hardware, trusted-boot components, record formats, or verification workflows is more likely to affect system functionality or architecture. Its classification ultimately depends on the certified system and the EAC process; neither the vendor nor jurisdiction can safely presume that a cryptographic change is minor.

This is the first edge of the recertification cliff: the greater the security value of the migration, the less likely it is to be operationally invisible.

Electora position: A jurisdiction cannot deploy post-quantum cryptography merely because NIST has standardized it. The cryptographic component must become part of a tested voting system, an EAC-approved configuration, a state-authorized product, and a locally supportable election process. Q-RET exists to make that transition visible before the timeline becomes irreversible.