← All postsNovember 14, 2026

What if the software changes after it was tested?

The voting software passed every test. Then someone walked into an elections office, copied the whole system onto a hard drive, and left. What happens to "certified" after that?

It is the morning of January 7, 2021, and a computer-forensics team is walking through the front door of the Coffee County, Georgia elections office — let in by county officials who had every key. They are not investigators. They are not auditors. They spend the next several hours copying everything: the Election Management System server, the ballot-marking devices, the high-speed scanner, Georgia's statewide Dominion voting-system software. The whole package. They walk out with it on hard drives.

The system they copied had been tested. It had been certified. It had run a real election.

None of that stopped what happened next.

What "certified" actually certifies

Before any voting system touches a real ballot, it goes through a certification process. A testing laboratory examines the hardware and software. It checks that the machine does what the documentation says. It issues a report. The jurisdiction accepts the system.

This sounds thorough. And for a snapshot in time, it is.

But certification is a photograph, not a surveillance camera. It captures the system as it existed on the day the lab examined it. What happens to that system between the lab and your polling place — and between elections — is a different question entirely, and it is largely unanswered by the certification process itself.

The critical gap is this: nobody routinely proves, in a way the public can independently check, that the software running on Election Day is the same software that passed the test.

That gap has a name. We call it the software-swap-before-election problem. It is not theoretical.

Coffee County: when the keys go to the wrong people

The Coffee County episode, documented in depositions in the federal Curling v. Raffensperger case and later in a Fulton County indictment, is the clearest real-world demonstration of why secrecy is a brittle security strategy for election software.

The system's integrity rested, in part, on the assumption that only authorized people would have access to it. That assumption broke the moment a county official let the forensics team in. Several people connected to the breach later pleaded guilty. The Georgia Secretary of State's office described it as unauthorized access in violation of state law.

But here is the question that persists after the guilty pleas: what do you do about an election system whose software has been copied and is now somewhere you don't control?

The honest answer, under the current certification model, is: not much. You can change passwords. You can patch the systems. You can assert, as officials did, that the breach did not affect the integrity of subsequent elections. But you cannot prove it to anyone who isn't already inclined to trust you — because the system was never designed to be independently verifiable in the first place.

As documented in the Curling case, expert testimony before the court included findings that a cyberattack could feasibly swap or delete votes and compromise the system. The court found the QR-code-based tabulation system "does not provide a verifiable and auditable ballot record because it relies on the QR code for vote tabulation and that code itself cannot be read and verified by the voter." A paper printout is not a voter-verifiable record if the printout encodes the actual vote in a barcode no human can read.

Security by opacity failed in Coffee County because opacity always fails eventually. Someone always has the keys.

The deeper problem: what happens between certification and Election Day?

Coffee County is the dramatic version of a mundane problem.

Election systems receive patches, configuration changes, and software updates throughout their operational life. Vendors push fixes. Counties apply updates. Memory cards get reprogrammed between elections. This is normal, reasonable software maintenance — and it happens almost entirely outside public view.

The California top-to-bottom review in 2007, in which University of California computer scientists examined the source code of certified voting systems, found serious vulnerabilities in every system they studied — including risks from malicious software that could spread between machines. The Ohio EVEREST review the same year, which studied certified systems from three major vendors, concluded that all of them "possess critical security failures" and noted that audit logs were commonly forgeable or erasable by the people they were supposed to monitor. These were certified systems, in active use, examined by independent experts who were given the source code.

The lesson from California and Ohio is the same as the lesson from Coffee County: "it was certified" is the beginning of the question, not the end of it.

The U.S. Government Accountability Office made essentially this point in 2005 — in a report issued more than two decades ago — finding that federal efforts to improve voting-system security were under way but "key activities remained incomplete," including establishing secure software repositories and sharing information about vulnerabilities. Some of those gaps have since narrowed. The structural problem has not.

The Princeton experiment, and why it still matters

In 2006, Princeton researchers Ariel Feldman, J. Alex Halderman, and Edward Felten obtained a real Diebold AccuVote-TS — the kind of machine used across the United States — and spent about a minute with physical access to it. What they built was a vote-stealing virus that could install itself through the memory card, alter tallies while keeping all internal records consistent, and spread from machine to machine during normal election-day operations.

The machine was certified. The software had passed testing.

The Princeton paper is now almost twenty years old, and voting systems have changed. But the structural lesson has not: if you cannot independently verify that the software running on Election Day is the software you inspected, then the inspection does not establish much.

A certified-then-updated, certified-then-patched, or certified-then-copied system is not necessarily the system the lab tested. And under most current certification frameworks, there is no routine, independent, public mechanism for checking.

Reproducible builds: the technical fix that changes the question

There is a software-engineering concept that addresses this directly. It is called a reproducible build.

