Join our Newsletter — 33% off our NHI Course
Home FAQ Identity Beyond IAM How should governments design secure online voting systems…
Identity Beyond IAM

How should governments design secure online voting systems without weakening ballot secrecy or result integrity?

← Back to all FAQ
By NHI Mgmt Group Editorial Team Updated September 18, 2026 Domain: Identity Beyond IAM

Governments need a trusted digital identity layer, strong authentication, and cryptographic protections that separate voter verification from ballot secrecy. The system must prove who is eligible to vote without creating a link between identity and choice. It also needs auditability, resilience, and independent oversight so citizens can trust that votes are accepted, counted, and protected end to end.

What Secure Online Voting Has to Separate

Secure online voting succeeds only when eligibility, authentication, ballot casting, tallying, and audit are treated as distinct trust functions. The system should verify that a person is allowed to vote, then let that person cast a ballot without exposing how they voted. That separation is the core design requirement, because collapsing it creates both privacy and integrity failure modes.

Designers also need to think in terms of trust boundaries, not just features. The voter interface, eligibility registry, ballot store, tallying service, and audit layer should be isolated so compromise of one component does not reveal choices or alter results. Strong NIST AI Risk Management Framework is not the right fit here, but the same governance discipline applies: define the trust boundary before you define the workflow.

For ballot secrecy, the technical goal is unlinkability. For result integrity, the goal is verifiable correctness. Those goals are related but not identical, so the system needs cryptography, logging, and independent verification that support both without giving either one too much power over the other.

Controls That Make the Design Work

Governments usually need a layered architecture: strong voter authentication, eligibility checks, encrypted ballot submission, separation of identifying data from ballot content, and end-to-end verifiability. Digital identity helps prove eligibility, but it must be designed so the identity event does not become a durable trace of the vote itself. That is why privacy-preserving tokenization, one-time voting credentials, or similar separation patterns matter.

Integrity controls should support both prevention and detection. Prevention includes authenticated channels, hardened servers, secure software supply chain practices, and protections against tampering in transit or at rest. Detection includes audit logs, independent tabulation checks, and mechanisms that let observers confirm that accepted ballots were counted as cast. SLSA is relevant where voting software is built and deployed, because build provenance and artifact integrity help reduce the risk of compromised code entering the system.

Governments should also align the voting stack to a secure-by-design baseline. That means minimising privileged access, tightly controlling administrative paths, and treating the election platform as critical infrastructure with explicit recovery planning. NIST Cybersecurity Framework 2.0 provides the right high-level structure for govern, identify, protect, detect, respond, and recover. For election systems, those functions need to be applied with unusually strict auditability and change control.

Risk and Threat Considerations

Online voting concentrates risk in a small number of technical and procedural controls. If voter identity can be linked back to the ballot, secrecy fails. If tallying logic can be altered, integrity fails. If availability is poor, even a secure system can become politically unreliable because voters cannot access it or verify that their ballot was accepted.

Failure mechanism: Common failure paths include identity-to-ballot correlation through logs or metadata, compromised administration interfaces, malicious code insertion, and weak provenance in the build or deployment chain. Adversaries do not need to break every layer, they only need one place where secrecy or count integrity collapses.

Impact: A secrecy breach can expose voter choice and chill participation. An integrity breach can invalidate results, trigger disputes, and force costly recounts or reruns. Even perceived weakness can damage public confidence enough to make the election outcome politically contested.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, CIS Controls v8, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
NIST CSF 2.0GOV — GovernElection systems need explicit governance and oversight for trust boundaries and accountability.
PR.AC — Access ControlVoting platforms depend on tightly limiting administrative and voter access paths.
PR.DS — Data SecurityBallots and identity data must be protected and separated to preserve secrecy and integrity.
Recommendation — Define governance rules for secrecy, integrity, and independent oversight before deployment. Enforce least-privilege access for all election administration and support functions. Protect and segregate ballot and identity data with strong cryptographic controls.
CIS Controls v85 — Account ManagementAdministrative and privileged accounts for voting systems must be tightly governed.
6 — Access Control ManagementElection workflows require strict control over who can access sensitive functions and data.
8 — Audit Log ManagementIndependent auditability is essential for verifying accepted votes and counts.
Recommendation — Restrict and review administrative accounts used to operate election systems. Limit access to ballot handling, tallying, and audit functions to approved roles. Log critical election actions in a way that supports independent verification.
NIST SP 800-63Digital Identity GuidelinesVoter eligibility and authentication rely on strong identity proofing and authentication assurance.
Recommendation — Use high-assurance identity proofing and authenticators for voter eligibility checks.
NIST Zero Trust (SP 800-207)SC-7 — Boundary ProtectionVoting architectures must isolate identity, ballot, tally, and audit components.
AC-4 — Information Flow ControlBallot secrecy depends on controlling how identity data can flow to ballot data.
Recommendation — Segment election components so compromise of one service cannot expose all data. Enforce information-flow rules that prevent identity-ballot correlation.
OWASP Non-Human Identity Top 10NHI-01 — Secrets and Credential ManagementVoting infrastructure depends on secure handling of system credentials and keys.
Recommendation — Protect operational secrets and rotate credentials used by election services.

Practitioner Guidance

What to prioritise: Treat secrecy and integrity as separate acceptance criteria. A system is not ready just because it authenticates voters successfully; it must also prove that no operational path can re-identify a ballot after casting.

What to verify: Require independent testing of the full chain from enrolment to tally, including whether logs, database joins, support tooling, or analytics could reconstruct voter choice. Test both normal operation and administrative recovery paths, because those are often where secrecy leaks appear.

Practitioner takeaway: The safest design is one where no single component, administrator, or audit process can both identify the voter and reveal the vote, while the count remains independently checkable end to end.

Deepen Your Knowledge

Sign up to our weekly newsletter — get 33% off our NHI Foundation Level Course

    NHIMG Editorial Note
    Reviewed and updated by the NHIMG editorial team on September 18, 2026.
    NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org