← All posts

A voting machine is a computer. "Certified" doesn't mean you can trust it

In 2004, Ireland spent millions on voting machines it never used—because an independent commission couldn't prove they worked. What "certified" actually means should terrify you.

It is the spring of 2004, and somewhere in a Dublin warehouse, 7,500 voting machines are sitting in their boxes, brand new, paid for, never to be used.

The Irish government had spent roughly €54 million procuring the Nedap/Powervote electronic voting and counting system. It had been tested. It had been approved by the relevant authorities. By every conventional measure, it was ready.

Then an independent Commission on Electronic Voting took a careful look — and said it could not recommend the system for use.

Not because it had found proof the machines would fail. Not because it had uncovered fraud or sabotage. The Commission's conclusion was more damning than either: it found it could not satisfy itself as to the accuracy and secrecy of the system as presented. The machines had not been proven, to an independent examiner's satisfaction, that they would work correctly. And so a democratic government's default position — the correct one — was: don't use them.

The machines sat in warehouses for five years and were formally scrapped in 2009, at an additional cost to the public. Ireland went back to paper.

That is the story certification is supposed to prevent. It didn't.

What "certified" actually means

Here is what happens when a voting machine gets certified in the United States.

A manufacturer submits its system to an accredited testing laboratory — one of a small number of private firms approved by the U.S. Election Assistance Commission. The lab tests the system against a set of federal standards (the Voluntary Voting System Guidelines, or VVSG). If it passes, the EAC adds it to a list of certified systems. States can then approve it for use.

The testing is real. The labs are credentialed. The standards have substance.

But there is a catch so large you could park those Irish voting machines inside it.

Certification is a snapshot. It reflects what the software was doing on the day the lab tested it. It does not — cannot — guarantee that the software running on election day is the same software the lab examined. It does not follow the machine out the door, through the supply chain, into the warehouse, onto the truck, and into the polling place. It tests a version. It does not certify a living, deployed system.

The U.S. Government Accountability Office made this point in plain language back in 2005: federal efforts to improve electronic voting system security and reliability were underway, but key activities remained incomplete. Years after the crisis that triggered federal reform, the machinery for actually assuring security was still being built. Standards and certification only matter once they exist and are enforced — until then, "we use certified systems" is a claim with no fully operational check behind it.

That gap between claim and reality is the threat model this piece is about.

The Princeton experiment: one minute, undetectable

In 2006, three Princeton researchers — Ariel Feldman, J. Alex Halderman, and Edward Felten — obtained a real Diebold AccuVote-TS touchscreen voting machine. It was a certified machine, one of the most widely deployed in the United States at the time.

They didn't need months. They didn't need a nation-state budget. They needed roughly sixty seconds of physical access.

In that time, an attacker could install malicious code on the machine — code that would steal votes while altering all records, logs, and counters to stay internally consistent. The machine would report clean. The logs would report clean. The totals would add up. And the votes would be wrong.

More alarming still: they built a working voting-machine virus. Code that spreads automatically from machine to machine during ordinary election activity — the routine swapping of memory cards that happens in every jurisdiction on every election day. One infected machine. One card. A chain.

The AccuVote-TS had passed certification. It had been evaluated by a testing lab. It had been approved for use in elections affecting millions of Americans.

None of that stopped what Princeton demonstrated. Because certification tested what the software was supposed to do — not whether an attacker could replace it with something else.

This is the distinction that matters. A lab examines a system for compliance with functional requirements. It is not staging an adversarial attack. It is not asking: what can a motivated attacker with sixty seconds do to this machine before it reaches the polling place? Those are different questions, and the certification process was not — and largely still is not — designed to answer them.

The secret in "secret source code"

Now add another layer.

The software inside those machines is proprietary. A vendor's trade secret. You cannot read it. The testing lab can read it — under a nondisclosure agreement. The EAC can receive a copy for its repository. But the public, the candidates, the parties, the independent security researchers who might catch what the lab missed: none of them can see what is actually running on the machine counting their votes.

This is not hypothetical paranoia. It is a documented problem with a documented consequence.

In January 2021, a computer-forensics firm walked into the Coffee County, Georgia elections office and copied the entire voting system — the Election Management System server, poll pads, ballot-marking devices, scanner software, Georgia's statewide Dominion system. All of it. The Georgia Secretary of State's office later described it as unauthorized access that former county officials allowed, in violation of state law. The episode is documented in federal court depositions in Curling v. Raffensperger and figures in a Fulton County indictment; several connected individuals later pleaded guilty.

Here is the point the Coffee County episode makes about secret source code as a security strategy: it failed the moment a small group of people got physical access to the room.

Proprietary software is not protected by its complexity or its excellence. It is protected by physical security and legal agreements. When those fail — and in Coffee County, they failed completely — the code is out. The attack surface is exposed to whoever received it, wherever they took it.

Secrecy-as-security and verifiability-as-security are not the same thing. They are, in fact, opposites. A system designed for secrecy becomes more dangerous when the secret leaks. A system designed for verifiability becomes more trustworthy the more people inspect it.

The German constitutional standard — and why it matters for you

