Security: three layers that must not be confused

In plain words

"Secure" is not one thing. A lock on a diary and a vault at a bank are both locks, but they protect different things against different people.

My Vote Forward has three layers, and each needs a different kind of security:

1. This website teaches. It should be hard to deface, its admin accounts should be well protected, and it should not collect your political views.
2. The demo lets you try things with a real account. Your saved priorities and opinions must be protected. The election inside it is simulated. Nothing you do there is an official vote.
3. A future official voting system would be a different project, run under election law, tested by independent experts, and approved by the authorities responsible for elections. It does not exist here.

This page explains what each layer must protect and why nobody should read the security of the first two as evidence about the third.

Defined terms

• Threat model. A written account of what is being protected, from whom, by what means, and with what assumptions.
• Assurance. Evidence that a system meets its security requirements, such as testing, review, audit, and operational records. Assurance is about evidence, not intention.
• Certification. A formal decision by an authorized body that a specific system version meets a specific standard. In U.S. elections, federal certification against the Voluntary Voting System Guidelines is voluntary unless state law requires it ¹.
• Software independence. A property where an undetected change or error in software cannot cause an undetectable change in an election outcome; VVSG 2.0 builds its auditability principle on this concept ^{1 3}. See audits and verification.
• Phishing resistance. In NIST's authentication guidelines, a property that "requires single- or multi-factor cryptographic authentication"; "passwords are not phishing-resistant" ⁵.
• Least privilege. Giving each person or process only the access its job requires. VVSG 2.0 requires default policies that "enforce the principles of least privilege and separation of duties" ¹.

See also the glossary.

Evidence

What official voting systems are held to

The U.S. Election Assistance Commission adopted VVSG 2.0 on February 10, 2021 ^{1 2}. Its security principles include access control (systems "authenticate administrators, users, devices, and services before granting access to sensitive functions" and include "multi-factor authentication mechanisms for critical operations"), physical security, data protection ("all cryptographic algorithms are public, well-vetted, and standardized"), system integrity ("multiple layers of controls," limited attack surface, verified software integrity, and updates "authorized by an administrator prior to installation"), and detection and monitoring ¹. VVSG 2.0 "does not permit devices or components using external network connections to be part of the voting system," explaining that with such a connection "an attack can be orchestrated from anywhere in the world" ¹. It also states that its requirements "do not apply to remote ballot marking devices and applications" ¹.

Standards take years to reach equipment. An EAC report published in 2026 states that more than five years after adoption, "two systems have been certified to VVSG 2.0," the first in July 2025 and the second in November 2025, and that "federal law does not require states to use the VVSG" ⁴. Many states run their own certification or technical review ⁴. See jurisdictions.

What federal agencies concluded about internet ballot return

The 2020 joint assessment by CISA, the EAC, the FBI, and NIST, re-released publicly for the 2024 cycle and described by CISA as remaining operative, says "electronic ballot return technologies are high-risk even with controls in place" and recommends paper ballot return ⁶. It identifies three reasons that differ from ordinary website risk: scale ("electronic systems present far greater risk to impact a significant number of ballots in seconds"), personal devices ("votes cast through 'bring your own device' voting systems may appear intact upon submission despite tampering"), and privacy, because remote systems often link identity and ballot digitally ⁶. It quotes the National Academies: "We do not, at present, have the technology to offer a secure method to support internet voting" ⁶. The National Academies' 2018 report recommends human-readable paper ballots and risk-limiting audits ⁷.

This review checked the CISA resource page for a successor document. The page is marked archived and describes the guidance as remaining operative for the 2024 cycle; no successor was identified in this review. Readers should check current CISA and EAC guidance before relying on it.

What end-to-end verification would add, and its current status

The EAC, with NIST, is establishing a process "to solicit, evaluate, and approve cryptographic E2E verifiable voting protocols," each round expected to last about a year ³. Required properties include cast as intended, recorded as cast, and tallied as recorded, plus dispute resolution and ballot secrecy ³. The described scope is polling place verification ("while in the polling place via a receipt") ³. It is a process for evaluating protocols, not an approval of any remote voting product.

Why a health privacy rule or "encryption" proves nothing here

The HIPAA Security Rule governs "electronic protected health information" held by covered entities and business associates ⁸. It is not an election standard. Likewise, encrypting data protects confidentiality in transit or at rest; it does not establish who is eligible, whether a vote was coerced, or whether results were tallied correctly. Those are separate requirements, as the VVSG principles show by listing them separately ¹.

Competing interpretations

"Security through modern technology" versus "security through evidence." One view holds that strong cryptography, cloud infrastructure, and biometrics have made secure online voting achievable. The federal agencies' 2020 assessment and the National Academies' 2018 report conclude otherwise for internet ballot return at present ^{6 7}. The difference is partly about evidence: the second view asks for independent evaluation and auditability that do not rely on trusting the software.

Paper as safeguard versus paper as barrier. Paper records support audits ⁷, but they can create obstacles for some voters with disabilities or voters abroad. Remote ballot marking with a printed, voter-verified ballot is one compromise the CISA assessment discusses ⁶.

Interpretation, this site's reading. The disagreement is often about which threat matters most. A designer focused on access sees exclusion; a designer focused on integrity sees attacks at scale. Both are real. A credible design names both and shows evidence for how each is handled.

Application to this framework

Threat model, in brief

Layer 1: the educational website (current)

The project's build specification requires least-privilege administration, multi-factor authentication for privileged roles, server-side authorization, secure session handling, managed secrets, input validation, rate limits, a content security policy and related headers, protected uploads, log redaction, dependency scanning, backups with a restoration check, and incident and rollback runbooks. It prohibits political preferences in analytics, session replay, tracking pixels, error traces, URLs, or email notifications. These are requirements of this project. Whether each is implemented and verified is reported on the status page, not assumed here.

Layer 2: the demo (current)

The demo protects real account data while simulating the election. Its specification requires passkeys where supported, consistent with NIST's direction toward phishing-resistant authentication ⁵; multi-factor authentication for privileged roles; safe recovery and session revocation; origin and request-forgery protection; strict cross-origin rules; encrypted storage of sensitive account data; no session replay or advertising pixels on sensitive routes; and no political preferences sent to social or AI services. It collects no government ID, face video, fingerprint, or registration documents. It has no ballot submission endpoint, no stored ballot choices, and no hidden switch to enable live voting. Encryption of account data is not described as anonymity; see privacy.

Layer 3: future official election security (not built)

This layer is a requirements and research program. A jurisdiction-specific assurance case would have to address, separately: legal authority; identity proofing and eligibility (identity and registration); prevention of duplicate counting across channels; ballot secrecy and coercion (intimidation); correct recording and tallying; independent verification and audits (audits and verification); availability and continuity; accessible alternatives; hardware and key custody (hardware); and dispute resolution. It would need to be a separate, reviewed project and deployment, not a dormant feature of the demo. No single administrator, countdown, or configuration value can enable official voting.

What this page does not claim: no certification, no legal approval, no "zero fraud," and no guarantee of privacy. EAC and NIST documents are cited to explain requirements, not as approvals of this project.

Unresolved questions

• Can a remote channel meet the software independence principle without paper, for example through an approved end-to-end protocol, and would that address household coercion? The EAC process has not answered this for remote voting ³.
• What independent party would evaluate the demo's account security, and how would results be published?
• How should availability be guaranteed, and what happens to an election if a network or service fails? See governance.
• Which elements of the threat model change by jurisdiction, and which are universal?