Authentication tries to confirm who or what is submitting a vote, while integrity controls ensure the vote is counted once, in the right form, and with the right weight. A system can authenticate successfully and still be manipulated if normalization, duplication, or commit logic is weak. In voting workflows, integrity is the control that protects the outcome.
Why Authentication and Integrity Solve Different Problems
In online voting, authentication answers the question “who or what is casting this ballot?”, while integrity answers “does this ballot remain valid, unique, and correctly counted from submission to tally?”. Those are related, but not interchangeable. A system can strongly authenticate a voter and still lose the election outcome if the vote can be altered, duplicated, replayed, mis-normalized, or applied with the wrong weight.
The distinction matters because voting is not just an access problem. It is also a correctness problem: the system has to preserve the meaning of the vote, not merely accept a legitimate submitter. integrity controls therefore sit around the ballot lifecycle, while authentication sits at the front door.
Where Authentication Ends and Vote Integrity Begins
Authentication is about proving the source of an action. In voting, that usually means verifying a registered voter, a device, or a session before the ballot is accepted. It does not, by itself, guarantee that the submitted choice survives every downstream step unchanged, or that the same choice is not submitted twice through a different path.
Integrity controls begin once the vote enters the workflow. They enforce normalization rules, one-record-one-vote logic, duplicate detection, commit and tally consistency, and tamper-evident handling so the stored or counted ballot matches the submitted intent. In other words, authentication validates the actor, but integrity validates the ballot.
This is why ballot-handling failures are often process failures rather than login failures. If the workflow can be replayed, reprocessed, or transformed incorrectly, the election can be distorted even when every voter is “properly authenticated.”
What Can Go Wrong in the Voting Pipeline
Integrity weakness usually shows up after sign-in. The common failure modes are duplicate submission, inconsistent normalization of a ballot, broken idempotency in the commit path, weak reconciliation between the cast vote and the counted vote, or a data path that allows one authenticated action to produce more than one counted outcome.
That is why integrity controls are broader than input validation. They include ledger-style protections, immutable or append-only handling where appropriate, auditability of every transformation, and reconciliation that can prove the tally came from the exact set of accepted ballots. Authentication alone cannot detect a ballot that was altered after submission or counted more than once.
For online voting, the right question is not only whether the user got in, but whether the end-to-end record of the vote is stable, attributable, and mathematically consistent with the rules of the election.
Risk and Threat Considerations
Online voting creates a high-value integrity target because an attacker does not need to break authentication if they can corrupt the vote after it is accepted. Weak commit logic, replay paths, duplicate processing, or faulty normalization can change outcomes while still leaving the sign-in layer apparently successful.
Failure mechanism: The attacker or failure condition exploits a gap between authenticated submission and final tally, such as replays, duplicate records, tampered ballot state, or inconsistent transformation of the vote before counting.
Impact: The system may record the wrong voter intent, count the same ballot more than once, suppress a valid ballot, or apply the wrong weight, which directly undermines election correctness and trust.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Online voting starts with proving the submitter's identity. |
| SI-7 — Software, Firmware, and Information Integrity | Vote counting depends on preventing tampering and preserving ballot correctness. | |
| AU-10 — Non-repudiation | Vote systems need evidence that accepted ballots were not altered or replayed. | |
| Recommendation — Enforce strong voter or operator authentication before accepting a ballot submission. Protect ballot data and tally processing from unauthorized modification. Retain auditable evidence linking each accepted ballot to its final counted state. | ||
| OWASP ASVS | V8 — Authorization | Voting workflows need strict one-action, one-outcome enforcement beyond sign-in. |
| V16 — Security Logging and Error Handling | Integrity assurance depends on traceable ballot processing and exception handling. | |
| Recommendation — Require server-side checks that prevent duplicate or out-of-scope vote actions. Log ballot processing steps and handle tally exceptions without corrupting results. | ||
Practitioner Guidance
What to verify: Treat the ballot lifecycle as the control boundary. Verify that one authenticated submission produces one immutable counted record, that duplicate handling is deterministic, and that every transformation from intake to tally is auditable.
Decision rule: If a control only proves the voter’s identity, do not treat it as sufficient for election assurance. Require separate evidence that the ballot cannot be replayed, rewritten, reweighted, or reprocessed without detection.
What good looks like: The system can demonstrate end-to-end reconciliation from accepted ballots to counted totals, with clear exception handling for duplicates, malformed submissions, and any ballot that fails integrity checks.
Practitioner takeaway: Authentication makes sure the right party can submit a vote, but integrity is what makes the counted outcome trustworthy; in online voting, outcome assurance depends on controlling the whole submission-to-tally path, not just the login event.
Related resources from NHI Mgmt Group
- What is the difference between DNS failover and DNS integrity controls?
- What is the difference between data privacy controls and enterprise authentication controls for AI applications?
- What is the difference between JWT authentication and JWT authorization controls?
- What is the difference between detective and preventive controls in authentication security?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org