Here is the idea in plain language. When software is compiled — when human-readable source code is converted into the binary that actually runs on a machine — the process usually produces slightly different output each time, depending on timestamps, compiler settings, and other variables. This means that even if you publish your source code, an independent party who compiles it themselves will get a binary that doesn't exactly match the binary running on the deployed machine. You cannot verify, bit-for-bit, that the running code matches the published code.

A reproducible build changes this. When a build is reproducible, anyone who takes the published source code and follows the documented build process gets the exact same binary, byte for byte. You can then compare a cryptographic hash of the binary on the deployed machine to the hash of the independently compiled binary. If they match, you know what code is running. If they don't match, something changed — and you can find out what.

This is not science fiction. The Debian Linux project has pursued reproducible builds since 2013. The Tor Browser achieves them. Bitcoin Core achieves them. These are real, deployed systems where independent parties can confirm that the binary matches the published source.

For voting software, reproducible builds would mean this: after any update or configuration change, the jurisdiction publishes the binary hash. Anyone — a journalist, a researcher, a campaign, a voter's advocacy group — can independently compile the source and check whether the hash matches. If it doesn't, that is a public, falsifiable fact.

This is what it means to replace "trust us" with "check for yourself." Not an audit by officials checking their own systems. Not a certification snapshot. A continuous, independent, publicly verifiable chain from source code to running machine. Read more about this gap and what a real fix looks like.

Why open source is necessary but not sufficient

Los Angeles County's VSAP system, certified in 2018 as California's first certified open-source election tally system, is a genuinely positive development. Public ownership of voting software and open source code mean the counting process can be inspected by independent experts rather than hidden as vendor trade secrets.

But open source solves only the first part of the problem: can anyone see the source code? It does not by itself answer the second part: is the code on the machine the same as the code in the repository?

Switzerland discovered this boundary in 2019. Swiss Post published the full source code of its internet voting system for public scrutiny — a remarkable act of transparency. Independent researchers Sarah Jamie Lewis, Olivier Pereira, and Vanessa Teague read it. What they found was a cryptographic trapdoor: an authority who knew the secret values could generate a shuffle-proof that passed mathematical verification while actually having altered votes. The flaw was invisible in a certified black box. It became findable the moment the source was published and independent cryptographers looked.

Publication enabled detection. But detection happened because someone looked closely at the cryptographic proofs themselves — and found that the proof could lie.

The lesson: open source is a prerequisite, not a guarantee. Reproducible builds add the second layer — proving the code you read is the code that ran. And independent cryptographic audits add the third — proving that even if the code ran correctly, its design doesn't allow hidden manipulation.

All three are necessary. Most election systems have none of them.

What you cannot verify right now, and what would make it checkable

Here is the state of play, stated plainly.

When an election concludes and officials announce the result, you are in a position to verify some things: you can check whether the paper ballot totals from the hand-count match the machine totals (as Georgia's 2020 statewide hand count demonstrated, to within about a tenth of a percent). You can examine chain-of-custody logs for the paper ballots. You can observe the count.

What you cannot verify — in most jurisdictions, by any mechanism currently available to the public — is whether the software that tabulated those ballots was the software the testing lab examined, or whether it was modified at any point between certification and Election Day.

You are trusting a chain you cannot see.

The fix is not mysterious. It requires:

Reproducible builds, so the binary on each machine can be independently verified against the published source.
Published hash values, signed and timestamped, every time software or configuration is updated — before any election that software will touch.
Independent compilation audits, in which parties outside the vendor and outside the election authority compile the code themselves and verify the hashes match.
Paper ballots the voter can read, so that whatever the software does or doesn't do, there is an independent artifact — marked by the voter, readable by a human, countable by hand — that can settle the question.

That last point matters most when the first three fail. The 2020 Georgia hand count confirmed the machine result to within a tenth of a percent precisely because paper ballots existed that were marked by voters and readable without software. The Curling court's concern about Georgia's QR-code system was exactly that the paper printout encodes the tabulated vote in a form no human can read without a machine — which means a "hand count" of those ballots is actually a re-scan, trusting the same software chain again.

Paper is not sufficient if the paper can't be read. Software is not sufficient if it can't be verified. The only system that is resilient against a software swap is one where the voter-marked, human-readable record is both the input to the count and the independent check on the software that counts it.

No Secretary of State's assurance changes this. No "audit confirmed the results" press release addresses it. The question is whether anyone outside the system can independently verify what ran. Right now, in most places, the answer is no.

The shareable truth

Certification tells you the software passed a test once. It doesn't tell you the software that ran on Election Day is the software that was tested. That gap is not a conspiracy — it is an engineering problem with a known solution. Jurisdictions that build for verifiability don't need you to trust them. That's the point.

Explore the software-swap gap in detail | See how common integrity gaps are worldwide | The two-minute version

Sources

See all posts Explore the gaps