In 2009, Germany's Federal Constitutional Court did something remarkable. It didn't wait for a proven attack. It ruled on principle: electronic voting machines whose operation cannot be independently verified by an ordinary citizen — without specialist knowledge — violate the constitutional principle of the public nature of elections.

The Court found this requirement flows from the Basic Law's guarantee of democratic legitimacy. Elections must be publicly checkable. Not checkable by experts under NDA. Not checkable by a testing lab on a specific day. Checkable by citizens.

The Nedap machines Germany had used recorded votes only in electronic memory, with no independently verifiable record a voter could inspect. They failed. The ordinance authorizing them was found unconstitutional. Germany went back to paper.

The Court did not require proof that the machines had been tampered with. It held that a system whose correctness rests on trusting hidden software fails the public-verifiability test regardless of whether tampering is ever proven.

Read that again. Not "we found fraud." Not "we found a bug." The system failed because it could not be independently checked. That alone was unconstitutional.

This is a higher standard than any U.S. certification process currently enforces. And it is the correct standard.

What the Irish commission understood

Return to Dublin for a moment. The Irish Commission on Electronic Voting's conclusion was not dramatic. It was careful, precise, and devastating.

The Commission stressed its conclusion was not a finding that the system would not work — it was a finding that it had not been proven, to the Commission's satisfaction, that it would work. It could not satisfy itself as to the accuracy and secrecy of the system as presented.

That phrasing is important. The burden of proof, the Commission held, lies with those deploying the system. It is not enough for a vendor to say "it works." It is not enough for a testing lab to say "it passed." An independent examiner must be able to confirm, through inspection, that it is accurate and that it protects ballot secrecy.

That examiner could not. So the machines never ran in a real election.

The Irish default — when you cannot independently verify, you do not deploy — is the correct default. It is the opposite of the certification-theater default, which is: if it passed the lab, it is certified, and if it is certified, it can be trusted.

Certification is a claim. Verifiability is evidence. These are not the same thing.

The fix: what "independently verifiable" actually requires

So what would a genuinely verifiable voting system look like? Three things, none of which requires the public to trust any single authority.

Public source code. The software that counts votes must be readable by anyone. Not readable by a lab under NDA. Readable by independent cryptographers, security researchers, and journalists. Los Angeles County's VSAP system, certified in 2018, was California's first certified open-source election tally system — meaning the code counting votes could, in principle, be inspected by anyone. That is a baseline, not a finish line.

Reproducible builds. Public source code alone is not sufficient. You also need to be able to confirm that the binary running on the machine — the actual executable code, the thing doing the counting — was produced from the published source and nothing else. This is what cryptographers call a reproducible build: given the same source, you should always get the same binary, so anyone can verify that what is deployed matches what was published. Without this, a vendor could publish clean source code and compile something different.

Cryptographic attestation. The machine running on election day should produce a verifiable record — signed, timestamped, tamper-evident — that links the running software to the published, inspectable version. Not a paper log that can be quietly reprinted. A cryptographic chain that an independent party can check after the fact without needing to trust the vendor, the jurisdiction, or the testing lab.

These three properties together convert "trust us" into "check for yourself." They are not exotic. They are how security-critical software is handled in other high-stakes domains. The Switzerland case makes the point from the other direction: in 2019, when Swiss Post published the source code of its internet voting system for public scrutiny, independent researchers immediately found a cryptographic trapdoor — a flaw that would let an insider generate a shuffle-proof transcript that passes verification while actually having altered votes. The system was suspended pending remediation. The flaw was invisible in a certified black box. It became findable the moment the code was public.

That is the entire argument. Openness caught what certification missed.

The question that remains open

Here is what no official statement, no lab certification, and no "audit confirmed the result" press release can currently answer for the machines in most U.S. jurisdictions:

Is the software running on the machine in the polling place the same software the testing lab examined?

There is no cryptographic chain of custody that lets an independent party answer that question. There is no reproducible build process that would let you check. The chain of trust runs through the vendor, the state, and the testing lab — and it is visible to none of them once the machine leaves the warehouse.

The CISA joint statement after the 2020 election asserted there was "no evidence that any voting system deleted or lost votes, changed votes, or was in any way compromised." That statement also rested, explicitly, on the existence of paper records enabling independent recounts and audits. Read that carefully: the officials' own reassurance derives its force from the verifiability that paper provides — not from the certification that preceded it.

Even the strongest official "it was secure" claim implicitly admits that trust flows from checkable evidence.

The Irish Commission understood this in 2004. The German Constitutional Court enshrined it in 2009. Switzerland learned it from its own cryptographers in 2019.

The question for every jurisdiction still running proprietary, closed, certified-and-deployed voting software is not whether it passed the lab. It is whether anyone outside the vendor's walls can independently confirm what is actually running, right now, on the machines that will count your vote.

Until the answer is yes — verifiably, cryptographically, by any qualified independent party, not by an official assurance — "certified" is a snapshot, not a guarantee.

That is what TrustVoting is built to change.

See how the secret-source-code gap looks across different jurisdictions →

Read the two-minute version of the verifiability problem →

Explore the global map of voting-system transparency →

Sources

See all postsExplore the gaps