Hardware: what devices can and cannot prove

In plain words

Many phones and laptops have a small, protected chip that keeps secret keys locked away. When you use a fingerprint or face to sign in, the device checks it locally and then uses that key. The website never sees your fingerprint.

That is useful. It makes stolen passwords far less of a problem. But it proves less than people think:

• It proves someone could unlock that device. It does not prove that person is allowed to vote.
• It does not stop someone standing next to you from telling you what to choose.
• It does not prove the device is free of malware.
• It does not help if you lose the device and have no safe way to recover.

Official voting equipment has its own hardware rules, such as tamper evidence and no internet connections. And no one should need an expensive device to take part.

Defined terms

• Authenticator. Something a person controls that is used to sign in, such as a security key or a phone holding a passkey. See identity and registration.
• Secure element (hardware-backed key storage). A protected component designed to store keys so they cannot be copied out. NIST's highest authentication level, AAL3, "requires the use of a cryptographic authenticator with a non-exportable private key" ¹.
• Device-bound versus synced passkey. The FIDO Alliance distinguishes passkeys that "never leave a single device" from those "synced between user's devices via a cloud service" ².
• Attestation. In Web Authentication, "verifiable evidence as to the origin of an authenticator" and the data it emits ³. Attestation describes the authenticator, not the person using it.
• Secure boot and firmware resiliency. Mechanisms that keep a device's low-level software from being changed without authorization, detect changes, and recover. NIST's guidance on platform firmware resiliency describes "protecting the platform against unauthorized changes, detecting unauthorized changes that occur," and "recovering from attacks rapidly and securely" ⁵.
• Hardware security module (HSM). A dedicated device for generating and using cryptographic keys. Modules can be validated under NIST's Cryptographic Module Validation Program against FIPS 140-3 ⁶.
• Endpoint compromise. Malware or unauthorized control of the device a person is using, even after they have signed in correctly.

See also the glossary.

Evidence

What a fingerprint does and does not do

NIST states that "biometrics SHALL only be used as part of multi-factor authentication with a physical authenticator," that "a biometric characteristic is not recognized as an authenticator by itself," that "biometric characteristics do not constitute secrets," and that "biometric comparison is probabilistic" ¹. The FIDO Alliance states that with passkeys, "biometric information and processing continues to stay on the device and is never sent to any remote server" ². A fingerprint, then, activates a credential under specified conditions. It does not deliver anything to the website that could establish citizenship, age, residence, or registration, and it does nothing about who else is in the room. See intimidation.

Keys, export, and assurance

NIST permits keys that can be exported, such as synced passkeys, at AAL2 or below, but states that because "syncable authenticators ... require the private key to be exportable," they "SHALL NOT be used at AAL3" ¹. The FIDO Alliance says "device-bound passkeys in modern hardware security keys offer the highest security assurance" ². The tradeoff is real: synced keys are easier to recover when a phone is lost; device-bound keys resist copying but make recovery harder.

Personal devices in remote voting

The 2020 federal assessment of electronic ballot return warns that "a voter's personal device may not have the necessary safeguards in place," so that votes "may appear intact upon submission despite tampering as a result of an attack on the personal device rather than on the ballot submission application itself" ⁷. Strong authentication does not protect against a compromised endpoint after sign-in.

Polling place equipment

VVSG 2.0 sets hardware-relevant principles for official voting systems: physical security ("prevents or detects attempts to tamper with voting system hardware" and "only exposes physical ports and access points that are essential to voting operations"), system integrity ("maintains and verifies the integrity of software, firmware, and other critical components" and requires that updates be "authorized by an administrator prior to installation"), access control with "least privilege and separation of duties" and revocation of access "when no longer required," and data protection in which "all cryptographic algorithms are public, well-vetted, and standardized" ⁴. VVSG 2.0 does not permit external network connections within the voting system ⁴.

Supply chain

NIST's supply chain guidance, SP 800-161 Revision 1 (May 2022, updated November 2024), opens with organizations' concern about "products and services that may potentially contain malicious" functionality, or be counterfeit or vulnerable because of weak manufacturing and development practices, and notes their limited insight into how acquired technology is built and secured ⁸. A device is only as trustworthy as its manufacturing, firmware signing, update channel, and custody.

Validated modules and what validation means

NIST's Cryptographic Module Validation Program, a joint effort with the Canadian Centre for Cyber Security, validates cryptographic modules to FIPS 140-3 ⁶. Validation concerns a cryptographic module. It is not an evaluation of an election system, its procedures, or its secrecy properties.

A national example of hardware tokens

Estonia's internet voting uses "an ID-card, Mobile-ID, Smart-ID, or digital identity document with valid certificates and PIN codes" ⁹. Its election authority still treats credential handover as a legal matter: "transfer of ID-card and its codes is prohibited" ¹⁰. Hardware tokens do not remove the need for law and enforcement.

Competing interpretations

Hardware as the answer versus hardware as one control. One view holds that modern secure hardware, combined with biometrics, makes remote voting safe. The evidence above shows narrower benefits: protected keys and phishing resistance, but no protection against endpoint malware after sign-in, coercion, or eligibility fraud ^{1 7}.

Attestation for assurance versus attestation for privacy. A relying party could require attestation to accept only certain authenticator models. That raises assurance, but it can exclude people with older or cheaper devices and reveal device details. This framework treats attestation as a design question for a future official layer, not a default.

Central keys versus distributed keys. HSMs can protect election keys centrally, but concentrate trust in their operators. Threshold designs spread keys across parties, at the cost of complexity. This page does not prescribe a protocol; any choice would need public cryptographic review, consistent with VVSG's requirement for public, well-vetted algorithms ⁴.

Application to this framework

1. The website. Readers need no special device. Administrator accounts use multi-factor authentication.
2. The demo. The demo uses passkeys where supported, with recovery codes, and never receives a fingerprint or face image. It does not require any particular device. Because passkeys are scoped to a site, a demo passkey is not a voting credential and does not work elsewhere ³.
3. Future official layer, research requirements only. A future assurance case would need to address: key custody and separation of duties; hardware-backed credentials and the limits of attestation; secure boot and signed updates through a reviewed supply chain ^{5 8}; compromise of an authenticated endpoint ⁷; lost-device recovery and revocation that cannot be abused by a coercer or an insider; physical custody and tamper evidence for polling place equipment ⁴; protected signing keys, possibly in validated HSMs ⁶; and accessible alternatives for people who cannot use a given device. None of this is built, and no hardware choice substitutes for legal authority or independent review.
4. No custom cryptography. The framework does not propose a new cryptographic protocol. See audits and verification and security.

Unresolved questions

• How can lost-device recovery be safe against a coercer who controls the voter's other accounts?
• Should a future official channel require device attestation, and how many eligible voters would that exclude?
• How would assisted access work for a voter who cannot operate a device alone, without giving the assistant control of the credential? See access and exclusion.
• What evidence would show that a personal device was not compromised at the moment of voting? No current standard cited here provides that.