Why Election Software Audits Follow a Different Security Standard Than Everything Else

Most software that handles anything important — banking transactions, medical records, industrial control systems — gets its security validated primarily by trusting the software itself: verifying its code is correct, its cryptography is sound, and its access controls work as designed. Election technology security in the United States has evolved toward a fundamentally different philosophy over the past two decades, built around a principle that sounds almost paradoxical at first: the actual security of an election system should not depend on trusting the software at all, but on having an independent, software-free way to verify its output regardless of whether the software behaved correctly, was tampered with, or simply had an undiscovered bug.

The Concept That Reshaped the Entire Field

This principle has a specific name in election security research: software independence, a term formalized in influential work by computer scientist Ronald Rivest and colleagues in the late 2000s, defining an election system as software-independent if an undetected change or error in its software cannot cause an undetectable change or error in the reported election outcome. This is a meaningfully different and, in an important sense, more demanding standard than simply asking whether election software is well-written and secure, because it explicitly assumes the software might fail or be compromised despite everyone’s best efforts, and asks what safety net exists if that assumption turns out to be true.

The practical mechanism that delivers software independence in most current US election systems is the voter-verified paper audit trail: a physical paper record of each vote, either marked directly by the voter on a paper ballot or printed by a voting machine for the voter to visually verify before it’s cast, that exists independently of whatever the voting software’s internal digital tallies say. This paper record becomes the actual source of truth that can be checked against the software’s reported results, specifically because paper doesn’t have exploitable software vulnerabilities, doesn’t run code that could be maliciously altered, and can be counted by hand using a process that doesn’t depend on trusting any computer at all.

Risk-Limiting Audits: Checking the Software’s Work Statistically

Having a paper record is only useful if there’s an actual, rigorous process for checking the software-reported results against it, and this is where risk-limiting audits come in as the specific statistical methodology that has become the field’s preferred verification tool. A risk-limiting audit doesn’t require hand-counting every single ballot in every election, which would be enormously expensive and slow — instead, it uses statistical sampling techniques to hand-count a carefully calculated subset of ballots, with the sample size and specific ballots selected in a way mathematically designed to guarantee, with high statistical confidence, that if the software-reported outcome were actually wrong, the audit would have a specified minimum probability of catching that error and triggering a larger recount or full hand count.

The specific mathematics behind risk-limiting audits, developed and refined through election security and statistics research over roughly the past fifteen years, allow election officials to state precisely, in advance, exactly how confident a completed audit makes them that the reported outcome is correct — a considerably more rigorous and quantifiable standard than the more informal, non-statistical post-election spot-checks that many jurisdictions relied on previously, and one that has been gradually adopted into state law and administrative rule in a growing number of US states over the past decade, with organizations including the nonpartisan Verified Voting and various academic election security research groups actively involved in both the underlying research and the practical implementation guidance state election officials use.

Why This Field Treats Adversarial Testing Differently Than Most Software Industries

Election technology security has also developed an unusually open relationship with adversarial security testing compared to most critical infrastructure software categories, most visibly through DEF CON’s Voting Village, an event running since 2017 at the DEF CON security conference where actual, in some cases currently or recently deployed, voting equipment is made available for security researchers and conference attendees to attempt to find vulnerabilities in in a public, hands-on setting. This kind of open, public red-teaming of voting equipment stands in real contrast to how most sensitive government or infrastructure technology is typically security-tested, which tends to happen through more closed, vendor-controlled, or classified testing processes rather than an open conference floor.

This openness reflects a deliberate philosophy among election security researchers that public findability of vulnerabilities, even embarrassing ones, ultimately strengthens election system security more than it weakens it, because it creates pressure for vendors and election officials to fix identified problems and, more fundamentally, reinforces exactly why the paper-based, software-independent verification layer matters so much: if a voting machine’s software does turn out to have exploitable vulnerabilities, as adversarial testing has repeatedly demonstrated is possible for various specific pieces of voting equipment over the years, the actual election outcome’s integrity still doesn’t depend on that software being flawless, because the paper record and audit process exist specifically to catch exactly this kind of scenario.

The Certification Process That Sits Alongside This

Beyond the software-independence and audit framework, US voting systems also go through a formal certification process managed at the federal level by the Election Assistance Commission, which maintains voluntary voting system guidelines that vendors’ equipment can be tested against by accredited independent testing laboratories, covering functional requirements, security requirements, and accessibility requirements together. States can choose to require federal certification, apply their own additional state-level certification requirements, or some combination of both, which means the certification landscape varies somewhat by state, but the overall architecture — vendor-built systems tested against detailed technical guidelines by accredited independent labs, rather than either self-certified by vendors or built directly by government agencies — mirrors patterns used in other regulated safety-critical industries, like medical device or aviation equipment certification, where independent third-party technical validation is considered a necessary check on vendor self-interest.

Why This Model Hasn’t Simply Been Adopted Everywhere Else

It’s worth understanding why this software-independence philosophy, despite its clear conceptual appeal, hasn’t been broadly adopted as the default security model for other critical software categories like banking or healthcare systems. The core reason is that election systems have a genuinely unusual property that makes a parallel, non-digital verification layer both practical and uniquely valuable: an individual vote is a simple, discrete, low-bandwidth piece of information that maps naturally onto a physical paper record, and verifying an election’s aggregate outcome through statistical sampling of that paper record is a tractable problem. Most other critical digital systems handle far higher-volume, more complex, and more continuously changing data — a bank’s transaction ledger or a hospital’s patient records — where an equivalent parallel paper-based verification system would be enormously more impractical to construct and maintain, which is part of why those industries have instead concentrated their security investment more heavily on the software and access-control side rather than pursuing an equivalent independent-verification-layer strategy the way election security has.

Election technology security, in other words, arrived at its current, somewhat unusual “don’t fully trust the software, verify independently” model not because election officials or security researchers are uniquely more paranoid than other industries, but because elections happen to have exactly the right structural properties — discrete, countable, paper-representable votes, combined with an unusually high public stake in outcome verifiability — to make that specific defense-in-depth strategy both achievable and worth the very real added cost and complexity of maintaining a parallel physical record and statistical audit process alongside the digital system doing most of the actual day-to-day work.