UOCAVA PILOT 

PROGRAM TESTING 

REQUIREMENTS 

Uniformed and Overseas 

Citizens Absentee Voting Act 

Pilot Program Testing 

Requirements 

AUGUST 25, 2010
Table of Contents 

Section 1: Overview .............................................................................................................................5

1.1 Background .............................................................................................................................5

1.2 EAC Certification Scope for UOCAVA Pilot Systems .............................................................9

1.3 Conformance Clause.............................................................................................................11

1.4 Effective Date ........................................................................................................................16

Section 2: Functional Requirements ..................................................................................................17

2.1 Accuracy................................................................................................................................17

2.2 Operating capacities..............................................................................................................20

2.3 Pre-Voting Capabilities..........................................................................................................21

2.4 Voting Capabilities.................................................................................................................22

2.5 Post Voting Capabilities ........................................................................................................24

2.6 Audit and Accountability........................................................................................................26

2.7 Performance Monitoring........................................................................................................29

Section 3: Usability, Accessibility, and Privacy Requirements ..........................................................31

3.1 Overview................................................................................................................................31

3.2 General Usability ...................................................................................................................32

3.3 Accessibility requirements.....................................................................................................38

Section 4: Software............................................................................................................................46

4.1 Selection of Programming Languages ..................................................................................46

4.2 Selection of General Coding Conventions ............................................................................46

4.3 Software Modularity and Programming.................................................................................47

4.4 Structured Programming .......................................................................................................47

4.5 Comments .............................................................................................................................48

4.6 Executable Code and Data Integrity .....................................................................................49

4.7 Error Checking.......................................................................................................................49

4.8 Recovery ...............................................................................................................................52

4.9 Source Code Review.............................................................................................................54

Section 5: Security .............................................................................................................................56

5.1 Access Control ......................................................................................................................56

5.2 Identification and Authentication ...........................................................................................59

5.3 Cryptography.........................................................................................................................62

5.4 Voting System Integrity Management ...................................................................................65

5.5 Communications Security......................................................................................................66

5.6 Logging..................................................................................................................................68

5.7 Incident Response.................................................................................................................73

5.8 Physical and Environmental Security....................................................................................74

5.9 Penetration Resistance .........................................................................................................77

Section 6: Quality Assurance.............................................................................................................80

6.1 General Requirements ..........................................................................................................80

6.2 Components from Third Parties ............................................................................................80

6.3 Responsibility for Tests .........................................................................................................80

6.4 Parts and Materials, Special Tests, and Examinations.........................................................81

6.5 Quality Conformance Inspections .........................................................................................81

Section 7: Configuration Management...............................................................................................82

7.1 Scope ....................................................................................................................................82

7.2 Configuration Identification....................................................................................................82

7.3 Baseline and Promotion Procedures.....................................................................................83

7.4 Configuration Control Procedures.........................................................................................83

7.5 Configuration Audits ..............................................................................................................84

Section 8: Technical Data Package ...................................................................................................86

8.1 Scope ....................................................................................................................................86

8.2 Implementation Statement ....................................................................................................88

8.3 System Hardware Specification ............................................................................................88

8.4 Application Logic Design and Specification ..........................................................................90
8.5 System Security Specification.............................................................................................102

8.6 Test Specifications ..............................................................................................................109

8.7 Configuration for Testing.....................................................................................................110

Section 9: System Users Manual.....................................................................................................112

9.1 Scope ..................................................................................................................................112

9.2 System Overview.................................................................................................................112

9.3 System Functionality Description ........................................................................................114

9.4 System Security Specification.............................................................................................115

9.5 Software ..............................................................................................................................117

9.6 Setup Inspection..................................................................................................................119

9.7 System Operations Manual.................................................................................................122

9.8 System Maintenance Manual..............................................................................................127

9.9 Personnel Deployment and Training Requirements ...........................................................130

Appendix A: Glossary ..........................................................................................................................132

Appendix B: List of References ...........................................................................................................136

Appendix C: Accuracy Test Case........................................................................................................142
Intentionally left blank 
1.1 Background 

Section 1: Overview 

1.1 Background 

1.1.1 UOCAVA Pilot Projects 

The Uniformed and Overseas Citizens Absentee Voting Act (UOCAVA) of 1986 

protects the right to vote in federal elections for this defined category of citizens. 

UOCAVA sets out federal and state responsibilities to assist these voters in 

exercising their voting rights. The Secretary of Defense is the presidential designee 

responsible for the federal functions of the Act. The Federal Voting Assistance 

Program (FVAP) administers this law on behalf of the Secretary of Defense and 

works cooperatively with other federal agencies and state and local election officials 

to carry out its provisions. 

UOCAVA legislation was enacted before the advent of today’s global electronic 

communications technology. Consequently it relied on U.S. domestic and military 

mail systems as well as foreign postal systems for the worldwide distribution of 

election materials. By the mid-1990s it became apparent that the mail transit time and 

unreliable delivery posed significant barriers for many UOCAVA citizens, preventing 

them from successfully exercising their right to vote. At the same time the Internet 

was being widely adopted by businesses, governments and the general public. 

Therefore it was a natural development for FVAP and states to consider the potential 

of the Internet as an alternative to the “by-mail” UOCAVA process. 

FVAP sponsored Voting Over the Internet (VOI), a small pilot project for the 

November 2000 general election, to examine the feasibility of using Internet 

technology. Four states participated in this experiment, which enabled voters to use 

their own personal computers to securely register to vote, request and receive 

absentee ballots, and return their voted ballots. Following the successful completion 

of the VOI project, in the Fiscal Year 2002 National Defense Authorization Act (§1604 

of P.L. 107-107:115 Stat.1277), Congress instructed the Secretary of Defense to 

carry out a larger demonstration project for the November 2002 general election. This 

project was to be “carried out with participation of sufficient numbers of absent 

uniformed services voters so that the results are statistically significant”. 

Since there was not sufficient time to define and implement a large project for 2002, 

the project was planned for implementation for the November 2004 election. Seven 

states agreed to participate and worked with FVAP to develop system requirements 

and operating procedures. However, the Secure Electronic Registration and Voting 

Experiment (SERVE) was cancelled before it was deployed due to concerns raised 

by several computer scientists. These individuals contended that the use of personal 

computers over the Internet could not be made secure enough for voting and 

consequently called for the project to be terminated. The Department of Defense, 

citing a lack of public confidence in the SERVE system, decided the project could not 

continue under these circumstances. 

In response to this development, the Fiscal Year 2005 National Defense 

Authorization Act (§567 of P.L. 108-375;118 Stat.119) repealed the requirement for 

the Secretary of Defense to conduct an electronic voting demonstration project “until 

the first regularly scheduled general election for federal office which occurs after the 

Election Assistance Commission (EAC) notifies the Secretary that the Commission 

has established electronic absentee voting guidelines and certifies that it will assist 

Section 1 | Page 5
1.1 Background 

the Secretary in carrying out the project”. Pursuant to this legislation, in September 

2005, the EAC requested its voting system advisory group, the Technical Guidelines 

Development Committee (TGDC), to add this subject on their research agenda; 

however the request was declined. This effectively put all federally-sponsored 

projects involving electronic return of voted ballots on indefinite hold. 

After the cancellation of the SERVE Project in 2004, FVAP developed and fielded the 

Interim Voting Assistance System (IVAS). This system provided for electronic 

submission of ballot requests and delivery of blank ballots using a Department of 

Defense secure server. The voter was notified by email when their ballot was 

available on the server. Then they could download and print the ballot, mark their 

selections and return the voted ballot by postal mail or facsimile, if their state 

permitted this option. Use of this system was restricted to voters enrolled in the 

Defense Enrollment Eligibility Reporting System (DEERS), which was the source for 

voter identification validation. A total of 108 counties in 9 states participated in this 

project. One hundred forty-nine voters submitted ballot requests and 17 voters 

received blank ballots. 

In 2006 the capabilities of IVAS were extended to enable all UOCAVA voters to use 

the system for submitting ballot requests. This was used by 470 jurisdictions in 8 

states. FVAP could not measure how many voters used this option. As in 2004, 

voters in the DEERS database could also receive blank ballots using the system. 

This capability was used by 103 jurisdictions in 3 states. Sixty-three voters submitted 

ballot requests and 29 downloaded blank ballots. 

In 2008 IVAS was further modified to enable all UOCAVA voters to make ballot 

requests and receive blank ballots. This enhanced capability was called the Voter 

Registration/Ballot Delivery System. It was used by 45 jurisdictions in 11 states. Over 

21,000 voters completed a ballot request form and 780 uploaded these forms to the 

system. One hundred twenty-four voters downloaded blank ballots. 

Since the State of Florida conducts its own voting system certification process, 

Okaloosa County, Florida, decided to field a small pilot for the 2008 general election 

that would enable voters to return their voted ballots electronically. Okaloosa County 

set up staffed remote electronic voting locations called “kiosks” in England, Germany 

and Japan. These sites were equipped with vote capture devices connected by a 

secure communications link to a system server. Voters came to the site and used the 

vote capture devices to receive, mark and cast their ballots electronically. The cast 

ballots were encrypted and transmitted back to the system server where they were 

stored until the Okaloosa Canvassing Board was ready to decrypt and tabulate them 

at the close of the election. The kiosk workers who staffed these sites verified voter 

identity and eligibility using an on-line connection to the voter registration system. A 

paper record of each vote was printed and used to verify the electronic results when 

the votes were tabulated. Ninety-three voters cast their ballots using this system. 

Also in 2008 the Arizona Secretary of State’s office developed and implemented a 

web-based system to enable voters to securely return their voted ballots 

electronically. This system, called the Military and Overseas Voting System, is still 

operational. Voters can request to register to vote and/or request an absentee ballot. 

When a request is received, an email is sent to the voter’s jurisdiction with the voter’s 

information to prompt the local election office to send a Federal Post Card Application 

and/or an absentee ballot. Ballots are sent to the voter by postal mail, email or 

facsimile. The local election office also authorizes the voter to use the Military and 

Overseas Voting System to return their voted ballot. An email is generated by the 

system that provides the voter with instructions for returning their ballot and a 

password. When they receive the ballot, the voter marks their selections and scans 

the ballot image into a computer file. Then they log onto the system and upload the 

voted ballot. The system sends an email to the voter to confirm that the ballot was 

Section 1 | Page 6
1.1 Background 

received. The appropriate county official also receives an email that a ballot has been 

received so they can download it for processing and tabulation. 

1.1.2 Testing Pilot Systems 

Most states require voting systems to undergo a testing and certification process 

before the system may be used in an election. This provides a level of assurance that 

the system provides the required functionality and operates reliably and securely. 

The four states participating in the VOI project agreed to test that system utilizing the 

Department of Defense Information Technology Security Certification and 

Accreditation (DITSCAP) process combined with the State of Florida Division of 

Elections Voting Systems Certification process. The testing regimen planned for the 

SERVE system was a combined DITSCAP, National Association of State Election 

Directors (NASED), and State of Florida certification and accreditation process. The 

system used for Okaloosa County’s remote voting pilot was tested and certified by 

the State of Florida Division of Elections. 

Due to the nature of these new systems, existing voting system standards were not 

sufficient for testing specific aspects. Therefore, additional security requirements 

were needed to test the use of digital signatures, cryptography and secure 

communications protocols. The hardware and software standards, developed for 

DRE and optical scan systems used in polling places, also needed to be revised to 

reflect the characteristics of the remote voting technologies. Each of these pilot 

projects established a working group, comprised of election officials, security experts 

and test engineers, to define the additional requirements needed to supplement the 

existing voting system standards. Reference materials for the working groups came 

from various national and international sources of information technology standards, 

such as the Federal Information Processing Standards (FIPS), Common Criteria, and 

the International Standards Organization. These efforts resulted in testing 

requirements documents that were specific to the technical features of each of the 

pilot systems, which supplied the criteria for testing and certifying these particular 

pilot systems. 

Since 2008, several states have enacted legislation enabling them to conduct 

electronic voting projects for UOCAVA voters, beginning with the 2010 elections. To 

be prepared to support the states with these projects, in July 2009 the EAC 

convened a UOCAVA Working Group to consider how to adapt the EAC’s Testing 

and Certification Program to accommodate UOCAVA pilot systems. It was concluded 

that two products were needed: a modified set of system testing requirements; and a 

revised testing and certification process. It was determined that the working group 

would assist the EAC in drafting the testing requirements. The EAC staff would adapt 

the certification process to accommodate the needs of UOCAVA pilot projects and 

publish a Voting System Pilot System Testing and Certification Manual. 

The EAC UOCAVA Working Group began with a review of the Voluntary Voting 

System Guidelines (VVSG) 2005; the Revision to the 2005 VVSG; and the Next 

Iteration to the VVSG to identify already established or proposed TGDC guidelines 

that would also apply to remote electronic voting systems. To fill gaps related to the 

introduction of technologies not covered in the VVSG and the additional security 

requirements associated with remote systems, VOI, SERVE and Okaloosa Project 

requirements documents were reviewed. In addition, FIPS and NIST Special 

Publications were consulted to identify federally specified information security 

requirements that would apply to the use of cryptography, public key infrastructure, 

secure communications and other security features of remote electronic voting 

systems. 

Section 1 | Page 7
1.1 Background 

 A significant challenge for the EAC Working Group was to specify requirements that 

would not unduly constrain innovation in the design of UOCAVA systems. The VOI, 

SERVE and Okaloosa system testing requirements were tailored to test the particular 

system implementations developed for those projects. However, since many different 

designs for remote voting systems could be submitted to the EAC certification 

program, the EAC Working Group needed to identify generic system requirements to 

allow for system design flexibility. This document is the result of that effort. 

1.1.3 Scope of EAC Pilot Project Testing Requirements 

Pilot projects are small in scale and short in duration. Consequently, certification for 

pilot systems needs to be quicker and less expensive than the regular process 

currently used for conventional systems with an expected life of more than 10 years. 

Nevertheless, since actual votes will be cast on the pilot voting systems, the 

certification process must retain sufficient rigor to provide reasonable assurance that 

these systems will operate correctly and securely. 

There is a fundamental dichotomy in complexity in remote voting system 

architectures: those where the vote capture device is controlled (e.g., provided by the 

election jurisdiction); and those where it is not controlled (e.g., the voter uses his own 

personal computer). Since the EAC planned to have the pilot certification process 

ready for implementation during the first half of 2010, it was decided that the EAC 

would focus its efforts on controlled platform architectures servicing multiple 

jurisdictions. This is a highly secure remote voting solution and the Okaloosa Project, 

which used remote kiosks with vote capture devices provided by the Supervisor of 

Elections office, provides an implementation example for reference. Defining 

requirements for this class of system architecture was determined to provide a 

reasonable test case that could be completed within the available timeframe. In 

addition, most of the core system processing functions are the same for both types of 

architectures, so a substantial number of requirements will carry over as this work is 

expanded by the TGDC to include other methods of remote electronic voting. This 

pilot testing requirements document will be provided to the TGDC as the basis and 

starting point for their research and deliberations. 

1.1.4 Next Steps 

While the EAC was working to ensure that the pilot certification effort was underway, 

legislation dealing with a number of UOCAVA voting issues was under consideration 

by Congress. Ultimately passed as part of the Fiscal Year 2010 National Defense 

Authorization Act (NDAA) (§581 of P.L. 111-84), the Military and Overseas Voters 

Empowerment Act contains a provision allowing the Secretary of Defense to 

establish one or more pilot programs to test the feasibility of new election technology 

for UOCAVA voters. This provision requires the EAC and the National Institute of 

Standards and Technology (NIST) to provide best practices or standards to support 

these pilot programs, “in accordance with electronic absentee voting guidelines 

established under” the earlier FY2005 NDAA. In December 2009, the EAC directed 

the TGDC to begin this work as a top research priority. The EAC expects the TGDC 

to make recommendations for the comprehensive set of remote electronic voting 

system guidelines mandated by the FY2005 NDAA. The TGDC has been tasked to 

consider the full range of remote voting architectures, including instances where the 

voter uses his own personal computer for voting. 

Section 1 | Page 8
1.2 EAC Certification Scope for UOCAVA Pilot Systems 

1.2 EAC Certification Scope for UOCAVA Pilot Systems 

An initial step in a system certification process is to define the boundaries of the system 

that will be tested and certified. There are several significant differences between 

UOCAVA remote electronic voting systems and conventional voting systems used in 

polling places. UOCAVA pilot systems operate as adjuncts to existing election 

administration systems in the participating jurisdictions. Pilot systems require election 

definition data from the local Election Management System (EMS) to set up the system 

for the election and define ballots. Information from the Statewide Voter Registration 

Database is needed to authenticate voters and determine their eligibility to vote, match 

them with the correct ballot style, and record voter history. Some processes that are 

handled procedurally in a polling place may be performed by a software application in a 

remote electronic system. Use of communications networks is necessary to connect to 

voters. Since the UOCAVA voting period currently extends for 45 days, pilot systems may 

be in operation for several weeks before polling place systems are activated for Election 

Day. Most, if not all, states prohibit tabulation of absentee ballots until after the polls are 

closed, so voted ballots may have to be stored on the system for several weeks. Pilot 

tabulation results will be integrated with the tabulation report generated by the local EMS. 

Consequently, there are many factors to consider when determining the scope for pilot 

system certification testing. 

Figure 1-1 illustrates a generic process flow for remote electronic voting that does not 

presuppose any particular architectural solution. Even at this high level of abstraction, 

two alternative processing paths are needed to accommodate differences in individual 

state requirements. The first path, called the absentee model, has two distinguishing 

features. This is essentially an electronic rendering of the UOCAVA by-mail process. In 

this path, the voter’s identity must remain linked to the cast ballot until the close of the 

voting period. At that time adjudication is made by the local jurisdiction on whether to 

accept or not accept the ballot. If the ballot is accepted, any identifiable link to the voter is 

removed. The now anonymous ballot is placed in the ballot box to be tabulated. If the 

ballot is rejected, the link is not removed and the disposition of the ‘unopened’ ballot is 

made in accordance with individual state procedures. 

The second path, called the early voting model, does not maintain any association 

between the voter and the cast ballot. When the voter presses the ‘Vote’ button and 

receives notification that their ballot selections have been recorded, the ballot goes 

directly into the ballot box. There is no ballot adjudication step and therefore no need to 

maintain a connection between the voter and the ballot. 

There are many of ways in which systems can be designed to perform these absentee 

functions. However, for the reasons discussed in 1.1.3, only one type of system 

architecture – kiosk-based remote voting -- is addressed in this document. There are four 

major components in kiosk-based voting systems: 

1. A system server which runs the voting software, stores voted ballots, and 

provides system administration functions; 

2. One or more kiosks which are designated remote locations that service multiple 

election jurisdictions are staffed by kiosk workers who verify voter identity and 

eligibility, and are equipped with electronic vote capture devices with printing 

capability. 

3. A tabulation device at each participating local election office which decrypts and 

tabulates the ballots for that jurisdiction; and 

4. Communications links which tie all the system components together. 

For security purposes, no vote data is permanently retained by the vote capture device. 

The cast ballot is transmitted to an electronic ballot box stored on the system server. The 

Section 1 | Page 9
1.2 EAC Certification Scope for UOCAVA Pilot Systems 

vote capture device produces a paper record of the voter’s choices that the voter can 

review for verification purposes. The paper records will be deposited in a secure 

receptacle and returned to the appropriate jurisdiction for system audit purposes. Other 

elements of the system architecture are not specified. 

All the system components supporting the functions inside the frame in Figure 1-1 are 

subject to EAC pilot certification testing. Any system submitted to the EAC for pilot 

certification must support both the absentee and early voting models. The interfaces 

between the pilot system and the local EMS are not included in EAC testing. Should a 

pilot jurisdiction decide to develop a software wizard or other automated method to move 

data between the EMS and the pilot system, that jurisdiction will be responsible for 

validating that element. Similarly, if a jurisdiction decides to provide an automated means 

for kiosk workers to access voter registration data to validate voter identity and eligibility, 

the jurisdiction will be expected to validate its performance. 

It is important to bear in mind that, although kiosk-based remote electronic voting may 

appear to be very similar to poll site voting, there are some very significant differences in 

the underlying legislative basis and the policies and procedures that flow from that. 

UOCAVA voting is by definition absentee voting. The process employed in UOCAVA 

voting pilots follows the same rules as the conventional postal delivery process. This 

means that the voting period could begin 45 days or more before Election Day, 

depending on state law. If some event, such as a law suit or an accident, causes a 

change in candidates in a race after the UOCAVA voting period begins, there must be a 

defined protocol for how to count that race in ballots that have already been cast if those 

voters don’t have an opportunity to vote again with a replacement ballot. Since kiosks 

could be located in many different time zones, the system server hosting the voting 

application has to be available essentially 24 hours a day, seven days a week. Therefore, 

the electronic voting process would most likely have to be interrupted to change the ballot 

definition data and rerun logic and accuracy testing. Since this is an absentee voting 

process, provisional ballots are not available. For the same reason, there are no legallymandated accessibility requirements. For those states following the absentee model of 

UOCAVA voting described above, there is a formal process to decide whether or not to 

accept a ballot for counting. Consequently, UOCAVA system requirements will vary 

somewhat from those for poll site systems. 

Section 1 | Page 10
1.3 Conformance Clause 

Figure 1-1 UOCAVA Process 

1.3 Conformance Clause 

1.3.1 Scope and Applicability 

This document defines requirements for conformance of kiosk-based remote 

electronic voting systems, intended for use in UOCAVA pilot programs, that 

manufacturers of such systems SHALL meet pursuant to EAC pilot program 

Section 1 | Page 11
1.3 Conformance Clause 

certification. As described in 1.2, these systems consist minimally of a system server 

connected through secure communications links to a number of staffed remote kiosk 

locations equipped with vote capture devices. The vote capture devices display the 

ballot data provided by the system server to the voter and capture the electronic 

record of voter choices. These choices are securely transmitted back to the server for 

storage when the ballot is cast. The vote capture device also prints a paper record 

for voter verification which is retained for use in system performance validation. The 

system server is also connected through secure communications links to each 

participating local election jurisdiction to transfer the encrypted ballot file at the close 

of the election period. This file is manually transferred to a standalone, air-gapped 

tabulation device which decrypts and tabulates the ballots. The functionality of each 

of these components and the integrated system functional performance and security 

features will be tested during the certification process. 

EAC pilot system certification testing will not include pilot system linkages to local 

voter registration and election management systems except for defined data 

interchange interfaces. It is the responsibility of the participating state and local 

jurisdictions to validate the functionality of any connections to their local systems. It 

should also be noted that these testing requirements only relate to the performance 

of system hardware and software, they do not extend to election administration 

procedures. However, requirements are included for system documentation and the 

ability to produce data needed to support procedures such as system audit. 

This document also provides the framework, procedures, and requirements that 

voting system testing labs (VSTLs) and manufacturers responsible for the 

certification testing of such pilot program systems SHALL follow. The requirements 

and procedures in this document may also be used by states to certify kiosk-based 

remote electronic voting systems for their own pilot programs. 

This document defines the minimum requirements for remote electronic voting 

systems in the context of pilot programs conducted by states and local jurisdictions 

and the process for testing these systems. The requirements are intended for use by: 

 Designers and manufacturers of voting systems; 

 VSTLs performing the analysis and testing of systems in support of the EAC 

certification process; 

 Election officials, including officials responsible for the installation, operation, 

and maintenance of voting systems for UOCAVA pilot programs; and 

 VSTLs and consultants performing the state certification of voting systems 

for pilot programs. 

Minimum requirements specified in this document include: 

 Functional capabilities; 

 Performance characteristics, including security; 

 Documentation; and 

 Test evaluation criteria. 

1.3.2 Conformance Framework 

This section provides the framework in which conformance is defined. It identifies the 

entities to which these requirements apply, the relationships among the various 

entities, the structure of the requirements, and the terminology used to indicate 

conformance. 

Section 1 | Page 12
1.3 Conformance Clause 

1.3.2.1 Applicable entities 

The requirements, prohibitions and options specified in these requirements apply to 

kiosk –based remote electronic voting systems, voting system manufacturers, and 

VSTLs. These requirements apply to all systems submitted for pilot certification 

under the EAC program. 

1.3.2.2 Requirements of entities 

It is the voting system manufacturer that must implement these requirements and 

provide the necessary documentation for the system. In order to claim 

conformance to the requirement, the voting system manufacturer SHALL satisfy 

the specified requirements. The voting system manufacturer SHALL successfully 

complete the prescribed test campaign with an EAC VSTL in order to obtain EAC 

certification. 

The VSTL SHALL satisfy the requirements for conducting pilot program certification 

testing. Additionally, as indicated in the document, certain requirements SHALL be 

tested by the manufacturer rather than the VSTL. The VSTL may use an 

operational environment emulating that used by election officials as part of their 

testing to ensure that the voting system can be configured and operated in a 

secure and reliable manner according to the manufacturer’s documentation and as 

specified by the requirements. The VSTL SHALL coordinate and deliver the 

requisite documentation, including a Test Plan and a Test Report, to the EAC for 

review and approval. 

The EAC SHALL review the test results and associated documentation from both 

the VSTL and the manufacturer and make a determination that all requirements 

have been appropriately tested and the test results are acceptable. The EAC may 

conduct audits of manufacturer testing to ensure its adequacy. The EAC will issue 

a pilot program certification number that indicates conformance of the specified 

system to these requirements. 

1.3.3 Extensions 

Extensions are additional functions, features, and/or capabilities included in a voting 

system that are not required by this document. To accommodate the needs of states 

that may impose additional requirements and to accommodate changes in 

technology, this document allows extensions. The use of extensions SHALL NOT 

contradict nor cause the nonconformance of functionality required by this document. 

1.3.4 Implementation Statement 

The implementation statement SHALL describe the remote electronic voting system 

and SHALL document the requirements that have been implemented by the voting 

system. It SHALL also identify optional features and capabilities supported by the 

voting system, as well as any extensions (i.e., additional functionality beyond what is 

required in this document). The implementation statement SHALL include a checklist 

identifying all the requirements for which a claim of conformance is made. 

The implementation statement SHALL be submitted with the manufacturer’s 

application to the EAC for pilot program certification testing. It SHALL provide a 

concise summary and narrative description of the voting system’s capabilities. It 

SHALL include identifying information about the voting system, including the 

hardware and software components, version number and date. 

Section 1 | Page 13
1.3 Conformance Clause 

1.3.5 Equivalent Configurations 

1.3.5.1 Background 

Under the standard EAC certification program, the scope of certification is very 

specific and extends only to the exact voting system configuration tested. The 

certificate specifically identifies each of the various configurations of the voting 

system’s components that were tested and certified, including the Operating 

System (OS) version and service pack, as well as the Central Processing Unit 

(CPU). Any modification to the system not authorized by the EAC will void the 

certificate. The certificate is applicable to the system configuration that has been 

tested during certification and is not applicable when any modification to hardware, 

software or COTS products has occurred. 

There is a tradeoff between requiring the exact configuration that was tested and 

certified to be deployed and allowing “equivalent configurations” that have been 

tested by the voting system manufacturer and attested to perform identically on 

these configurations. Requiring only exact configurations that have been certified to 

be deployed guarantees that the customer is using the identical system that has 

been tested by the VSTL, but does not allow the flexibility needed to accommodate 

routine and expected changes to Commercial Off the Shelf (COTS) systems. The 

requirements in this document are designed to allow for such flexibility. 

1.3.5.2 Procedures for changes to baseline configuration 

Testing for UOCAVA Pilot Certification is conducted by the VSTL and voting 

system manufacturer on the baseline configuration consisting of: 

1. Specific hardware; 

2. Major Version of operating system and third-party COTS applications. 

 Major Versions are changed when an updated version is 

downloaded; major versions are not considered changed when a 

patch is applied to fix an individual item. 

 In Microsoft Operating Systems, Major Versions would include 

Service Packs– New Service Packs would be considered a 

different Major Version. 

 Downloading patches (i.e., security) would not be considered a 

change to the Major Version. However, manufacturers SHALL 

create a log of all patches downloaded and supply them to the 

EAC upon request. 

Any change to hardware or software (Major Versions) SHALL be regression tested 

by the voting system manufacturer to ensure that all requirements affected by the 

change have been adhered to. Regression testing SHALL be documented and 

legally affirmed to by the manufacturer, and accepted by the EAC. Regression 

testing SHALL be done by the manufacturer when the EAC certified version differs 

from the one being deployed in any of the following ways: 

a. Any hardware is changed. However, de minimis changes, as defined in 

the EAC Pilot System Certification Manual, SHALL NOT undergo 

regression testing; 

b. Any change to Major Version of the OS is made; and 

c. Any major change to a third-party COTS application is made. 

Section 1 | Page 14
1.3 Conformance Clause 

All regression testing by manufacturers SHALL include accuracy and reliability 

testing. Other tests SHALL be repeated for requirements closely related to the 

functionality that was modified with the hardware or software (Major Version) 

changes. 

Any change to the voting system application not covered by 3 a, b or c SHALL 

undergo testing by the VSTL. 

Test Reports describing the manufacturer regression testing SHALL be submitted 

to the EAC. The EAC may conduct random audits to ensure that the manufacturer 

regression testing performed was sufficient. 

1.3.6 Requirements Language and Structure 

1.3.6.1 Language 

Understanding how language is used is a pre-requisite to understanding this 

document. Language in this document is divided into two categories: normative, 

i.e., the requirements language itself, and informative. Normative language is 

prescriptive and must be followed to obtain conformance to this document and 

ultimately EAC certification. Informative parts of this document include discussion, 

examples, extended explanations, and other matter that are necessary for proper 

understanding of the requirements and how to ensure conformance. Informative 

text is not prescriptive and serves to clarify requirements. 

Normative language is specifically for requirements. The following keywords are 

used within requirements text to indicate the conformance aspects of the 

requirement: 

 SHALL indicates a mandatory requirement to do something; 

 SHALL NOT indicates a mandatory requirement not to do something. 

1.3.6.2 Structure of requirements 

Each remote electronic voting system requirement in this document is identified 

according to a hierarchical scheme in which higher-level requirements (e.g., "The 

requirements for formatting the TDP are general in nature; specific format details 

are of the manufacturer's choosing.") are supported by lower-level requirements 

(e.g., " The TDP SHALL include a detailed table of contents for the required 

documents, an abstract of each document, and a listing of each of the informational 

sections and appendices presented."). Thus, requirements are nested. When the 

nesting hierarchy has reached four levels (i.e., 1.1.1.1), further nested 

requirements are designated with lowercase letters, then Roman numerals. 

Therefore, all requirements are traceable by a distinct reference. 

Some requirements are directly testable and some are not. Lower-level 

requirements (i.e., leaf-node requirements that have no requirements directly 

beneath them) are directly testable. Higher-level requirements (i.e., requirements 

with directly testable requirements beneath them) are not directly testable. Higherlevel requirements are included because: (1) they are testable indirectly insofar as 

their lower-level requirements are testable; and (2) they often provide the structure 

and rationale for the lower level requirements. Satisfying all the lower-level 

requirements will result in satisfying the corresponding higher-level 

requirement. Thus, VSTLs need to only directly test lower-level requirements, not 

higher-level requirements. However, if non-conformance with a higher-level 

requirement is determined through any other means (e.g., OEVT testing, 

inspection) then the voting system is deemed not to conform to that higher-level 

requirement. 

Section 1 | Page 15
1.4 Effective Date 

1.4 Effective Date 

The UOCAVA Pilot Program Testing Requirements SHALL become effective for pilot 

certification testing upon adoption by the EAC. At that time, all kiosk-based remote 

electronic pilot systems submitted for EAC certification SHALL be tested for conformance 

with these requirements. 

These requirements are voluntary in that each of the states can decide whether to require 

the voting systems used in pilot programs for their state to have an EAC certification. 

States may decide to adopt these requirements in whole or in part at any time, 

irrespective of the effective date. In addition, states may specify additional requirements 

that pilot voting systems used in their jurisdictions must meet. The EAC certification 

program does not, in any way, pre-empt the ability of the states to have their own voting 

system certification process. 

Section 1 | Page 16
2.1 Accuracy 

Section 2: Functional Requirements 

2.1 Accuracy 

Voting system accuracy addresses the accuracy of data for each of the individual ballot 

selections that could be selected by a voter, including the positions that are not selected. 

Accuracy is defined as the ability of the voting system to capture, record, store, 

consolidate and report the specific selections and absence of selections, made by the 

voter on each ballot without error. 

For each processing function in the following list, the voting system SHALL achieve a 

target error rate of no more than one in 10,000,000 ballot positions, with a maximum 

acceptable error rate in the test process of one in 500,000 ballot positions. Types of 

functions include: 

 Recording voter selections 

 Recording voter selections into ballot image storage independently from voting 

data storage; and 

 Consolidation of vote selection data from multiple voting sites to generate 

jurisdiction-wide vote totals. 

2.1.1 Components and Hardware 

2.1.1.1 Component accuracy 

Memory hardware, such as semiconductor devices and magnetic storage media, 

SHALL be accurate. 

Test Method: Functional 

Test Entity: VSTL 

2.1.1.2 Equipment design 

The design of equipment in all voting systems SHALL provide for protection against 

mechanical, thermal, and electromagnetic stresses that impact voting system 

accuracy. 

Test Method: Functional 

Test Entity: VSTL 

2.1.1.3 Voting system accuracy 

To ensure vote accuracy, all voting systems SHALL: 

a. Record the election contests, candidates, and issues exactly as defined by 

election officials; 

b. Record the appropriate options for casting and recording votes; 

Section 2 | Page 17
2.1 Accuracy 

c. Record each vote precisely as indicated by the voter and be able to 

produce an accurate report of all votes cast; 

d. Include control logic and data processing methods incorporating parity and 

check-sums (or equivalent error detection and correction methods) to 

demonstrate that the voting system has been designed for accuracy; and 

e. Provide software that monitors the overall quality of data read-write and 

transfer quality status, checking the number and types of errors that occur 

in any of the relevant operations on data and how they were corrected. 

Test Method: Functional 

Test Entity: VSTL 

2.1.2 Environmental Range 

All voting systems SHALL meet the accuracy requirements over manufacturer 

specified operating conditions and after storage under non-operating conditions. 

Test Method: Functional 

Test Entity: VSTL 

2.1.3 Content of Data Verified for Accuracy 

2.1.3.1 Election management system accuracy 

Voting systems SHALL accurately record all election management data entered by 

the user, including election officials or their designees. 

Test Method: Functional 

Test Entity: VSTL 

2.1.3.2 Recording accuracy 

For recording accuracy, all voting systems SHALL: 

a. Record every entry made by the user except where it violates voter 

privacy; 

b. Accurately interpret voter selection(s) and record them correctly to 

memory; 

c. Verify the correctness of detection of the user selections and the addition 

of the selections correctly to memory; 

d. Verify the correctness of detection of data entered directly by the user and 

the addition of the selections correctly to memory; and 

e. Preserve the integrity of election management data stored in memory 

against corruption by stray electromagnetic emissions, and internally 

generated spurious electrical signals. 

Test Method: Functional 

Test Entity: VSTL 

Section 2 | Page 18
2.1 Accuracy 

2.1.4 Telecommunications Accuracy 

The telecommunications components of all voting systems SHALL achieve a target 

error rate of no more than one in 10,000,000 ballot positions, with a maximum 

acceptable error rate in the test process of one in 500,000 ballot positions. 

Test Method: Functional 

Test Entity: VSTL 

2.1.5 Accuracy Test Content 

Voting system accuracy SHALL be verified by a specific test conducted for this 

objective. The overall test approach is described in Appendix C. 

2.1.5.1 Simulators 

If a simulator is used, it SHALL be verified independently of the voting system in 

order to produce ballots as specified for the accuracy testing. 

Test Method: Functional 

Test Entity: VSTL 

2.1.5.2 Ballots 

Ballots used for accuracy testing SHALL include all the supported types (i.e., 

rotation, alternative languages) of contests and election types (primary, general). 

Test Method: Functional 

Test Entity: VSTL 

2.1.6 Reporting Accuracy 

Processing accuracy is defined as the ability of the voting system to process stored 

voting data. Processing includes all operations to consolidate voting data after the 

voting period has ended. 

The voting systems SHALL produce reports that are consistent, with no discrepancy 

among reports of voting data. 

Test Method: Functional 

Test Entity: VSTL 

Section 2 | Page 19
2.2 Operating capacities 

2.2 Operating capacities 

2.2.1 Maximum Capacities 

The manufacturer SHALL specify at least the following maximum operating 

capacities for the voting system (i.e. server, vote capture device, tabulation device, 

and communications links): 

 Throughput, 

 Memory, 

 Transaction processing speed, and 

 Election constraints: 

o Number of jurisdictions 

o Number of ballot styles per jurisdiction 

o Number of contests per ballot style 

o Number of candidates per contest 

o Number of voted ballots 

Test Method: Functional 

Test Entity: VSTL 

2.2.1.1 Capacity testing 

The voting system SHALL achieve the maximum operating capacities stated by the 

manufacturer in section 2.2.1. 

Test Method: Functional 

Test Entity: VSTL 

2.2.2 Operating Capacity notification 

The voting system SHALL provide notice when any operating capacity is approaching 

its limit. 

Test Method: Functional 

Test Entity: VSTL 

2.2.3 Simultaneous Transmissions 

The voting system SHALL protect against the loss of votes due to simultaneous 

transmissions. 

Test Method: Functional 

Test Entity: VSTL 

Section 2 | Page 20
2.3 Pre-Voting Capabilities 

2.3 Pre-Voting Capabilities 

2.3.1 Import and Verify Election Definition 

2.3.1.1 Import the election definition 

The voting system SHALL: 

a. Keep all data logically separated by, and accessible only to, the 

appropriate state and local jurisdictions; 

b. Provide the capability to import or manually enter ballot content, ballot 

instructions and election rules, including all required alternative language 

translations from each jurisdiction; 

c. Provide the capability for the each jurisdiction to verify that their election 

definition was imported accurately and completely; 

d. Support image files (e.g., jpg or gif) and/or a handwritten signature image 

on the ballot so that state seals, official signatures and other graphical 

ballot elements may be properly displayed; and 

e. Support multiple ballot styles per each local jurisdiction. 

Test Method: Inspection/Functional 

Test Entity: VSTL 

2.3.1.2 Protect the election definition 

The voting system SHALL provide a method to protect the election definition from 

unauthorized modification. 

Test Method: Functional 

Test Entity: VSTL 

2.3.2 Readiness Testing 

2.3.2.1 Voting system test mode 

The voting system SHALL provide a test mode to verify that the voting system is 

correctly installed, properly configured, and all functions are operating to support 

pre-election readiness testing for each jurisdiction. 

Test Method: Functional 

Test Entity: VSTL 

2.3.2.2 Test data segregation 

The voting system SHALL provide the capability to zero-out or otherwise segregate 

test data from actual voting data. 

Test Method: Functional 

Test Entity: VSTL 

Section 2 | Page 21
2.4 Voting Capabilities 

2.4 Voting Capabilities 

2.4.1 Opening the Voting Period 

2.4.1.1 Accessing the ballot 

The voting system SHALL: 

a. Present the correct ballot style to each voter; 

b. Allow the voting session to be canceled; and 

c. Prevent a voter from casting more than one ballot in the same election. 

Test Method: Functional 

Test Entity: VSTL 

 

2.4.2 Casting a Ballot 

2.4.2.1 Record voter selections 

The voting system SHALL: 

a. Record the selection and non-selection of individual vote choices; 

b. Record the voter's selection of candidates whose names do not appear on 

the ballot, if permitted under state law, and record as many write-ins as the 

number of candidates the voter is allowed to select; 

c. Prohibit the voter from accessing or viewing any information on the display 

screen that has not been authorized and preprogrammed into the voting 

system (i.e., no potential for display of external information or linking to 

other information sources); 

d. Allow the voter to change a vote within a contest before advancing to the 

next contest; 

e. Provide unambiguous feedback regarding the voter’s selection, such as 

displaying a checkmark beside the selected option or conspicuously 

changing its appearance; 

f. Indicate to the voter when no selection, or an insufficient number of 

selections, has been made for a contest (e.g., undervotes); 

g. Provide the voter the opportunity to correct the ballot for an undervote 

before the ballot is cast; 

h. Allow the voter, at the voter’s choice, to submit an undervoted ballot 

without correction. 

i. Prevent the voter from making more than the allowable number of 

selections for any contest (e.g., overvotes); and 

j. In the event of a failure of the main power supply external to the voting 

system, provide the capability for any voter who is voting at the time to 

complete casting a ballot, allow for the successful shutdown of the voting 

system without loss or degradation of the voting and audit data, and allow 

Section 2 | Page 22
2.4 Voting Capabilities 

voters to resume voting once the voting system has reverted to back-up 

power. 

Test Method: Functional 

Test Entity: VSTL 

2.4.2.2 Verify voter selections 

The voting system SHALL: 

a. Produce a paper record each time the confirmation screen is displayed; 

b. Generate a paper record identifier. This SHALL be a random identifier that 

uniquely links the paper record with the cast vote record; 

c. Allow the voter to either cast the ballot or return to the vote selection 

process to make changes after reviewing the confirmation screen and 

paper record; and 

d. Prompt the voter to confirm his choices before casting the ballot, signifying 

to the voter that casting the ballot is irrevocable and directing the voter to 

confirm his intention to cast the ballot. 

Test Method: Functional 

Test Entity: VSTL 

2.4.2.3 Cast ballot 

The voting system SHALL: 

a. Store all cast ballots in a random order; logically separated by, and only 

accessible to, the appropriate state/local jurisdictions; 

b. Notify the voter after the vote has been stored persistently that the ballot 

has been cast; 

c. Notify the voter that the ballot has not been cast successfully if it is not 

stored successfully, and provide clear instruction as to steps the voter 

should take to cast his ballot should this event occur; and 

d. Prohibit access to voted ballots until such time as state law allows for 

processing of absentee ballots. 

Test Method: Functional 

Test Entity: VSTL 

2.4.2.4 Ballot linking to voter identification 

2.4.2.4.1 Absentee model 

The cast ballot SHALL be linked to the voter’s identity without violating the 

privacy of the voter. 

Test Method: Functional 

Test Entity: VSTL 

Section 2 | Page 23
2.5 Post Voting Capabilities 

2.4.2.4.2 Early voting model 

The cast ballot SHALL NOT be linked to the voter’s identity. 

Test Method: Inspection 

Test Entity: VSTL 

2.4.3 Vote Secrecy 

2.4.3.1 Link to voter 

The voting system SHALL be capable of producing a cast vote record that does not 

contain any information that would link the record to the voter. 

Test Method: Functional 

Test Entity: VSTL 

2.4.3.2 Voting session records 

The voting system SHALL NOT store any information related to the actions 

performed by the voter during the voting session. 

Test Method: Functional 

Test Entity: VSTL 

2.5 Post Voting Capabilities 

2.5.1 Ballot Box Retrieval 

2.5.1.1 Seal and sign the electronic ballot box 

The voting system SHALL seal and sign each jurisdiction’s electronic ballot box, by 

means of a digital signature, to protect the integrity of its contents. 

Test Method: Functional 

Test Entity: VSTL 

2.5.1.2 Electronic ballot box retrieval 

The voting system SHALL allow each jurisdiction to retrieve its electronic ballot 

box. 

Test Method: Functional 

Test Entity: VSTL 

Section 2 | Page 24
2.5 Post Voting Capabilities 

2.5.1.3 Electronic ballot box integrity check 

The voting system SHALL perform an integrity check on the electronic ballot box 

verifying that it has not been tampered with or modified before opening. 

Test Method: Functional 

Test Entity: VSTL 

2.5.2 Tabulation 

2.5.2.1 Tabulation device connectivity 

The tabulation device SHALL be physically, electrically, and electromagnetically 

isolated from any other computer network. 

Test Method: Inspection 

Test Entity: VSTL 

2.5.2.2 Open ballot box 

The tabulation device SHALL allow only an authorized entity to open the ballot box. 

Test Method: Functional 

Test Entity: VSTL 

2.5.2.3 Absentee model 

2.5.2.3.1 Adjudication 

The tabulation device SHALL allow the designation of electronic ballots as 

“accepted” or “not accepted” by an authorized entity. 

Test Method: Functional 

Test Entity: VSTL 

2.5.2.4 Ballot decryption 

The tabulation device decryption process SHALL remove all layers of encryption 

and breaking all correlation between the voter and the ballot, producing a record 

that is in clear text. 

Test Method: Functional 

Test Entity: VSTL 

2.5.2.5 Tabulation report format 

The tabulation device SHALL have the capability to generate a tabulation report of 

voting results in an open and non-proprietary format. 

Test Method: Functional 

Section 2 | Page 25
2.6 Audit and Accountability 

Test Entity: VSTL 

2.6 Audit and Accountability 

2.6.1 Scope 

This section presents requirements for the voting system to provide the capability for 

conducting the types of system performance verifications listed below. The intention 

is to provide for independent verification of the agreement of the paper record and 

electronic tabulation results. These audits could be conducted on the entire set of 

records or on a sampling basis, depending on the preferences of state/local 

jurisdictions: 

a. Hand audit – Validation of electronic tabulation results via comparison with 

results of a hand tally of paper records; and 

b. Comparison of ballot images and the corresponding paper records. 

It should be noted that these audits are for the purpose of verifying system 

performance and are conducted independently from the election audits that many 

jurisdictions conduct to verify overall election results. It is expected that ballots cast 

on a UOCAVA pilot voting system will be included with ballots cast by all other means 

when audit samples are drawn for election results verification. 

2.6.2 Electronic Records 

In order to support independent auditing, a voting system SHALL be able to produce 

electronic records that contain the necessary information in a secure and usable 

manner. Typically, this includes records such as: 

 Vote counts; 

 Counts of ballots recorded; 

 Paper record identifier; 

 Event logs and other records of important events; and 

 Election archive information. 

The following requirements apply to records produced by the voting system for any 

exchange of information between devices, support of auditing procedures, or 

reporting of final results: 

a. Requirements for electronic records to be produced by tabulation devices; 

and 

b. Requirements for printed reports to support auditing steps. 

2.6.2.1 All records capable of being exported 

The voting system SHALL provide the capability to export its electronic records in 

an open format, such as XML, or include a utility to export log data into a publicly 

documented format. 

Test Method: Functional 

Section 2 | Page 26
2.6 Audit and Accountability 

Test Entity: VSTL 

2.6.2.2 Ballot images 

The voting system SHALL have the capability to generate ballot images in a human 

readable format. 

Test Method: Functional 

Test Entity: VSTL 

2.6.2.3 Ballot image content 

The voting system SHALL be capable of producing a ballot image that includes: 

a. Election title and date of election; 

b. Jurisdiction identifier; 

c. Ballot style; 

d. Paper record identifier; and 

e. For each contest and ballot question: 

i. The choice recorded, including write-ins; and 

ii. Information about each write-in. 

Test Method: Functional 

Test Entity: VSTL 

2.6.2.4 All records capable of being printed 

The tabulation device SHALL provide the ability to produce printed forms of its 

electronic records. The printed forms SHALL retain all required information as 

specified for each record type other than digital signatures. 

Test Method: Functional 

Test Entity: VSTL 

2.6.2.5 Summary count record 

The voting system SHALL produce a summary count record including the following: 

a. Time and date of summary record; and 

b. The following, both in total and broken down by ballot style and voting 

location: 

i. Number of received ballots 

ii. Number of counted ballots 

iii. Number of rejected electronic CVRs 

iv. Number of write-in votes 

v. Number of undervotes. 

Section 2 | Page 27
2.6 Audit and Accountability 

Test Method: Functional 

Test Entity: VSTL 

2.6.3 Paper Records 

The vote capture device is required to produce a paper record for each ballot cast. 

This record SHALL be available to the voter to review and verify, and SHALL be 

retained for later auditing or recounts, as specified by state law. Paper records 

provide an independent record of the voter’s choices that can be used to verify the 

correctness of the electronic record created by the vote capture device. 

2.6.3.1 Paper record creation 

Each vote capture device SHALL print a human readable paper record. 

Test Method: Functional 

Test Entity: VSTL 

2.6.3.2 Paper record contents 

Each paper record SHALL contain at least: 

a. Election title and date of election; 

b. Voting location; 

c. Jurisdiction identifier; 

d. Ballot style; 

e. Paper record identifier; and 

f. For each contest and ballot question: 

i. The recorded choice, including write-ins; and 

ii. Information about each write-in. 

Test Method: Inspection 

Test Entity: VSTL 

2.6.3.3 Privacy 

The vote capture device SHALL be capable of producing a paper record that does 

not contain any information that could link the record to the voter. 

Test Method: Inspection 

Test Entity: VSTL 

Section 2 | Page 28
2.7 Performance Monitoring 

2.6.3.4 Multiple pages 

When a single paper record spans multiple pages, each page SHALL include the 

voting location, ballot style, date of election, and page number and total number of 

the pages (e.g., page 1 of 4). 

Test Method: Functional 

Test Entity: VSTL 

2.6.3.5 Machine-readable part contains same information as humanreadable part 

If a non-human-readable encoding is used on the paper record, it SHALL contain 

the entirety of the human-readable information on the record. 

Test Method: Inspection 

Test Entity: VSTL 

2.6.3.6 Format for paper record non-human-readable data 

Any non-human-readable information on the paper record SHALL be presented in 

a non-proprietary format. 

Test Method: Inspection 

Test Entity: VSTL 

2.6.3.7 Linking the electronic CVR to the paper record 

The paper record SHALL: 

a. Contain the paper record identifier; and 

b. Identify whether the paper record represents the ballot that was cast. 

Test Method: Inspection 

Test Entity: VSTL 

2.7 Performance Monitoring 

2.7.1 Voting System and Network Status 

2.7.1.1 Network monitoring 

The system server SHALL provide for system and network monitoring during the 

voting period. 

Test Method: Functional 

Test Entity: VSTL 

Section 2 | Page 29
2.7 Performance Monitoring 

2.7.1.2 Tool access 

The system and network monitoring functionality SHALL only be accessible to 

authorized personnel from restricted consoles. 

Test Method: Functional 

Test Entity: VSTL 

2.7.1.3 Tool privacy 

System and network monitoring functionality SHALL NOT have the capability to 

compromise voter privacy or election integrity. 

Test Method: Functional 

Test Entity: VSTL 

Section 2 | Page 30
3.1 Overview 

Section 3: Usability, Accessibility, and 

Privacy Requirements 

3.1 Overview 

The importance of usability and accessibility in the design of voting systems has become 

increasingly apparent. It is not sufficient that the internal operation of these systems be 

correct; in addition, voters and kiosk workers must be able to use them effectively. There 

are some particular considerations for the design of usable and accessible voting 

systems: 

 The voting task itself can be fairly complex; the voter may have to navigate an 

electronic ballot, choose multiple candidates in a single contest, or decide on 

abstrusely worded referenda 

 Pilot projects by definition are implementing new kinds of voting systems, so 

there is limited opportunity for voters and kiosk workers to gain familiarity with the 

process 

 Usability and accessibility requirements include a broad range of factors, 

including physical abilities, language skills, and technology experience 

3.1.1 Purpose 

The challenge, then, is to provide a voting system that voters can use comfortably, 

efficiently, and with confidence that they have cast their votes correctly. The 

requirements within this section are intended to serve that goal. Three broad 

principles motivate this section: 

1. All eligible UOCAVA voters SHALL have access to the voting process 

without discrimination. 

The voting process SHALL be accessible to individuals with disabilities. The voting 

process includes access to the kiosk site, instructions on how to vote, initiating the 

voting session, making ballot selections, review of the ballot and the paper record, 

final submission of the ballot, depositing the paper record in a secure receptacle, and 

getting help when needed. 

2. Each cast ballot SHALL accurately capture the selections made by the voter. 

The ballot SHALL be presented to the voter in a manner that is clear and usable. 

Voters should encounter no difficulty or confusion regarding the process for 

recording their selections. 

3. The voting process SHALL preserve the secrecy of the ballot. 

The voting process SHALL preclude anyone else from determining the content of a 

voter's ballot, without the voter's cooperation. If such a determination is made against 

the wishes of the voter, then his or her privacy has been violated. 

All the requirements in this section have the purpose of improving the quality of 

interaction between voters and voting systems. 

Note that these principles refer to the entire voting process. The UOCAVA Pilot 

Program Testing Requirements apply only to voting systems; other aspects of the 

Section 3 | Page 31
3.2 General Usability 

process (such as administrative rules and procedures) are outside the scope of EAC 

certification, but are nonetheless crucial for the full achievement of the principles. 

3.1.2 Special terminology 

The following terms are used frequently in this chapter; they are defined in the 

Glossary in Appendix A: 

 Alert time 

 Audio-Tactile Interface (ATI) 

 Common Industry Format (CIF) 

 Completed system response time 

 Initial system response time 

 Voter inactivity time 

3.2 General Usability 

The voting system SHALL support voters in the task of effectively and accurately casting 

their ballots. The features of the voting system SHALL not contribute to the commission 

of voter error within the voting session. 

3.2.1 Privacy 

The voting process must preclude anyone else from determining the content of a 

voter's ballot without the voter's cooperation. Privacy ensures that the voter can cast 

votes based solely on his or her own preferences without intimidation or inhibition. 

3.2.1.1 Privacy at the kiosk locations 

a. The vote capture device SHALL prevent others from determining the 

contents of a ballot. 

b. The vote capture device SHALL support ballot privacy during the voting 

session and ballot submission. 

c. During the voting session, if an audio interface to the vote capture device is 

provided, it SHALL be audible only to the voter. 

d. The vote capture device SHALL issue all warnings in a way that preserves 

the privacy of the voter and the confidentiality of the ballot. 

e. The vote capture device SHALL not issue a receipt to the voter that would 

provide proof to another of how the voter voted. 

3.2.1.2 No recording of alternative format usage 

When voters use non-typical ballot interfaces, such as large print or alternative 

languages, their anonymity may be vulnerable. To the extent possible, only the 

logical contents of their ballots should be recorded, not the special formats in which 

they were rendered. 

a. No information SHALL be kept within an electronic cast voter record that 

identifies any alternative language feature(s) used by a voter. 

Section 3 | Page 32
3.2 General Usability 

b. No information SHALL be kept within an electronic cast voter record that 

identifies any accessibility feature(s) used by a voter. 

3.2.2 Cognitive issues 

The features specified in this section are intended to minimize cognitive difficulties for 

voters. They should always be able to operate the vote capture device and 

understand the effect of their actions. 

a. The vote capture device SHALL provide instructions for all its valid 

operations. 

b. The vote capture device SHALL provide a means for the voter to get help 

directly from the system at any time during the voting session. 

c. Instructional material for the voter SHALL conform to norms and best 

practices for plain language. 

i. Warnings and alerts issued by the vote capture device SHALL be 

distinguishable from other information and should clearly state: 

 The nature of the problem; 

 Whether the voter has performed or attempted an invalid 

operation or whether the vote capture device itself has 

malfunctioned in some way; and 

 The set of responses available to the voter. 

ii. When an instruction is based on a condition, the condition should be 

stated first, and then the action to be performed. 

iii. The vote capture device should use familiar, common words and 

avoid technical or specialized words that voters are not likely to 

understand. 

iv. Each distinct instruction should be separated spatially from other 

instructions for visual or tactile interfaces, and temporally for auditory 

interfaces. 

v. The vote capture device should issue instructions on the correct way 

to perform actions, rather than telling voters what not to do. 

vi. The instructions should address the voter directly rather than use 

passive voice constructions. 

vii. The vote capture device should avoid the use of gender-based 

pronouns. 

d. Consistent with election law, the voting application SHALL support a process 

that does not introduce bias for or against any of the contest choices to be 

presented to the voter. In both visual and aural formats, the choices SHALL 

be presented in an equivalent manner. 

e. The voting system SHALL provide the capability to design a ballot with a high 

level of clarity and comprehensibility. 

i. The vote capture device should not visually present a single contest 

spread over two pages or two columns. 

ii. The ballot SHALL clearly indicate the maximum number of 

candidates for which one can vote within a single contest. 

Section 3 | Page 33
3.2 General Usability 

iii. The relationship between the name of a candidate and the 

mechanism used to vote for that candidate SHALL be consistent 

throughout the ballot. 

iv. The vote capture device should present instructions near to where 

they are needed. 

f. The use of color SHALL agree with common conventions: (a) green, blue or 

white is used for general information or as a normal status indicator; (b) 

amber or yellow is used to indicate warnings or a marginal status; (c) red is 

used to indicate error conditions or a problem requiring immediate attention. 

g. When an icon is used to convey information, indicate an action, or prompt a 

response, it SHALL be accompanied by a corresponding linguistic label. 

3.2.3 Perceptual issues 

The requirements of this section are designed to minimize perceptual difficulties for 

the voter. Some of these requirements are designed to assist voters with poor 

reading vision. These are voters who might have some difficulty in reading normal 

text, but are not typically classified as having a visual disability. 

a. The electronic display screen of the vote capture device SHALL have the 

following characteristics: 

 Flicker frequency NOT between 2 Hz and 55 Hz. 

 Minimum display brightness: 130 cd/m2 

 Minimum display darkroom 7×7 checkerboard contrast: 150:1 

 Minimum display pixel pitch: 85 pixels/inch (0.3 mm/pixel) 

 Minimum display area 700 cm2 

 Antiglare screen surface that shows no distinct virtual image of a 

light source 

 Minimum uniform diffuse ambient contrast for 500 1× illuminance: 

10:1 

b. Any aspect of the vote capture device that is adjustable by either the voter or 

kiosk worker, including font size, color, contrast, audio volume, or rate of 

speech, SHALL automatically reset to a standard default value upon 

completion of that voter's session. 

c. If any aspect of a vote capture device is adjustable by either the voter or 

kiosk worker, there SHALL be a mechanism to allow the voter to reset all 

such aspects to their default values while preserving the current votes. 

d. For all text the vote capture device SHALL provide a font with the following 

characteristics 

 Height of capital letters at least: 3.0 mm 

 x-height of a least: 70% of cap height 

 Stroke width at least: 0.35 mm. 

e. The vote capture device electronic image display SHALL be capable of 

showing all information in at least two font sizes: 

Section 3 | Page 34
3.2 General Usability 

 3.0-4.0 mm cap height, with a corresponding x-height at least 70% of 

the cap height and a minimum stroke width of 0.35 mm; 

 6.3-9.0 mm cap height, with a corresponding x-height at least 70% of 

the cap height and a minimum stroke width of 0.7 mm; under control 

of the voter. The device SHALL allow the voter to adjust font size 

throughout the voting session while preserving the current votes. 

f. Text should be presented in a sans serif font. 

g. Vote capture devices providing paper verification records SHALL provide 

features that assist in the reading of such records by voters with poor reading 

vision. 

i. The vote capture device may achieve legibility of paper records by 

supporting the printing of those records in at least two font sizes, 3.0-

4.0mm and 6.3-9.0mm. 

ii. The vote capture device may achieve legibility of paper records by 

supporting magnification of those records. This magnification may 

be done by optical or electronic devices. The manufacturer may 

either: 1) provide the magnifier itself as part of the system, or 2) 

provide the make and model number of readily available magnifiers 

that are compatible with the system. 

h. The minimum figure-to-ground ambient contrast ratio for all text and 

informational graphics (including icons) SHALL be 10:1. For paper records, 

contrast is measured based on ambient lighting of at least 300 l×. 

i. The electronic display screen of the vote capture device SHALL be capable 

of showing all information in high contrast either by default or under the 

control of the voter. If the device allows the voter to adjust contrast during 

the voting session it SHALL preserve the current votes. High contrast is a 

figure-to-ground ambient contrast ratio for text and informational graphics of 

at least 50:1. 

j. The default color coding SHALL support correct perception by voters with 

color blindness. 

i. Ordinary information presented to the voter should be in the form of 

black text on a white background. The use of color should be 

reserved for special cases, such as warnings or alerts. 

ii. No information presented to the voter SHALL be in the form of 

colored text on a colored background. Either the text or background 

SHALL be black or white. 

iii. If text is colored other than black or white: 

1. The background SHALL be black or white. 

2. The text SHALL be presented in a bold font (minimum 0.6 

mm stroke width). 

3. If the background is black, the text color SHALL be yellow or 

light cyan. 

4. If the background is white, the text color SHALL be dark 

enough to maintain a 10:1 contrast ratio. 

iv. If the background is colored other than black or white, the 

presentation SHALL follow these guidelines: 

1. The text color SHALL be black. 

Section 3 | Page 35
3.2 General Usability 

2. The background color SHALL be yellow or light cyan. 

k. Color coding SHALL not be used as the sole means of conveying 

information, indicating an action, prompting a response, or distinguishing a 

visual element. 

3.2.4 Interaction issues 

The requirements of this section are designed to minimize interaction difficulties for 

the voter. 

a. The vote capture device SHALL not require page scrolling by the voter. 

b. The vote capture device SHALL provide unambiguous feedback regarding 

the voter’s selection, such as displaying a checkmark beside the selected 

option or conspicuously changing its appearance. 

c. Vote capture device input mechanisms SHALL be designed to prevent 

accidental activation. 

i. On touch screens, the sensitive touch areas SHALL have a minimum 

height of 0.5 inches and minimum width of 0.7 inches. The vertical 

distance between the centers of adjacent areas SHALL be at least 

0.6 inches, and the horizontal distance at least 0.8 inches. Touch 

areas SHALL not overlap. 

3.2.4.1 Timing issues 

These requirements address how long the system and voter wait for each other to 

interact. 

a. The initial system response time of the vote capture device SHALL be no 

greater than 0.5 seconds. 

b. When the voter performs an action to record a single vote, the completed 

system response time of the vote capture device SHALL be no greater 

than one second in the case of a visual response, and no greater than five 

seconds in the case of an audio response. 

c. The completed system response time of the vote capture device SHALL be 

no greater than 10 seconds. 

d. If the vote capture device has not completed its visual response within one 

second, it SHALL present to the voter, within 0.5 seconds of the voter's 

action, some indication that it is preparing its response. 

e. If the vote capture device requires a response by a voter within a specific 

period of time, it SHALL issue an alert at least 20 seconds before this time 

period has expired and provide a means by which the voter may receive 

additional time 

3.2.5 Alternative languages 

HAVA Section 301 (a)(4) states that the voting system SHALL provide alternative 

language accessibility pursuant to the requirements of Section 203 of the Voting 

Rights Act of 1965 (42 U.S.C. 1973aa-1a). Ideally every voter would be able to vote 

independently and privately, regardless of language. As a practical matter, 

alternative language access is mandated under the Voting Rights Act of 1975, 

subject to certain thresholds (e.g., if the language group exceeds 5% of the voting 

Section 3 | Page 36
3.2 General Usability 

age population). Thus, election officials must ensure that the pilot voting system is 

capable of handling the languages meeting the legal threshold within their districts. 

a. The voting system SHALL be capable of presenting the ballot, contest 

choices, review screens, paper verification records, and voting instructions in 

any language declared by the manufacturer to be supported by the system. 

3.2.6 Usability for kiosk workers 

Voting systems are used not only by voters to record their votes, but also by kiosk 

workers who are responsible for kiosk site set-up, light maintenance, and kiosk site 

closing. Because of the variety of possible implementations, it is impossible to 

specify detailed design requirements for these functions. The requirements below 

describe general capabilities that all pilot systems must support. 

a. Messages generated by the vote capture device for kiosk workers in support 

of the set up, maintenance, or safety of the system SHALL adhere to the 

requirements for clarity in Section 3.2.4 “Cognitive issues”. 

3.2.6.1 Operation 

Kiosk workers are responsible for opening the kiosk locations each day of the 

voting period, keeping them running smoothly during voting hours, closing the kiosk 

locations at the end of each day of the voting period, and shutting down the kiosks 

at the end of the voting period. 

Operations may be categorized in three phases: initial system set up, daily set up 

and operation, and shutting down the system at the end of the voting period. 

Initial setup includes all the steps necessary to remove the system from its shipping 

crate, physically set up and configure the vote capture devices and peripherals, 

verify the integrity of the software, load and check out the software, initiate and 

check out the communications links. . 

Daily operation of the kiosk location includes such functions as: 

 voter identification and authorization; 

 provision of smartcard to voter to initiate the voting session ; 

 assistance to voters who need help; 

 system recovery in the case of voters who abandon the voting session 

without having cast a ballot; and 

 routine supplies replenishment, such as adding paper to the printer. 

Daily shutdown includes all the steps necessary to take the vote capture device 

from the state in which it is ready to record votes to its overnight storage state. 

a. The procedures for voting system setup, polling, and shutdown, as 

documented by the manufacturer, SHALL be reasonably easy for the typical 

poll worker to learn, understand, and perform. 

b. The manufacturer SHALL provide clear, complete, and detailed instructions 

and messages for kiosk location setup, daily operation, and shutdown. 

i. The documentation SHALL be presented at a level appropriate for 

kiosk workers who are not experts in voting system and computer 

technology. 

ii. The documentation SHALL be in a format suitable for use in the 

kiosk location. 

Section 3 | Page 37
3.3 Accessibility requirements 

iii. The instructions and messages SHALL enable the kiosk worker to 

verify that the vote capture device, peripherals, and communications 

links 

 Has been set up correctly; 

 Is in correct working order to record votes; and 

 Has been shut down correctly. 

3.2.6.2 Safety 

All voting systems and their components must be designed so as to eliminate 

hazards to personnel or to the equipment itself. Hazards include, but are not 

limited to: 

 Fire hazards; 

 Electrical hazards; 

 Potential for equipment tip-over (stability); 

 Potential for cuts and scrapes (e.g., sharp edges); 

 Potential for pinching (e.g., tight, spring-loaded closures); and 

 Potential for hair or clothing entanglement. 

Devices associated with the voting system SHALL be certified in accordance with 

the requirements of UL 60950-1, Information Technology Equipment – Safety – 

Part 1 by a certification organization accredited by the Department of Labor, 

Occupational Safety and Health Administration’s Nationally Recognized Testing 

Laboratory program. The certification organization’s scope of accreditation SHALL 

include IEC/UL 60950-1. 

IEC/UL 60950 is a comprehensive standard for IT equipment and addresses all the 

hazards discussed above under Safety. 

3.3 Accessibility requirements 

The voting process is to be accessible to voters with disabilities through the use of a 

specially equipped voting station. A machine so equipped is referred to herein as an 

accessible voting station (Acc-VS). 

The requirements in this section are intended to address this HAVA mandate. Ideally, 

every voter would be able to vote independently and privately. As a practical matter, 

there may be some number of voters who, because of the nature of their disabilities, will 

need personal assistance with any system. Nonetheless, these requirements are meant 

to make the voting system independently accessible to as many voters as possible. This 

includes access across all voting processes: capabilities to generate, verify and cast an 

official ballot must be provided. 

This section is organized according to the type of disability being addressed. For each 

type, certain appropriate design features are specified. Note, however, that a feature 

intended primarily to address one kind of disability may very well assist voters with other 

kinds. Moreover, this organization in no way implies that the various sets of requirements 

are optional or mutually exclusive. In order to conform, an Accessible Voting Station 

must fulfill all the requirements of all the sub-sections of Chapter 3.3. 

Section 3 | Page 38
3.3 Accessibility requirements 

There are many other requirements, such as the general usability requirements, that 

apply to the Acc-VS besides those in this section. Please see Section 3.1.3 “Interaction of 

usability and accessibility requirements” for a full explanation. 

3.3.1 General 

The requirements of this section are relevant to a wide variety of disabilities. 

a. The Acc-VS SHALL be integrated into the manufacturer’s complete voting 

system so as to support accessibility for disabled voters throughout the 

voting session. 

i. The manufacturer SHALL supply documentation describing 1) 

recommended procedures that fully implement accessibility for 

voters with disabilities and 2) how the Acc-VS supports those 

procedures. 

b. When the provision of accessibility for Acc-VS involves an alternative format 

for ballot presentation, then all information presented to non-disabled voters, 

including instructions, warnings, error and other messages, and contest 

choices, SHALL be presented in that alternative format. 

c. The support provided to voters with disabilities SHALL be intrinsic to the 

accessible voting station. It SHALL not be necessary for the accessible 

voting station to be connected to any personal assistive device of the voter in 

order for the voter to operate it correctly. 

d. If a voting system provides for voter identification or authentication by using 

biometric measures that require a voter to possess particular biological 

characteristics, then Acc-VS SHALL provide a secondary means that does 

not depend on those characteristics. 

e. If the Acc-VS generates a paper record (or some other durable, humanreadable record) for the purpose of allowing voters to verify their votes, then 

the system SHALL provide a means to ensure that the verification record is 

accessible to all voters with disabilities, as identified in 3.3 “Accessibility 

requirements”. 

i. If the Acc-VS generates a paper record (or some other durable, 

human-readable record) for the purpose of allowing voters to verify 

their votes, then the system SHALL provide a mechanism that can 

read that record and generate an audio representation of its 

contents. 

3.3.2 Low vision 

These requirements specify the features of the accessible voting station designed to 

assist voters with low vision. 

In general, low vision is defined as having a visual acuity worse than 20/70. Low (or 

partial) vision also includes dimness of vision, haziness, film over the eye, foggy 

vision, extreme near-sightedness or far-sightedness, distortion of vision, color 

distortion or blindness, visual field defects, spots before the eyes, tunnel vision, lack 

of peripheral vision, abnormal sensitivity to light or glare and night blindness. 

People with tunnel vision can see only a small part of the ballot at one time. For 

these users it is helpful to have letters at the lower end of the font size range in order 

Section 3 | Page 39
3.3 Accessibility requirements 

to allow them to see more letters at the same time. Thus, there is a need to provide 

font sizes at both ends of the range. 

People with low vision or color blindness benefit from high contrast and from a 

selection of color combinations appropriate for their needs. Between 7% and 10% of 

all men have color vision deficiencies. Certain color combinations in particular cause 

problems. Therefore, use of color combinations with good contrast is required. Note 

also the general Requirement 3.2.5 j. 

However, some users are very sensitive to very bright displays and cannot use them 

for long. An overly bright background causes a visual white-out that makes these 

users unable to distinguish individual letters. Thus, use of non-saturated color 

options is an advantage for some people. 

It is important to note that some of the requirements in 3.2.5 “Perceptual issues” also 

provide support for voters with certain kinds of vision problems. 

a. An accessible voting station with a color electronic image display SHALL 

allow the voter to adjust the color saturation throughout the voting session 

while preserving the current votes. Two options SHALL be available: 1) 

black text on white background and 2) white text on black background. 

b. Buttons and controls on accessible voting stations SHALL be distinguishable 

by both shape and color. This applies to buttons and controls implemented 

either "on-screen" or in hardware. This requirement does not apply to 

sizeable groups of keys, such as a conventional 4x3 telephone keypad or a 

full alphabetic keyboard. 

c. The Acc-VS SHALL provide synchronized audio output to convey the same 

information as that which is displayed on the screen. There SHALL be a 

means by which the voter can disable either the audio or the video output, 

resulting in a video-only or audio-only presentation, respectively. The system 

SHALL allow the voter to switch among the three modes (synchronized 

audio/video, video-only, or audio-only) throughout the voting session while 

preserving the current votes. 

3.3.3 Blindness 

These requirements specify the features of the accessible voting station designed to 

assist voters who are blind. 

a. The accessible voting station SHALL provide an audio-tactile interface (ATI) 

that supports the full functionality of the visual ballot interface. 

i. The ATI of VEBD-A of the accessible voting station SHALL provide 

the same capabilities to vote and cast a ballot as are provided by its 

visual interface. 

ii. The ATI SHALL allow the voter to have any information provided by 

the voting system repeated. 

iii. The ATI SHALL allow the voter to pause and resume the audio 

presentation. 

iv. The ATI SHALL allow the voter to skip to the next contest or return to 

previous contests. 

v. The ATI SHALL allow the voter to skip over the reading of a 

referendum so as to be able to vote on it immediately. 

b. Voting stations that provide audio presentation of the ballot SHALL do so in a 

usable way, as detailed in the following sub-requirements. 

Section 3 | Page 40
3.3 Accessibility requirements 

i. The ATI SHALL provide its audio signal through an industry standard 

connector for private listening using a 3.5mm stereo headphone jack 

to allow voters to use their own audio assistive devices. 

ii. When VEBD-A utilizes a telephone style handset or headphone to 

provide audio information, it SHALL provide a wireless T-Coil 

coupling for assistive hearing devices so as to provide access to that 

information for voters with partial hearing. That coupling SHALL 

achieve at least a category T4 rating as defined by [ANSI01] 

American National Standard for Methods of Measurement of 

Compatibility between Wireless Communications Devices and 

Hearing Aids, ANSI C63.19. 

iii. A sanitized headphone or handset SHALL be made available to each 

voter. 

iv. VEBD-A SHALL set the initial volume for each voting session 

between 40 and 50 dB SPL. 

v. The audio system SHALL allow the voter to control the volume 

throughout the voting session while preserving the current votes. 

The volume SHALL be adjustable from a minimum of 20dB SPL up 

to a maximum of 100 dB SPL, in increments no greater than 10 dB. 

vi. The audio system SHALL be able to reproduce frequencies over the 

audible speech range of 315 Hz to 10 KHz. 

vii. The audio presentation for VEBD-A of verbal information should be 

readily comprehensible by voters who have normal hearing and are 

proficient in the language. This includes such characteristics as 

proper enunciation, normal intonation, appropriate rate of speech, 

and low background noise. Candidate names should be pronounced 

as the candidate intends. 

viii. The audio system SHALL allow the voter to control the rate of 

speech throughout the voting session while preserving the current 

votes. The range of speeds supported SHALL include 75% to 200% 

of the nominal rate. Adjusting the rate of speech SHALL not affect 

the pitch of the voice. 

c. If Acc-VS supports ballot activation for non-blind voters, then it SHALL also 

provide features that enable voters who are blind to perform this activation. 

d. If Acc-VS supports ballot submission or vote verification for non-blind voters, 

then it SHALL also provide features that enable voters who are blind to 

perform these actions. 

e. Mechanically operated controls or keys, or any other hardware interface on 

Acc-VS available to the voter SHALL be tactilely discernible without 

activating those controls or keys. 

f. The status of all locking or toggle controls or keys (such as the "shift" key) for 

Acc-VS SHALL be visually discernible, and also discernible through either 

touch or sound. 

3.3.4 Dexterity 

These requirements specify the features of the accessible voting station designed to 

assist voters who lack fine motor control or use of their hands. 

Section 3 | Page 41
3.3 Accessibility requirements 

a. The accessible voting station SHALL provide a mechanism to enable nonmanual input that is functionally equivalent to tactile input. All the 

functionality of the accessible voting station (e.g., straight party voting, writein candidates) that is available through the conventional forms of input, such 

as tactile, SHALL also be available through the non-manual input 

mechanism. 

b. If Acc-VS supports ballot submission or vote verification for non-disabled 

voters, then it SHALL also provide features that enable voters who lack fine 

motor control or the use of their hands to perform these actions. 

c. Keys, controls, and other manual operations on the accessible voting station 

SHALL be operable with one hand and SHALL not require tight grasping, 

pinching, or twisting of the wrist. The force required to activate controls and 

keys SHALL be no greater 5 lbs. (22.2 N). 

d. The accessible voting station controls SHALL not require direct bodily 

contact or for the body to be part of any electrical circuit. 

3.3.5 Mobility 

These requirements specify the features of the accessible voting station designed to 

assist voters who use mobility aids, including wheelchairs. Many of the requirements 

of this section are based on the ADA Accessibility Guidelines for Buildings and 

Facilities (ADAAG). 

a. The accessible voting station SHALL provide a clear floor space of 30 inches 

minimum by 48 inches minimum for a stationary mobility aid. The clear floor 

space SHALL be designed for a forward approach or a parallel approach. 

b. When deployed according to the installation instructions provided by the 

manufacturer, Acc-VS SHALL allow adequate room for an assistant to the 

voter. This includes clearance for entry to and exit from the area of the 

voting station. 

c. Labels, displays, controls, keys, audio jacks, and any other part of the 

accessible voting station necessary for the voter to operate the voting system 

SHALL be legible and visible to a voter in a wheelchair with normal eyesight 

(no worse than 20/40, corrected) who is in an appropriate position and 

orientation with respect to the accessible voting station. 

3.3.5.1 Controls within reach 

The requirements of this section ensure that the controls, keys, audio jacks and any 

other part of the accessible voting station necessary for its operation are within easy 

reach. Note that these requirements have meaningful application mainly to controls 

in a fixed location. A hand-held tethered control panel is another acceptable way of 

providing reachable controls. 

a. If the accessible voting station has a forward approach with no forward reach 

obstruction then the high reach SHALL be 48 inches maximum and the low 

reach SHALL be 15 inches minimum. See Part 1: Figure 3-1. 

b. If the accessible voting station has a forward approach with a forward reach 

obstruction, the following sub-requirements SHALL apply. (See Part 1: 

Figure 3-2). 

i. The forward obstruction for Acc-VS SHALL be no greater than 25 

inches in depth, its top no higher than 34 inches and its bottom 

surface no lower than 27 inches. 

Section 3 | Page 42
3.3 Accessibility requirements 

ii. If the obstruction for Acc-VS is no more than 20 inches in depth, then 

the maximum high reach SHALL be 48 inches, otherwise it SHALL 

be 44 inches. 

iii. Space under the obstruction between the finish floor or ground and 9 

inches above the finish floor or ground SHALL be considered toe 

clearance and SHALL comply with the following provisions for AccVS: 

1. Toe clearance depth SHALL extend 25 inches maximum 

under the obstruction; 

2. The minimum toe clearance depth under the obstruction 

SHALL be either 17 inches or the depth required to reach 

over the obstruction to operate the accessible voting 

station, whichever is greater; and 

3. Toe clearance width SHALL be 30 inches minimum. 

iv. Space under the obstruction between 9 inches and 27 inches above 

the finish floor or ground SHALL be considered knee clearance and 

SHALL comply with the following provisions: 

1. Knee clearance depth SHALL extend 25 inches maximum 

under the obstruction at 9 inches above the finish floor or 

ground; 

2. The minimum knee clearance depth at 9 inches above the 

finish floor or ground SHALL be either 11 inches or 6 

inches less than the toe clearance, whichever is greater; 

3. Between 9 inches and 27 inches above the finish floor or 

ground, the knee clearance depth SHALL be permitted to 

reduce at a rate of 1 inch in depth for each 6 inches in 

height. (It follows that the minimum knee clearance at 27 

inches above the finish floor or ground SHALL be 3 inches 

less than the minimum knee clearance at 9 inches above 

the floor.); and 

4. Knee clearance width SHALL be 30 inches minimum. 

c. If the accessible voting station has a parallel approach with no side reach 

obstruction then the maximum high reach SHALL be 48 inches and the 

minimum low reach SHALL be 15 inches. See Part 1: Figure 3-3. 

d. If the accessible voting station has a parallel approach with a side reach 

obstruction, the following sub-requirements SHALL apply. See Figure 3-1. 

i. The side obstruction for Acc-VS SHALL be no greater than 24 inches 

in depth and its top no higher than 34 inches. 

ii. If the obstruction is no more than 10 inches in depth, then the 

maximum high reach SHALL be 48 inches, otherwise it SHALL be 46 

inches. 

Section 3 | Page 43
3.3 Accessibility requirements 

Figure 3-1 Unobstructed reach measurements 

Dimensions shown in inches above the line, SI units (in millimeters) below the line 

Figure 1: Unobstructed forward reach Figure 2: Obstructed forward reach 

(a) for an obstruction depth of up to 20 inches 

(b) for an obstruction depth of up to 25 inches 

Figure 3: Unobstructed side reach with 

an allowable obstruction less than 10 

inches deep 

Figure 4: Obstructed side reach 

(a) for an obstruction depth of up to 10 inches 

(b) for an obstruction depth of up to 24 inches 

3.3.6 Hearing 

These requirements specify the features of the accessible voting station designed to 

assist voters with hearing disabilities. 

a. The accessible voting station SHALL incorporate the features listed under 

Requirement 3.3.3-C for voting systems that provide audio presentation of 

the ballot. 

b. If the accessible voting system provides sound cues as a method to alert the 

voter, the tone SHALL be accompanied by a visual cue, unless the station is 

in audio-only mode. 

c. No voting device SHALL cause electromagnetic interference with assistive 

hearing devices that would substantially degrade the performance of those 

devices. The voting device, measured as if it were a wireless device, SHALL 

achieve at least a category T4 rating as defined by [ANSI01] American 

National Standard for Methods of Measurement of Compatibility between 

Wireless Communications Devices and Hearing Aids, ANSI C63.19. 

Section 3 | Page 44
3.3 Accessibility requirements 

3.3.7 Cognition 

These requirements specify the features of the accessible voting station designed to 

assist voters with cognitive disabilities. 

a. The accessible voting station should provide support to voters with cognitive 

disabilities. 

3.3.8 English proficiency 

These requirements specify the features of the accessible voting station designed to 

assist voters who lack proficiency in reading English. 

a. For voters who lack proficiency in reading English, Acc-VS SHALL provide 

an audio interface for instructions and ballots as described in 3.3.3 b. 

Section 3 | Page 45
4.1 Selection of Programming Languages 

Section 4: Software 

4.1 Selection of Programming Languages 

4.1.1 Acceptable Programming Language Constructs 

Application logic SHALL be produced in a high-level programming language that has 

all of the following control constructs: 

a. Sequence; 

b. Loop with exit condition (e.g., for, while, and/or do-loops); 

c. If/Then/Else conditional; 

d. Case conditional; and 

e. Block-structured exception handling (e.g., try/throw/catch). 

Test Method: Inspection 

Test Entity: Manufacturer 

4.2 Selection of General Coding Conventions 

4.2.1 Acceptable Coding Conventions 

Application logic SHALL adhere to (or be based on) a published, credible set of 

coding rules, conventions or standards (herein simply called "coding conventions") 

that enhance the workmanship, security, integrity, testability, and maintainability of 

applications. 

Test Method: Inspection 

Test Entity: Manufacturer 

4.2.1.1 Published 

Coding conventions SHALL be considered published if they appear in publicly 

available media. 

Test Method: Inspection 

Test Entity: Manufacturer 

4.2.1.2 Credible 

Coding conventions SHALL be considered credible if at least two different 

organizations independently decided to adopt them and made active use of them at 

some time within the three years before conformity assessment was first sought. 

Test Method: Inspection 

Section 4 | Page 46
4.3 Software Modularity and Programming 

Test Entity: Manufacturer 

4.3 Software Modularity and Programming 

4.3.1.1 Modularity 

Application logic SHALL be designed in a modular fashion. 

4.3.1.2 Module testability 

Each module SHALL have a specific function that can be tested and verified 

independently from the remainder of the code. 

Test Method: Inspection 

Test Entity: Manufacturer 

4.3.1.3 Module size and identification 

Modules SHALL be small and easily identifiable. 

Test Method: Inspection 

Test Entity: Manufacturer 

4.4 Structured Programming 

4.4.1 Exception Handling 

4.4.1.1 Exception handling 

Application logic SHALL handle exceptions using block-structured exception 

handling constructs. 

Test Method: Inspection 

Test Entity: Manufacturer 

4.4.1.2 Legacy library units must be wrapped 

If application logic makes use of any COTS or third-party logic callable units that do 

not throw exceptions when exceptional conditions occur, those callable units 

SHALL be wrapped in callable units that check for the relevant error conditions and 

translate them into exceptions, and the remainder of application logic SHALL use 

only the wrapped version. 

Test Method: Inspection 

Test Entity: Manufacturer 

Section 4 | Page 47
4.5 Comments 

4.4.2 Unstructured Control Flow is Prohibited 

Application logic SHALL contain no unstructured control constructs. 

Test Method: Inspection 

Test Entity: Manufacturer 

4.4.2.1 Branching 

Arbitrary branches (a.k.a. GoTos) SHALL NOT be allowed. 

Test Method: Inspection 

Test Entity: Manufacturer 

4.4.2.2 Intentional exceptions 

Exceptions SHALL only be used for abnormal conditions. Exceptions SHALL NOT 

be used to redirect the flow of control in normal ("non-exceptional") conditions. 

Test Method: Inspection 

Test Entity: Manufacturer 

4.4.2.3 Unstructured exception handling 

Unstructured exception handling (e.g., On Error GoTo, setjmp/longjmp) SHALL 

NOT be allowed. 

Test Method: Inspection 

Test Entity: Manufacturer 

4.4.2.4 Separation of code and data 

Application logic SHALL NOT compile or interpret configuration data or other input 

data as a programming language. 

Test Method: Inspection 

Test Entity: Manufacturer 

4.5 Comments 

4.5.1 Header Comments 

Application logic modules SHALL include header comments that provide at least the 

following information for each callable unit (e.g., function, method, operation, 

subroutine, procedure.): 

a. The purpose of the unit and how it works (if not obvious); 

Section 4 | Page 48
4.6 Executable Code and Data Integrity 

b. A description of input parameters, outputs and return values, exceptions 

thrown, and side-effects; and 

c. Any protocols that must be observed (e.g., unit calling sequences). 

Test Method: Inspection 

Test Entity: Manufacturer 

4.6 Executable Code and Data Integrity 

4.6.1 Code Coherency 

Application logic SHALL conform to the following sub-requirements: 

a. Self-modifying code SHALL NOT be allowed; 

b. Application logic SHALL be free of race conditions, deadlocks, livelocks, and 

resource starvation; 

c. If compiled code is used, it SHALL only be compiled using a COTS compiler; 

and 

d. If interpreted code is used, it SHALL only be run under a specific, identified 

version of a COTS runtime interpreter. 

Test Method: Inspection 

Test Entity: Manufacturer 

4.6.2 Prevent Tampering With Code 

Programmed devices SHALL defend against replacement or modification of 

executable or interpreted code. 

Test Method: Inspection 

Test Entity: Manufacturer 

4.6.3 Prevent Tampering With Data 

The voting system SHALL prevent access to or manipulation of configuration data, 

vote data, or audit records. 

Test Method: Inspection 

Test Entity: Manufacturer 

4.7 Error Checking 

Section 4 | Page 49
4.7 Error Checking 

4.7.1 Detect Garbage Input 

4.7.1.1 Validity check 

Programmed devices SHALL check information inputs for completeness and 

validity. 

Test Method: Inspection 

Test Entity: Manufacturer 

4.7.1.2 Defend against garbage input 

Programmed devices SHALL ensure that incomplete or invalid inputs do not lead to 

irreversible error. 

Test Method: Inspection 

Test Entity: Manufacturer 

4.7.2 Mandatory Internal Error Checking 

4.7.2.1 Error checking 

Application logic that is vulnerable to the following types of errors SHALL check for 

these errors at run time and respond defensively (as specified by Requirement 

4.7.2.8) when they occur: 

 Out-of-bounds accesses of arrays or strings (includes buffers used to move 

data); 

 Stack overflow errors; 

 CPU-level exceptions such as address and bus errors, dividing by zero, 

and the like; 

 Variables that are not appropriately handled when out of expected 

boundaries; 

 Numeric overflows; and 

 Known programming language specific vulnerabilities. 

Test Method: Inspection 

Test Entity: Manufacturer 

4.7.2.2 Range checking of indices 

If the application logic uses arrays, vectors, character sequences, strings or any 

analogous data structures, and the programming language does not provide 

automatic run-time range checking of the indices, the indices SHALL be rangedchecked on every access. 

Test Method: Inspection 

Test Entity: Manufacturer 

Section 4 | Page 50
4.7 Error Checking 

4.7.2.3 Stack overflows 

If stack overflow does not automatically result in an exception, the application logic 

SHALL explicitly check for and prevent stack overflow. 

Test Method: Inspection 

Test Entity: Manufacturer 

4.7.2.4 CPU traps 

The application logic SHALL implement such handlers as are needed to detect and 

respond to CPU-level exceptions including address and bus errors and dividing by 

zero. 

Test Method: Inspection 

Test Entity: Manufacturer 

4.7.2.5 Garbage input parameters 

All scalar or enumerated type parameters whose valid ranges as used in a callable 

unit (e.g., function, method, operation, subroutine, procedure.) do not cover the 

entire ranges of their declared data types SHALL be range-checked on entry to the 

unit. 

Test Method: Inspection 

Test Entity: Manufacturer 

4.7.2.6 Numeric overflows 

If the programming language does not provide automatic run-time detection of 

numeric overflow, all arithmetic operations that could potentially overflow the 

relevant data type SHALL be checked for overflow. 

Test Method: Inspection 

Test Entity: Manufacturer 

 

4.7.2.7 Nullify freed pointers 

If pointers are used, any pointer variables that remain within scope after the 

memory they point to is deallocated SHALL be set to null or marked as invalid 

(pursuant to the idiom of the programming language used) after the memory they 

point to is deallocated. 

Test Method: Inspection 

Test Entity: Manufacturer 

Section 4 | Page 51
4.8 Recovery 

4.7.2.8 React to errors detected 

The detection of any of the errors enumerated in Requirement 4.7.2.1 SHALL be 

treated as a complete failure of the callable unit in which the error was detected. An 

appropriate exception SHALL be thrown and control SHALL pass out of the unit 

forthwith. 

Test Method: Inspection 

Test Entity: Manufacturer 

4.7.2.9 Do not disable error checks 

Error checks detailed in Requirement 4.7.2.1 SHALL remain active in production 

code. 

Test Method: Inspection 

Test Entity: Manufacturer 

4.7.2.10 Roles authorized to respond to errors 

Exceptions resulting from failed error checks or CPU-level exceptions SHALL 

require intervention by an election official or administrator before voting can 

continue. 

Test Method: Inspection 

Test Entity: Manufacturer 

4.7.2.11 Election integrity monitoring 

The voting system SHALL proactively detect or prevent basic violations of election 

integrity (e.g., stuffing of the ballot box or the accumulation of negative votes) and 

alert an election official or administrator if such violations they occur. 

Test Method: Inspection 

Test Entity: Manufacturer 

4.8 Recovery 

4.8.1 Voting System Device Failure 

4.8.1.1 Resuming normal operations 

All voting systems SHALL be capable of resuming normal operations following the 

correction of a failure in any device. 

Test Method: Functional 

Test Entity: Manufacturer 

Section 4 | Page 52
4.8 Recovery 

4.8.1.2 Failures not compromise voting or audit data 

Exceptions and system recovery SHALL be handled in a manner that protects the 

integrity of all recorded votes and audit log information. 

Test Method: Functional 

Test Entity: Manufacturer 

4.8.1.3 Device survive component failure 

All vote capture device SHALL be capable of resuming normal operation following 

the correction of a failure in any component (e.g., memory, CPU, printer) provided 

that catastrophic electrical or mechanical damage has not occurred. 

Test Method: Functional 

Test Entity: Manufacturer 

4.8.2 Controlled Recovery 

Error conditions SHALL be corrected in a controlled fashion so that voting system 

status may be restored to the initial state existing before the error occurred. 

Test Method: Functional 

Test Entity: Manufacturer 

4.8.2.1 Nested error conditions 

Nested error conditions that are corrected without reset, restart, reboot, or 

shutdown of the vote capture device SHALL be corrected in a controlled sequence 

so that voting system status may be restored to the initial state existing before the 

first error occurred. 

Test Method: Functional 

Test Entity: Manufacturer 

4.8.2.2 Reset CPU error states 

CPU-level exceptions that are corrected without reset, restart, reboot, or shutdown 

of the vote capture device SHALL be handled in a manner that restores the CPU to 

a normal state and allows the voting system to log the event and recover as with a 

software-level exception. 

Test Method: Functional 

Test Entity: Manufacturer 

4.8.3 Restore Device to Checkpoints 

When recovering from non-catastrophic failure or from any error or malfunction that is 

within the operator's ability to correct, the voting system SHALL restore the device to 

Section 4 | Page 53
4.9 Source Code Review 

the operating condition existing immediately prior to the error or failure, without loss 

or corruption of voting data previously stored in the device. 

Test Method: Functional 

Test Entity: Manufacturer 

4.9 Source Code Review 

In the source code review, the accredited test lab shall look at programming 

completeness, consistency, correctness, modifiability, structure, modularity and 

construction. 

4.9.1 Workmanship 

Although these requirements are scoped to application logic, in some cases the test 

lab may need to inspect border logic and third-party logic to assess conformity. 

4.9.1.1 Review source versus manufacturer specifications 

The test lab SHALL assess the extent to which the application logic adheres to the 

specifications made in its design documentation. 

Test Method: Inspection 

Test Entity: VSTL 

4.9.1.2 Review source versus coding conventions 

The test lab SHALL assess the extent to which the application logic adheres to the 

published, credible coding conventions chosen by the manufacturer. 

Test Method: Inspection 

Test Entity: VSTL 

4.9.1.3 Review source versus workmanship requirements 

The test lab SHALL assess the extent to which the application logic adheres to the 

requirements of Section 4 Software. 

Test Method: Inspection 

Test Entity: VSTL 

4.9.1.4 Efficacy of built-in self-tests 

The test lab SHALL verify the efficacy of built-in measurement, self-test, and 

diagnostic capabilities. 

Test Method: Inspection 

Test Entity: VSTL 

Section 4 | Page 54
4.9 Source Code Review 

4.9.2 Security 

4.9.2.1 Security control source code review 

The test lab SHALL analyze the source code of the security controls to assess 

whether they function correctly and cannot be bypassed. 

Test Method: Inspection 

Test Entity: VSTL 

Section 4 | Page 55
5.1 Access Control 

Section 5: Security 

5.1 Access Control 

This section states requirements for the identification of authorized system users, 

processes and devices and the authentication or verification of those identities as a 

prerequisite to granting access to system processes and data. It also includes 

requirements to limit and control access to critical system components to protect system 

and data integrity, availability, confidentiality, and accountability. 

This section applies to all entities attempting to physically enter voting system facilities or 

to request services or data from the voting system. 

5.1.1 Separation of Duties 

5.1.1.1 Definition of roles 

The voting system SHALL allow the definition of personnel roles with segregated 

duties and responsibilities on critical processes to prevent a single person from 

compromising the integrity of the system. 

Test Method: Functional 

Test Entity: VSTL 

5.1.1.2 Access to election data 

The voting system SHALL ensure that only authorized roles, groups, or individuals 

have access to election data. 

Test Method: Functional 

Test Entity: VSTL 

5.1.1.3 Separation of duties 

The voting system SHALL require at least two persons from a predefined group for 

validating the election configuration information, accessing the cast vote records, 

and starting the tabulation process. 

Test Method: Functional 

Test Entity: VSTL 

5.1.2 Voting System Access 

The voting system SHALL provide access control mechanisms designed to permit 

authorized access and to prevent unauthorized access to the system. 

Section 5 | Page 56
5.1 Access Control 

5.1.2.1 Identity verification 

The voting system SHALL identify and authenticate each person to whom access 

is granted, and the specific functions and data to which each person holds 

authorized access. 

Test Method: Functional 

Test Entity: VSTL 

5.1.2.2 Access control configuration 

The voting system SHALL allow the administrator group or role to configure 

permissions and functionality for each identity, group or role to include account and 

group/role creation, modification, and deletion. 

Test Method: Functional 

Test Entity: VSTL 

5.1.2.3 Default access control configuration 

The voting system’s default access control permissions SHALL implement the least 

privileged role or group needed. 

Test Method: Functional 

Test Entity: VSTL 

5.1.2.4 Escalation prevention 

The voting system SHALL prevent a lower-privilege process from modifying a 

higher-privilege process. 

Test Method: Functional 

Test Entity: VSTL 

5.1.2.5 Operating system privileged account restriction 

The voting system SHALL NOT require its execution as an operating system 

privileged account and SHALL NOT require the use of an operating system 

privileged account for its operation. 

Test Method: Functional 

Test Entity: VSTL 

5.1.2.6 Logging of account 

The voting system SHALL log the identification of all personnel accessing or 

attempting to access the voting system to the system event log. 

Test Method: Functional 

Test Entity: VSTL 

Section 5 | Page 57
5.1 Access Control 

5.1.2.7 Monitoring voting system access 

The SHALL provide tools for monitoring access to the system. These tools SHALL 

provide specific users real time display of persons accessing the system as well as 

reports from logs. 

Test Method: Functional 

Test Entity: VSTL 

5.1.2.8 Login failures 

The vote capture devices at the kiosk locations and the central server SHALL have 

the capability to restrict access to the voting system after a preset number of login 

failures. 

a. The lockout threshold SHALL be configurable by appropriate 

administrators/operators. 

b. The voting system SHALL log the event. 

c. The voting system SHALL immediately send a notification to appropriate 

administrators/operators of the event. 

d. The voting system SHALL provide a mechanism for the appropriate 

administrators/operators to reactivate the account after appropriate 

confirmation. 

Test Method: Functional 

Test Entity: VSTL 

5.1.2.9 Account lockout logging 

The voting system SHALL log a notification when any account has been locked 

out. 

Test Method: Functional 

Test Entity: VSTL 

5.1.2.10 Session time-out 

Authenticated sessions on critical processes SHALL have an inactivity time-out 

control that will require personnel re-authentication when reached. This time-out 

SHALL be implemented for administration and monitor consoles on all voting 

system devices. 

Test Method: Functional 

Test Entity: VSTL 

5.1.2.11 Screen lock 

Authenticated sessions on critical processes SHALL have a screen-lock 

functionality that can be manually invoked. 

Section 5 | Page 58
5.2 Identification and Authentication 

Test Method: Functional 

Test Entity: VSTL 

5.2 Identification and Authentication 

Authentication mechanisms and their associated strength may vary from one voting 

system capability and architecture to another but all must meet the minimum requirement 

to maintain integrity and trust. It is important to consider a range of roles individuals may 

assume when operating different components in the voting system and each may require 

different authentication mechanisms. 

The requirements described in this section vary from role to role. For instance, a kiosk 

worker will have different identification and authentication characteristics than a voter. 

Also, for selected critical functions there may be cases where split knowledge or dual 

authorization is necessary to ensure security. This is especially relevant for critical 

cryptographic key management functions. 

5.2.1 Authentication 

5.2.1.1 Strength of authentication 

Authentication mechanisms supported by the voting system SHALL support 

authentication strength of at least 1/1,000,000. 

Test Method: Functional 

Test Entity: VSTL 

5.2.1.2 Minimum authentication methods 

The voting system SHALL authenticate users per the minimum authentication 

methods outlined below. 

Test Method: Functional 

Test Entity: VSTL 

Table 5-1 Roles 

GROUP OR ROLE MINIMUM AUTHENTICATION

STRENGTH 

Election Judge Two factor 

Kiosk Worker One factor 

Voter Not required 

Section 5 | Page 59
5.2 Identification and Authentication 

Election Official Two factor 

Administrator Two-factor 

Application or Process Digital signature 112 bits of security1

5.2.1.3 Multiple authentication mechanisms 

The voting system SHALL provide multiple authentication methods to support 

multi-factor authentication. 

Test Method: Functional 

Test Entity: VSTL 

5.2.1.4 Secure storage of authentication data 

When private or secret authentication data is stored by the voting system, it SHALL 

be protected to ensure that the confidentiality and integrity of the data are not 

violated. 

Test Method: Functional 

Test Entity: VSTL 

5.2.1.5 Password reset 

The voting system SHALL provide a mechanism to reset a password if it is 

forgotten, in accordance with the system access/security policy. 

Test Method: Functional 

Test Entity: VSTL 

5.2.1.6 Password strength configuration 

The voting system SHALL allow the administrator group or role to specify password 

strength for all accounts including minimum password length, use of capitalized 

letters, use of numeric characters, and use of non-alphanumeric characters per 

NIST 800-63 Electronic Authentication Guideline Standards. 

Test Method: Functional 

Test Entity: VSTL 

5.2.1.7 Password history configuration 

The voting system SHALL enforce password histories and allow the administrator 

to configure the history length when passwords are stored by the system. 

 

1

 NIST Special Publication 800-57 

Section 5 | Page 60
5.2 Identification and Authentication 

Test Method: Functional 

Test Entity: VSTL 

5.2.1.8 Account information password restriction 

The voting system SHALL ensure that the user name is not used in the password. 

Test Method: Functional 

Test Entity: VSTL 

5.2.1.9 Automated password expiration 

The voting system SHALL provide a means to automatically expire passwords. 

Test Method: Functional 

Test Entity: VSTL 

5.2.1.10 Device authentication 

The voting system servers and vote capture devices SHALL identify and 

authenticate one another using NIST - approved cryptographic authentication 

methods at the 112 bits of security. 

Test Method: Functional 

Test Entity: VSTL 

5.2.1.11 Network authentication 

Remote voting location site Virtual Private Network (VPN) connections (i.e., vote 

capture devices) to voting servers SHALL be authenticated using strong mutual 

cryptographic authentication at the 112 bits of security. 

Test Method: Functional 

Test Entity: VSTL 

5.2.1.12 Message authentication 

Message authentication SHALL be used for applications to protect the integrity of 

the message content using a schema with 112 bits of security. 

Test Method: Functional 

Test Entity: VSTL 

5.2.1.13 Message authentication mechanisms 

IPsec, SSL, or TLS and MAC mechanisms SHALL all be configured to be 

compliant with FIPS 140-2 using approved algorithm suites and protocols. 

Test Method: Functional 

Section 5 | Page 61
5.3 Cryptography 

Test Entity: VSTL 

5.3 Cryptography 

Cryptography serves several purposes in voting systems. They include: 

Confidentiality: where necessary the confidentiality of voting records can be provided by 

encryption; 

Authentication: data and programs can be authenticated by a digital signature or 

message authentication codes (MAC), or by comparison of the cryptographic hashes of 

programs or data with the reliably known hash values of the program or data. If the 

program or data are altered, then that alteration is detected when the signature or MAC is 

verified, or the hash on the data or program is compared to the known hash value. 

Typically the programs loaded on voting systems and the ballot definitions used by voting 

systems are verified by the systems, while systems apply digital signatures to 

authenticate the critical audit data that they output. For remote connections cryptographic 

user authentication mechanism SHALL be based on strong authentication methods; and 

Random number generation: random numbers are used for several purposes including 

the creation of cryptographic keys for cryptographic algorithms and methods to provide 

the services listed above, and as identifiers for voting records that can be used to identify 

or correlate the records without providing any information that could identify the voter. 

5.3.1 General Cryptography Requirements 

5.3.1.1 Cryptographic functionality 

All cryptographic functionality SHALL be implemented using NIST-approved 

cryptographic algorithms/schemas, or use published and credible cryptographic 

algorithms/schemas/protocols. 

Test Method: Inspection 

Test Entity: VSTL 

5.3.1.2 Required security strength 

Cryptographic algorithms and schemas SHALL be implemented with a security 

strength equivalent to at least 112 bits of security to protect sensitive voting 

information and election records. 

Test Method: Inspection 

Test Entity: VSTL 

5.3.1.3 Use NIST-approved cryptography for communications 

Cryptography used to protect information in-transit over public telecommunication 

networks SHALL use NIST-approved algorithms and cipher suites. In addition the 

implementations of these algorithms SHALL be NIST-approved (Cryptographic 

Algorithm Validation Program). 

Section 5 | Page 62
5.3 Cryptography 

Test Method: Function 

Test Entity: VSTL 

5.3.2 Key Management 

The following requirements apply to voting systems that generate cryptographic keys 

internally. 

5.3.2.1 Key generation methods 

Cryptographic keys generated by the voting system SHALL use a NIST-approved 

key generation method, or a published and credible key generation method. 

Test Method: Inspection 

Test Entity: VSTL 

5.3.2.2 Security of key generation methods 

Compromising the security of the key generation method (e.g., guessing the seed 

value to initialize the deterministic random number generator (RNG)) SHALL 

require as least as many operations as determining the value of the generated key. 

Test Method: Inspection 

Test Entity: VSTL 

5.3.2.3 Seed values 

If a seed key is entered during the key generation process, entry of the key SHALL 

meet the key entry requirements in 5.3.3.1. If intermediate key generation values 

are output from the cryptographic module, the values SHALL be output either in 

encrypted form or under split knowledge procedures. 

Test Method: Inspection 

Test Entity: VSTL 

5.3.2.4 Use NIST-approved key generation methods for 

communications 

Cryptographic keys used to protect information in-transit over public 

telecommunication networks SHALL use NIST-approved key generation methods. 

If the approved key generation method requires input from a random number 

generator, then an approved (FIPS 140-2) random number generator SHALL be 

used. 

Test Method: Inspection 

Test Entity: VSTL 

Section 5 | Page 63
5.3 Cryptography 

5.3.2.5 Random number generator health tests 

Random number generators used to generate cryptographic keys SHALL 

implement one or more health tests that provide assurance that the random 

number generator continues to operate as intended (e.g., the entropy source is not 

stuck). 

Test Method: Inspection 

Test Entity: VSTL 

5.3.3 Key Establishment 

Key establishment may be performed by automated methods (e.g., use of a public 

key algorithm), manual methods (use of a manually transported key loading device), 

or a combination of automated and manual methods. 

5.3.3.1 Key entry and output 

Secret and private keys established using automated methods SHALL be entered 

into and output from a voting system in encrypted form. Secret and private keys 

established using manual methods may be entered into or output from a system in 

plaintext form. 

Test Method: Inspection 

Test Entity: VSTL 

 

5.3.4 Key Handling 

5.3.4.1 Key storage 

Cryptographic keys stored within the voting system SHALL NOT be stored in 

plaintext. Keys stored outside the voting system SHALL be protected from 

disclosure or modification. 

Test Method: Inspection 

Test Entity: VSTL 

5.3.4.2 Key zeroization 

The voting system SHALL provide methods to zeroize all plaintext secret and 

private cryptographic keys within the system. 

Test Method: Functional 

Test Entity: VSTL 

5.3.4.3 Support for rekeying 

The voting system SHALL support the capability to reset cryptographic keys to new 

values. 

Test Method: Functional 

Section 5 | Page 64
5.4 Voting System Integrity Management 

Test Entity: VSTL 

5.4 Voting System Integrity Management 

This section addresses the secure deployment and operation of the voting system, 

including the protection of removable media and protection against malicious software. 

5.4.1 Protecting the Integrity of the Voting System 

5.4.1.1 Cast vote integrity; transmission 

The integrity and authenticity of each individual cast vote SHALL be protected from 

any tampering or modification during transmission. 

Test Method: Functional 

Test Entity: VSTL 

5.4.1.2 Cast vote integrity; storage 

The integrity and authenticity of each individual cast vote SHALL be preserved by 

means of a digital signature during storage. 

Test Method: Functional 

Test Entity: VSTL 

5.4.1.3 Cast vote storage 

Cast vote data SHALL NOT be permanently stored on the vote capture device. 

Test Method: Functional 

Test Entity: VSTL 

5.4.1.4 Electronic ballot box integrity 

The integrity and authenticity of the electronic ballot box SHALL be protected by 

means of a digital signature. 

Test Method: Functional 

Test Entity: VSTL 

5.4.1.5 Malware detection 

The voting system SHALL use malware detection software to protect against 

known malware that targets the operating system, services, and applications. 

Test Method: Inspection 

Test Entity: VSTL 

Section 5 | Page 65
5.5 Communications Security 

5.4.1.6 Updating malware detection 

The voting system SHALL provide a mechanism for updating malware detection 

signatures. 

Test Method: Inspection 

Test Entity: VSTL 

5.4.1.7 Validating software on kiosk voting devices 

The voting system SHALL provide the capability for kiosk workers to validate the 

software used on the vote capture devices as part of the daily initiation of kiosk 

operations. 

Test Method: Inspection 

Test Entity: VSTL 

5.5 Communications Security 

This section provides requirements for communications security. These requirements 

address ensuring the integrity of transmitted information and protecting the voting system 

from external communications-based threats. 

5.5.1 Data Transmission Integrity 

5.5.1.1 Data integrity protection 

Voting systems that transmit data over communications links SHALL provide 

integrity protection for data in transit through the generation of integrity data (digital 

signatures and/or message authentication codes) for outbound traffic and 

verification of the integrity data for inbound traffic. 

Test Method: Functional 

Test Entity: VSTL 

 

5.5.1.2 TLS/SSL 

Voting systems SHALL use at a minimum TLS 1.0, SSL 3.1 or equivalent 

protocols, including all updates to both protocols and implementations as of the 

date of the submission (e.g., RFC 5746 for TLS 1.0). 

Test Method: Functional 

Test Entity: VSTL 

5.5.1.3 Virtual private networks (VPN) 

Voting systems deploying VPNs SHALL configure them to only allow FIPScompliant cryptographic algorithms and cipher suites. 

Section 5 | Page 66
5.5 Communications Security 

Test Method: Functional 

Test Entity: VSTL 

5.5.1.4 Unique system identifier 

Each communicating device SHALL have a unique system identifier. 

Test Method: Inspection 

Test Entity: VSTL 

5.5.1.5 Mutual authentication required 

Each device SHALL mutually strongly authenticate using the system identifier 

before additional network data packets are processed. 

Test Method: Functional 

Test Entity: VSTL 

5.5.1.6 Secrecy of ballot data 

Data transmission SHALL preserve the secrecy of voters’ ballot selections and 

SHALL prevent the violation of ballot secrecy and integrity. 

Test Method: Functional 

Test Entity: VSTL 

5.5.2 External Threats 

Voting systems SHALL implement protections against external threats to which the 

system may be susceptible. 

Test Method: Functional 

Test Entity: VSTL 

5.5.2.1 Disabling network interfaces 

Voting system components SHALL have the ability to enable or disable physical 

network interfaces. 

Test Method: Functional 

Test Entity: VSTL 

5.5.2.2 Minimizing interfaces 

The number of active ports and associated network services and protocols SHALL 

be restricted to the minimum required for the voting system to function. 

Test Method: Inspection/Vulnerability 

Section 5 | Page 67
5.6 Logging 

Test Entity: VSTL 

5.5.2.3 Prevention of attacks and security non-compliance 

The voting system SHALL block all network connections that are not over a 

mutually authenticated channel. 

Test Method: Functional/Vulnerability 

Test Entity: VSTL 

5.6 Logging 

5.6.1 Log Management 

5.6.1.1 Default settings 

The voting system SHALL implement default settings for secure log management 

activities, including log generation, transmission, storage, analysis, and disposal. 

Test Method: Inspection 

Test Entity: VSTL 

5.6.1.2 Log access 

Logs SHALL only be accessible to authorized roles. 

Test Method: Functional 

Test Entity: VSTL 

5.6.1.3 Log access 

The voting system SHALL restrict log access to append-only for privileged logging 

processes and read-only for authorized roles. 

Test Method: Functional 

Test Entity: VSTL 

5.6.1.4 Logging events 

The voting system SHALL log logging failures, log clearing, and log rotation. 

Test Method: Functional 

Test Entity: VSTL 

5.6.1.5 Log format 

The voting system SHALL store log data in a publicly documented format, such as 

XML, or include a utility to export log data into a publicly documented format. 

Section 5 | Page 68
5.6 Logging 

Test Method: Inspection 

Test Entity: VSTL 

5.6.1.6 Log separation 

The voting system SHALL ensure that each jurisdiction’s event logs and each 

component’s logs are separable from each other. 

Test Method: Functional 

Test Entity: VSTL 

5.6.1.7 Log review 

The voting system SHALL include an application or program to view, analyze, and 

search event logs. 

Test Method: Functional 

Test Entity: VSTL 

5.6.1.8 Log preservation 

All logs SHALL be preserved in a useable manner prior to voting system 

decommissioning. 

Test Method: Inspection 

Test Entity: VSTL 

5.6.1.9 Voter privacy 

Logs SHALL NOT contain any data that could violate the privacy of the voter’s 

identity. 

Test Method: Functional 

Test Entity: VSTL 

5.6.1.10 Timekeeping format 

Timekeeping mechanisms SHALL generate time and date values, including hours, 

minutes, and seconds. 

Test Method: Functional 

Test Entity: VSTL 

5.6.1.11 Timekeeping precision 

The precision of the timekeeping mechanism SHALL be able to distinguish and 

properly order all log events. 

Section 5 | Page 69
5.6 Logging 

Test Method: Inspection 

Test Entity: VSTL 

5.6.1.12 System clock security 

Only the system administrator SHALL be permitted to set the system clock. 

Test Method: Functional 

Test Entity: VSTL 

5.6.2 Communications Logging 

5.6.2.1 General 

All communications actions SHALL be logged. 

Test Method: Inspection 

Test Entity: VSTL 

5.6.2.2 Log content 

The communications log SHALL contain at least the following entries: 

 Times when the communications are activated and deactivated; 

 Services accessed; 

 Identification of the device which data was transmitted to or received from; 

 Identification of authorized entity; and 

 Successful and unsuccessful attempts to access communications or 

services. 

Test Method: Functional 

Test Entity: VSTL 

5.6.3 System Event Logging 

This section describes requirements for the voting system to perform event logging 

for system maintenance troubleshooting, recording the history of system activity, and 

detecting unauthorized or malicious activity. The operating system, and/or 

applications software may perform the actual event logging. There may be multiple 

logs in use for any system component. 

5.6.3.1 Event log format 

The voting system SHALL log the following data for each event: 

a. System ID; 

b. Unique event ID and/or type; 

Section 5 | Page 70
5.6 Logging 

c. Timestamp; 

d. Success or failure of event, if applicable; 

e. User ID triggering the event, if applicable; and 

f. Jurisdiction, if applicable. 

Test Method: Inspection 

Test Entity: VSTL 

5.6.3.2 Critical events 

All critical events SHALL be recorded in the system event log. 

Test Method: Functional 

Test Entity: VSTL 

5.6.3.3 System events 

At a minimum the voting system SHALL log the events described in the table 

below. 

Test Method: Inspection 

Test Entity: VSTL 

Table 5-2 System Events 

SYSTEM EVENT DESCRIPTION

GENERAL SYSTEM FUNCTIONS

Error and exception messages 

Includes but not limited to: 

 The source and disposition of system interrupts resulting in 

entry into exception handling routines. 

 Messages generated by exception handlers. 

 The identification code and number of occurrences for each 

hardware and software error or failure. 

 Notification of physical violations of security. 

 Other exception events such as power failures, failure of 

critical hardware components, data transmission errors or 

other types of operating anomalies. 

 All faults and the recovery actions taken. 

 Error and exception messages such as ordinary timer 

system interrupts and normal I/O system interrupts do not 

need to be logged. 

Critical system status messages 

Critical system status messages other than information messages 

displayed by the device during the course of normal operations. 

Includes but not limited to: 

Section 5 | Page 71
5.6 Logging 

SYSTEM EVENT DESCRIPTION

 Diagnostic and status messages upon startup. 

 The “zero totals” check conducted before starting the voting 

period. 

Non-critical status messages Non-critical status messages that are generated by the data quality 

monitor or by software and hardware condition monitors. 

Events that require election official 

intervention 

Events that require election official intervention, so that each election 

official access can be monitored and access sequence can be 

constructed. 

Shutdown and restarts Both normal and abnormal shutdowns and restarts. 

Changes to system configuration 

settings 

Configuration settings include but are not limited to registry keys, 

kernel settings, logging settings, and other system configuration 

settings. 

Integrity checks for executables, 

configuration files, data, and logs 

Integrity checks that may indicate possible tampering with files and 

data. 

The addition and deletion of files Files added or deleted from the system. 

System readiness results 

Includes but not limited to: 

 System pass or fail of hardware and software test for system 

readiness. 

 Identification of the software release, identification of the 

election to be processed, kiosk locations, and the results of 

the software and hardware diagnostic tests. 

 Pass or fail of ballot style compatibility and integrity test. 

 Pass or fail of system test data removal. 

Removable media events Removable media that is inserted into or removed from the system. 

Backup and restore Successful and failed attempts to perform backups and restores. 

Authentication related events 

Includes but not limited to: 

 Login/logoff events (both successful and failed attempts). 

 Account lockout events. 

 Password changes. 

Access control related events 

Includes but not limited to: 

 Use of privileges. 

 Attempts to exceed privileges. 

 All access attempts to application and underlying system 

resources. 

 Changes to the access control configuration of the system. 

User account and role (or groups) 

management activity 

Includes but not limited to: 

 Addition and deletion of user accounts and roles. 

 User account and role suspension and reactivation. 

Section 5 | Page 72
5.7 Incident Response 

SYSTEM EVENT DESCRIPTION

 Changes to account or role security attributes such as 

password length, access levels, login restrictions, 

permissions. 

 Administrator account and role password resets. 

Installation, upgrading, patching, or 

modification of software or firmware 

Logging for installation, upgrading, patching, or modification of 

software or firmware include logging what was installed, upgraded, or 

modified as well as a cryptographic hash or other secure identifier of 

the old and new versions of the data. 

Changes to configuration settings 

Includes but not limited to: 

 Changes to critical function settings. At a minimum critical 

function settings include location of ballot definition file, 

contents of the ballot definition file, vote reporting, location of 

logs, and system configuration settings. 

 Changes to settings including but not limited to enabling and 

disabling services. 

 Starting and stopping processes. 

Abnormal process exits All abnormal process exits. 

Successful and failed database 

connection attempts (if a database is 

utilized). 

All database connection attempts. 

Changes to cryptographic keys At a minimum critical cryptographic settings include key addition, key 

removal, and re-keying. 

Voting events 

Includes: 

 Opening and closing the voting period. 

 Casting a vote. 

 Success or failure of log and election results exportation. 

5.7 Incident Response 

5.7.1 Incident Response Support 

5.7.1.1 Critical events 

Manufacturers SHALL document what types of system operations or security 

events (e.g., failure of critical component, detection of malicious code, 

unauthorized access to restricted data) are classified as critical. 

Test Method: Inspection 

Test Entity: VSTL 

Section 5 | Page 73
5.8 Physical and Environmental Security 

5.7.1.2 Critical event alarm 

An alarm that notifies appropriate personnel SHALL be generated on the vote 

capture device, system server, or tabulation device, depending upon which device 

has the error, if a critical event is detected. 

Test Method: Functional 

Test Entity: VSTL 

5.8 Physical and Environmental Security 

5.8.1 Physical Access 

5.8.1.1 Unauthorized physical access requirement 

Any unauthorized physical access SHALL leave physical evidence that an 

unauthorized event has taken place. 

Test Method: Inspection 

Test Entity: VSTL 

5.8.2 Physical Ports and Access Points 

5.8.2.1 Non-essential ports 

The voting system SHALL disable physical ports and access points that are not 

essential to voting operations, testing, and auditing. 

Test Method: Inspection 

Test Entity: VSTL 

5.8.3 Physical Port Protection 

5.8.3.1 Physical port shutdown requirement 

If a physical connection between the vote capture device and a component is 

broken, the affected vote capture device port SHALL be automatically disabled. 

Test Method: Inspection 

Test Entity: VSTL 

5.8.3.2 Physical component alarm requirement 

The voting system SHALL produce a visual alarm if a connected component is 

physically disconnected. 

Test Method: Inspection 

Test Entity: VSTL 

Section 5 | Page 74
5.8 Physical and Environmental Security 

5.8.3.3 Physical component event log requirement 

An event log entry that identifies the name of the affected device SHALL be 

generated if a vote capture device component is disconnected. 

Test Method: Inspection 

Test Entity: VSTL 

5.8.3.4 Physical port enablement requirement 

Disabled ports SHALL only be re-enabled by authorized administrators. 

Test Method: Inspection 

Test Entity: VSTL 

5.8.3.5 Physical port restriction requirement 

Vote capture devices SHALL be designed with the capability to restrict physical 

access to voting device ports that accommodate removable media with the 

exception of ports used to activate a voting session. 

Test Method: Inspection 

Test Entity: VSTL 

5.8.3.6 Physical port tamper evidence requirement 

Vote capture devices SHALL be designed to give a physical indication of tampering 

or unauthorized access to ports and all other access points, if used as described in 

the manufacturer's documentation. 

Test Method: Inspection 

Test Entity: VSTL 

5.8.3.7 Physical port disabling capability requirement 

Vote capture devices SHALL be designed such that physical ports can be manually 

disabled by an authorized administrator. 

Test Method: Inspection 

Test Entity: VSTL 

5.8.4 Door Cover and Panel Security 

5.8.4.1 Access points security requirement 

Access points such as covers and panels SHALL be secured by locks or tamper 

evident or tamper resistant countermeasures and SHALL be implemented so that 

Section 5 | Page 75
5.8 Physical and Environmental Security 

kiosk workers can monitor access to vote capture device components through 

these points. 

Test Method: Inspection 

Test Entity: VSTL 

5.8.5 Secure Paper Record Receptacle 

5.8.5.1 Secure paper record container requirement 

If the voting system provides paper record containers then they SHALL be 

designed such that any unauthorized physical access results in physical evidence 

that an unauthorized event has taken place. 

Test Method: Inspection 

Test Entity: VSTL 

5.8.6 Secure Physical Lock and Key 

5.8.6.1 Secure physical lock access requirement 

Voting equipment SHALL be designed with countermeasures that provide physical 

indication that unauthorized attempts have been made to access locks installed for 

security purposes. 

Test Method: Inspection 

Test Entity: VSTL 

5.8.6.2 Secure locking system key requirement 

Manufacturers SHALL provide locking systems for securing vote capture devices 

that can make use of keys that are unique to each owner. 

Test Method: Inspection 

Test Entity: VSTL 

5.8.7 Media Protection 

These requirements apply to all media, both paper and digital, that contain personal 

privacy related data or other protected or sensitive types of information. 

5.8.7.1 Kiosk site protection 

The voting system SHALL meet the following requirements: 

a. All paper records (including rejected ones) printed at the kiosk locations 

SHALL be deposited in a secure container; 

Section 5 | Page 76
5.9 Penetration Resistance 

b. Vote capture device hardware, software and sensitive information (e.g., 

electoral roll) SHALL be physically protected to prevent unauthorized 

modification or disclosure; and 

c. Vote capture device hardware components, peripherals and removable 

media SHALL be identified and registered by means of a unique serial 

number or other identifier. 

Test Method: Inspection 

Test Entity: VSTL 

5.9 Penetration Resistance 

5.9.1 Resistance to Penetration Attempts 

5.9.1.1 Resistant to attempts 

The voting system SHALL be resistant to attempts to penetrate the system by any 

remote unauthorized entity. 

Test Method: Functional 

Test Entity: VSTL 

5.9.1.2 System information disclosure 

The voting system SHALL be configured to minimize ports, responses and 

information disclosure about the system while still providing appropriate 

functionality. 

Test Method: Functional 

Test Entity: VSTL 

5.9.1.3 System access 

The voting system SHALL provide no access, information or services to 

unauthorized entities. 

Test Method: Functional 

Test Entity: VSTL 

5.9.1.4 Interfaces 

All interfaces SHALL be penetration resistant including TCP/IP, wireless, and 

modems from any point in the system. 

Test Method: Functional 

Test Entity: VSTL 

Section 5 | Page 77
5.9 Penetration Resistance 

5.9.1.5 Documentation 

The configuration and setup to attain penetration resistance SHALL be clearly and 

completely documented. 

Test Method: Functional 

Test Entity: VSTL 

5.9.2 Penetration Resistance Test and Evaluation 

5.9.2.1 Scope 

The scope of penetration testing SHALL include all the voting system components. 

The scope of penetration testing includes but is not limited to the following: 

 System server; 

 Vote capture devices; 

 Tabulation device; 

 All items setup and configured per Technical Data Package (TDP) 

recommendations; 

 Local wired and wireless networks; and 

 Internet connections. 

Test Method: Penetration 

Test Entity: VSTL 

5.9.2.2 Test environment 

Penetration testing SHALL be conducted on a voting system set up in a controlled 

lab environment. Setup and configuration SHALL be conducted in accordance with 

the TDP, and SHALL replicate the real world environment in which the voting 

system will be used. 

Test Method: Penetration 

Test Entity: VSTL 

5.9.2.3 White box testing 

The penetration testing team SHALL conduct white box testing using manufacturer 

supplied documentation and voting system architecture information. 

Documentation includes the TDP and user documentation. The testing team 

SHALL have access to any relevant information regarding the voting system 

configuration. This includes, but is not limited to, network layout and Internet 

Protocol addresses for system devices and components. The testing team SHALL 

be provided any source code included in the TDP. 

Test Method: Penetration 

Test Entity: VSTL 

Section 5 | Page 78
5.9 Penetration Resistance 

5.9.2.4 Focus and priorities 

Penetration testing seeks out vulnerabilities in the voting system that might be used 

to change the outcome of an election, interfere with voter ability to cast ballots, 

ballot counting, or compromise ballot secrecy. The penetration testing team SHALL 

prioritize testing efforts based on the following: 

a. Threat scenarios for the voting system under investigation; 

b. Remote attacks SHALL be prioritized over in-person attacks; 

c. Attacks with a large impact SHALL be prioritized over attacks with a more 

narrow impact; and 

d. Attacks that can change the outcome of an election SHALL be prioritized 

over attacks that compromise ballot secrecy or cause non-selective denial 

of service. 

Test Method: Penetration 

Test Entity: VSTL 

Section 5 | Page 79
6.1 General Requirements 

Section 6: Quality Assurance 

6.1 General Requirements 

At a minimum, this program SHALL: 

a. Include procedures for specifying, procuring, inspecting, accepting, and 

controlling parts and raw materials of the requisite quality; 

b. Require the documentation of the software development process; 

c. Require the documentation of the hardware specification and selection process; 

d. Identify and enforce all requirements for: 

i. In-process inspection and testing that the manufacturer deems 

necessary to ensure proper fabrication and assembly of hardware 

ii. Installation and operation of software and firmware 

e. Include plans and procedures for post-production environmental screening and 

acceptance testing; and 

f. Include a procedure for maintaining all data and records required to document 

and verify the quality inspections and tests. 

Test Method: Inspection 

Test Entity: Manufacturer 

6.2 Components from Third Parties 

A manufacturer who does not manufacture all the components of its voting system, but 

instead procures components as standard commercial items for assembly and integration 

into a voting system, SHALL verify that the supplier manufacturers follow documented 

quality assurance procedures that are at least as stringent as those used internally by the 

voting system manufacturer. 

Test Method: Inspection 

Test Entity: Manufacturer 

6.3 Responsibility for Tests 

Manufacturer SHALL be responsible for performing all quality assurance tests, acquiring 

and documenting test data, and providing test reports for examination by the VSTL as 

part of the national certification process. These reports SHALL also be provided to the 

purchaser upon request. 

Test Method: Inspection 

Test Entity: Manufacturer 

Section 6 | Page 80
6.4 Parts and Materials, Special Tests, and Examinations 

6.4 Parts and Materials, Special Tests, and 

Examinations 

In order to ensure that voting system parts and materials function properly, 

manufacturers SHALL: 

a. Select parts and materials to be used in voting systems and components 

according to their suitability for the intended application. Suitability may be 

determined by similarity of this application to existing standard practice or by 

means of special tests; 

b. Design special tests, if needed, to evaluate the part or material under conditions 

accurately simulating the actual voting system operating environment; and 

c. Maintain the resulting test data as part of the quality assurance program 

documentation. 

Test Method: Inspection 

Test Entity: Manufacturer 

6.5 Quality Conformance Inspections 

The manufacturer performs conformance inspections to ensure the overall quality of the 

voting system and components delivered to the VSTL for national certification testing and 

to the jurisdiction for implementation. To meet the conformance inspection requirements 

the manufacturer SHALL: 

a. Inspect and test each voting system or component to verify that it meets all 

inspection and test requirements for the voting system; and 

b. Deliver a record of tests or a certificate of satisfactory completion with each 

voting system or component. 

Test Method: Inspection 

Test Entity: Manufacturer 

Section 6 | Page 81
7.1 Scope 

Section 7: Configuration Management 

7.1 Scope 

7.1.1 Configuration Management Requirements 

The configuration management documentation provided for manufacturer registration 

SHALL be sufficient for pilot projects. 

Test Method: Inspection 

Test Entity: EAC 

7.1.2 Audit of Configuration Management Documentation 

The manufacturer SHALL provide the following documentation to the EAC for review. 

This documentation will be audited during the registration review which will be 

conducted during the pilot testing period. The items which the EAC will audit are the 

following: 

a. Application of configuration management requirements; 

b. Configuration management policy; 

c. Configuration identification; 

d. Baseline, promotion, and demotion procedures; 

e. Configuration control procedures; 

f. Release process; 

g. Configuration audits; and 

h. Configuration management resources. 

Test Method: Inspection 

Test Entity: EAC 

7.2 Configuration Identification 

Configuration identification is the process of identifying, naming, and acquiring 

configuration items. Configuration identification encompasses all voting system 

components. 

Section 7 | Page 82
7.3 Baseline and Promotion Procedures 

7.2.1 Classification and Naming Configuration Items 

Manufacturers SHALL describe the procedures and conventions used to classify 

configuration items into categories and subcategories, uniquely number or otherwise 

identify configuration items and name configuration items. 

Test Method: Inspection 

Test Entity: Manufacturer 

7.2.2 Versioning Conventions 

When a voting system component is part of a higher level system element such as a 

subsystem, the manufacturer SHALL describe the conventions used to: 

a. Identify the specific versions of individual configuration items and sets of 

items that are incorporated in higher level system elements such as 

subsystems; 

b. Uniquely number or otherwise identify versions; and 

c. Name versions. 

Test Method: Inspection 

Test Entity: Manufacturer 

7.3 Baseline and Promotion Procedures 

Manufacturers SHALL establish formal procedures and conventions for establishing and 

providing a complete description of the procedures and related conventions used to: 

a. Establish a particular instance of a component as the starting baseline; 

b. Promote subsequent instances of a component to baseline status as 

development progresses through to completion of the initial completed version 

released to the VSTL for testing; and 

c. Promote subsequent instances of a component to baseline status as the 

component is maintained throughout its life cycle until system retirement (i.e., the 

system is no longer sold or maintained by the manufacturer). 

Test Method: Inspection 

Test Entity: Manufacturer 

7.4 Configuration Control Procedures 

Configuration control is the process of approving and implementing changes to a 

configuration item to prevent unauthorized additions, changes or deletions. The 

manufacturer SHALL establish such procedures and related conventions, providing a 

complete description of those procedures used to: 

a. Develop and maintain internally developed items; 

Section 7 | Page 83
7.5 Configuration Audits 

b. Acquire and maintain third-party items; 

c. Resolve internally identified defects for items regardless of their origin; and 

d. Resolve externally identified and reported defects (i.e., by customers and 

VSTLs). 

Test Method: Inspection 

Test Entity: Manufacturer 

7.5 Configuration Audits 

7.5.1 Physical Configuration Audit (PCA) 

For the PCA, a manufacturer SHALL provide: 

a. Identification of all items that are to be a part of the pilot release; 

b. Specification of compiler (or choice of compilers) to be used to generate 

voting system executable programs; 

c. Identification of all hardware that interfaces with the software; 

d. Configuration baseline data for all hardware that is unique to the voting 

system; 

e. Copies of all software documentation intended for distribution to users, 

including program listings, specifications, operations manual, voter manual, 

and maintenance manual; 

f. Identification of any changes between the physical configuration of the voting 

system submitted for the PCA and that submitted for the Functional 

Configuration Audit (FCA), with a certification that any differences do not 

degrade the functional characteristics; and 

g. Complete descriptions of its procedures and related conventions used to 

support this audit by 

i. Establishing a configuration baseline of the software and hardware to 

be tested; and 

ii. Confirming whether the voting system documentation matches the 

corresponding system components. 

Test Method: Inspection 

Test Entity: VSTL 

7.5.2 Functional Configuration Audit (FCA) 

The Functional Configuration Audit is conducted by the VSTL to verify that the voting 

system performs all the functions described in the system documentation. 

Manufacturers SHALL: 

a. Completely describe its procedures and related conventions used to support 

this audit for all voting system components; and 

b. Provide the following information to support this audit: 

Section 7 | Page 84
7.5 Configuration Audits 

c. Copies of all procedures used for module or unit testing, integration testing, 

and system testing; 

d. Copies of all test cases generated for each module and integration test, and 

sample ballot formats or other test cases used for system tests; and 

e. Records of all tests performed by the procedures listed above, including error 

corrections and retests. 

Test Method: Functional / Inspection 

Test Entity: VSTL 

Section 7 | Page 85
8.1 Scope 

Section 8: Technical Data Package 

8.1 Scope 

This section contains a description of manufacturer documentation relating to the voting 

system that must be submitted with the system as a precondition of conformity 

assessment. These items are necessary to define the product and its method of 

operation; to provide technical and test data supporting the manufacturer's claims of the 

system's functional capabilities and performance levels; and to document instructions 

and procedures governing system operation and field maintenance. Any other items 

relevant to the system evaluation, such as media, materials, source code, object code, 

and sample output report formats, must be submitted along with this documentation. 

This documentation is used by the VSTL in constructing the test plan. Testing of systems 

submitted by manufacturers that consistently adhere to particularly strong and welldocumented quality assurance and configuration management practices will generally be 

more efficient than for systems developed and maintained using less rigorous or less 

well-documented practices. 

Both formal documentation and notes of the manufacturer's system development process 

must be submitted for conformity assessment. Documentation describing the system 

development process permits assessment of the manufacturer's systematic efforts to 

develop and test the system and correct defects. Inspection of this process also enables 

the design of a more precise test plan. The VSTL must design and conduct the 

appropriate tests to cover all elements of the system and to ensure conformance with all 

system requirements. 

8.1.1 Content and Format 

The content of the Technical Data Package (TDP) is intended to provide clear, 

complete descriptions of the following information about the voting system: 

 Overall system design, including subsystems, modules and the interfaces 

among them; 

 Specific functional capabilities provided by the system; 

 Performance and design specifications; 

 Design constraints, applicable standards, and compatibility requirements; 

 Personnel, equipment, and facility requirements for system operation, 

maintenance, and logistical support; 

 Manufacturer practices for assuring system quality during the system's 

development and subsequent maintenance; and 

 Manufacturer practices for managing the configuration of the system during 

development and for modifications to the system throughout its life cycle. 

Section 8 | Page 86
8.1 Scope 

8.1.1.1 Required content for initial conformity assessment 

8.1.1.1.1 Identify full system configuration 

Manufacturers SHALL submit to the VSTL documentation necessary for the 

identification of the full system configuration submitted for evaluation and for 

the development of an appropriate test plan by the VSTL. 

Test Method: Inspection 

Test Entity: Manufacturer 

8.1.1.1.2 Required content for pilot certification 

Manufacturers SHALL provide a list of all documents submitted controlling the 

design, construction, operation, and maintenance of the voting system. At 

minimum, the TDP SHALL contain the following documentation: 

 Implementation statement; 

 Voting system user documentation (See Section 9 Voting Equipment 

User Documentation); 

 System hardware specification; 

 Application logic design and specification; 

 System security specification; 

 System test specification; 

 Configuration for testing; and 

 Training documentation. 

Test Method: Inspection 

Test Entity: Manufacturer 

8.1.1.2 Format 

The requirements for formatting the TDP are general in nature; specific format 

details are of the manufacturer's choosing. 

8.1.1.2.1 Table of contents and abstracts 

The TDP SHALL include a detailed table of contents for the required 

documents, an abstract of each document, and a listing of each of the 

informational sections and appendices presented. 

Test Method: Inspection 

Test Entity: Manufacturer 

8.1.1.2.2 Cross-index 

A cross-index SHALL be provided indicating the portions of the documents that 

are responsive to the documentation requirements enumerated in section 

8.1.1.1.2. 

Section 8 | Page 87
8.2 Implementation Statement 

Test Method: Inspection 

Test Entity: Manufacturer 

8.1.2 Protection of Proprietary Information 

8.1.2.1 Identify proprietary data 

Manufacturers SHALL identify all documents, or portions of documents, containing 

proprietary information that is not releasable to the public. 

Test Method: Inspection 

Test Entity: Manufacturer 

8.2 Implementation Statement 

8.2.1 TDP Implementation Statement 

The TDP SHALL include an implementation statement. 

Test Method: Inspection 

Test Entity: Manufacturer 

8.3 System Hardware Specification 

8.3.1 System Hardware Specification Scope 

Manufacturers SHALL expand on the system overview included in the user 

documentation by providing detailed specifications of the hardware components of 

the voting system, including specifications of hardware used to support the 

telecommunications capabilities of the voting system, if applicable. 

Test Method: Inspection 

Test Entity: Manufacturer 

8.3.2 System Hardware Characteristics 

8.3.2.1 Description of hardware characteristics 

Manufacturers SHALL provide a detailed discussion of the characteristics of the 

system, indicating how the hardware meets individual requirements defined in this 

document, including: 

a. Performance characteristics: Basic system performance attributes and 

operational scenarios that describe the manner in which system functions 

are invoked, describe environmental capabilities, describe life expectancy, 

and describe any other essential aspects of system performance; 

Section 8 | Page 88
8.3 System Hardware Specification 

b. Physical characteristics: Suitability for intended use, requirements for 

security criteria, and vulnerability to adverse environmental factors; 

c. Reliability: System and component reliability stated in terms of the 

system's operating functions, and identification of items that require special 

handling or operation to sustain system reliability; and 

d. Environmental conditions: Ability of the system to withstand natural 

environments, and operational constraints in normal and test 

environments, including all requirements and restrictions regarding 

electrical service, telecommunications services, environmental protection, 

and any additional facilities or resources required to install and operate the 

system. 

Test Method: Inspection 

Test Entity: Manufacturer 

8.3.3 Design and Construction 

8.3.3.1 System configuration 

Manufacturers SHALL provide sufficient data, or references to data, to identify 

unequivocally the details of the system configuration submitted for testing. 

Test Method: Inspection 

Test Entity: Manufacturer 

8.3.3.2 Photographs for hardware validation 

Manufacturers SHALL provide photographs of the exterior and interior of devices 

included in the system to identify the hardware of the system configuration 

submitted for testing. 

Test Method: Inspection 

Test Entity: Manufacturer 

8.3.3.3 List of materials 

Manufacturers SHALL provide a list of materials and components used in the 

system and a description of their assembly into major system components and the 

system as a whole. 

Test Method: Inspection 

Test Entity: Manufacturer 

8.3.3.4 Design and construction miscellany 

Text and diagrams SHALL be provided that describe: 

a. Materials, processes, and parts used in the system, their assembly, and 

the configuration control measures to ensure compliance with the system 

specification; 

Section 8 | Page 89
8.4 Application Logic Design and Specification 

b. Electromagnetic environment generated by the system; and 

c. Operator and voter safety considerations and any constraints on system 

operations or the use environment. 

Test Method: Inspection 

Test Entity: Manufacturer 

8.3.4 Hardwired Logic 

8.3.4.1 Hardwired and mechanical implementations of logic 

For each non-COTS hardware component (e.g., an application-specific integrated 

circuit or a manufacturer-specific integration of smaller components), 

manufacturers SHALL provide complete design and logic specifications, such as 

Computer Aided Design and Hardware Description Language files. 

Test Method: Inspection 

Test Entity: Manufacturer 

8.3.4.2 Logic specifications for PLDs, FPGAs and PICs 

For each Programmable Logic Device (PLD), Field-Programmable Gate Array 

(FPGA), or Peripheral Interface Controller (PIC) that is programmed with nonCOTS logic, manufacturers SHALL provide complete logic specifications, such as 

Hardware Description Language files or source code. 

Test Method: Inspection 

Test Entity: Manufacturer 

8.4 Application Logic Design and Specification 

8.4.1 Application Logic Design and Specification 

Manufacturers SHALL expand on the system overview included in the user 

documentation by providing detailed specifications of the application logic 

components of the system, including those used to support the telecommunications 

capabilities of the system, if applicable. 

Test Method: Inspection 

Test Entity: Manufacturer 

Section 8 | Page 90
8.4 Application Logic Design and Specification 

8.4.2 Purpose and Scope 

8.4.2.1 Application logic functions 

Manufacturers SHALL describe the function or functions that are performed by the 

application logic comprising the system, including that used to support the 

telecommunications capabilities of the system, if applicable. 

Test Method: Inspection 

Test Entity: Manufacturer 

8.4.3 Applicable Documents 

8.4.3.1 Documents controlling application logic development 

Manufacturers SHALL list all documents controlling the development of application 

logic and its specifications. 

Test Method: Inspection 

Test Entity: Manufacturer 

8.4.4 Application Logic Overview 

8.4.4.1 Application logic overview 

Manufacturers SHALL provide an overview of the application logic. 

Test Method: Inspection 

Test Entity: Manufacturer 

8.4.4.2 Application logic architecture 

The overview SHALL include a description of the architecture, the design 

objectives, and the logic structure and algorithms used to accomplish those 

objectives. 

Test Method: Inspection 

Test Entity: Manufacturer 

8.4.4.3 Application logic design 

The overview SHALL include the general design, operational considerations, and 

constraints influencing the design. 

Test Method: Inspection 

Test Entity: Manufacturer 

Section 8 | Page 91
8.4 Application Logic Design and Specification 

8.4.4.4 Application logic overview miscellany 

The overview SHALL include the following additional information for each separate 

software package: 

a. Package identification; 

b. General description; 

c. Requirements satisfied by the package; 

d. Identification of interfaces with other packages that provide data to, or 

receive data from, the package; and 

e. Concept of execution for the package. 

Test Method: Inspection 

Test Entity: Manufacturer 

8.4.5 Application Logic Standards and Conventions 

8.4.5.1 Application logic standards and conventions 

Manufacturers SHALL provide information on application logic standards and 

conventions developed internally by the manufacturer as well as published industry 

standards that have been applied by the manufacturer. 

Test Method: Inspection 

Test Entity: Manufacturer 

8.4.5.2 Application logic standards and conventions, checklist 

Manufacturers SHALL provide information that addresses the following standards 

and conventions related to application logic: 

a. Development methodology; 

b. Design standards, including internal manufacturer procedures; 

c. Specification standards, including internal manufacturer procedures; 

d. Coding conventions, including internal manufacturer procedures; 

e. Testing and verification standards, including internal manufacturer 

procedures, that can assist in determining the correctness of the logic; and 

f. Quality assurance standards or other documents that can be used to 

examine and test the application logic. These documents include 

standards for logic diagrams, program documentation, test planning, and 

test data acquisition and reporting. 

Test Method: Inspection 

Test Entity: Manufacturer 

Section 8 | Page 92
8.4 Application Logic Design and Specification 

8.4.5.3 Justify coding conventions 

Manufacturers SHALL furnish evidence that the selected coding conventions are 

"published" and "credible" as specified in section 4.3.1. 

Test Method: Inspection 

Test Entity: Manufacturer 

8.4.6 Application Logic Operating Environment 

8.4.6.1 Application logic operating environment 

Manufacturers SHALL describe or make reference to all operating environment 

factors that influence the design of application logic. 

Test Method: Inspection 

Test Entity: Manufacturer 

8.4.7 Hardware Environment and Constraints 

8.4.7.1 Hardware environment and constraints 

Manufacturers SHALL identify and describe the hardware characteristics that 

influence the design of the application logic, such as: 

a. Logic and arithmetic capability of the processor; 

b. Memory read-write characteristics; 

c. External memory device characteristics; 

d. Peripheral device interface hardware; 

e. Data input/output device protocols; and 

f. Operator controls, indicators, and displays. 

Test Method: Inspection 

Test Entity: Manufacturer 

8.4.8 Application Logic Environment 

8.4.8.1 Operating system 

Manufacturers SHALL identify the operating system and the specific version 

thereof, or else clarify how the application logic operates without an operating 

system. 

Test Method: Inspection 

Test Entity: Manufacturer 

Section 8 | Page 93
8.4 Application Logic Design and Specification 

8.4.8.2 Compilers and assemblers 

For systems containing compiled or assembled application logic, manufacturers 

SHALL identify the COTS compilers or assemblers used in the generation of 

executable code, and the specific versions thereof. 

Test Method: Inspection 

Test Entity: Manufacturer 

8.4.8.3 Interpreters 

For systems containing interpreted application logic, manufacturers SHALL specify 

the COTS runtime interpreter that SHALL be used to run this code, and the specific 

version thereof. 

Test Method: Inspection 

Test Entity: Manufacturer 

8.4.9 Application Logic Functional Specification 

8.4.9.1 Application logic functional specification 

Manufacturers SHALL provide a description of the operating modes of the system 

and of application logic capabilities to perform specific functions. 

Test Method: Inspection 

Test Entity: Manufacturer 

8.4.10 Functions and Operating Modes 

8.4.10.1 Functions and operating modes 

Manufacturers SHALL describe all application logic functions and operating modes 

of the system, such as ballot preparation, election programming, preparation for 

opening the voting period, recording votes and/or counting ballots, closing the 

voting period, and generating reports. 

Test Method: Inspection 

Test Entity: Manufacturer 

8.4.10.2 Functions and operating modes detail 

For each application logic function or operating mode, manufacturers SHALL 

provide: 

a. A definition of the inputs to the function or mode (with characteristics, 

limits, tolerances or acceptable ranges, as applicable); 

b. An explanation of how the inputs are processed; and 

Section 8 | Page 94
8.4 Application Logic Design and Specification 

c. A definition of the outputs produced (again, with characteristics, limits, 

tolerances, or acceptable ranges, as applicable). 

Test Method: Inspection 

Test Entity: Manufacturer 

8.4.11 Application Logic Integrity Features 

8.4.11.1 Application logic integrity features 

Manufacturers SHALL describe the application logic's capabilities or methods for 

detecting or handling: 

a. Exception conditions; 

b. System failures; 

c. Data input/output errors; 

d. Error logging for audit record generation; 

e. Production of statistical ballot data; 

f. Data quality assessment; and 

g. Security monitoring and control. 

Test Method: Inspection 

Test Entity: Manufacturer 

8.4.12 Programming Specifications 

8.4.12.1 Programming specifications 

Manufacturers SHALL provide in this section an overview of the application logic's 

design, its structure, and implementation algorithms and detailed specifications for 

individual modules. 

Test Method: Inspection 

Test Entity: Manufacturer 

8.4.13 Programming Specifications Overview 

The programming specifications overview SHALL document the architecture of the 

application logic. 

8.4.13.1 Programming specifications overview, diagrams 

This overview SHALL include such items as Unified Modeling Language diagrams, 

data flow diagrams, and/or other graphical techniques that facilitate understanding 

of the programming specifications. 

Test Method: Inspection 

Section 8 | Page 95
8.4 Application Logic Design and Specification 

Test Entity: Manufacturer 

8.4.13.2 Internal functioning of individual modules 

This section SHALL be prepared to facilitate understanding of the internal 

functioning of the individual modules. 

Test Method: Inspection 

Test Entity: Manufacturer 

8.4.13.3 Programming specifications overview, content 

Implementation of the functions SHALL be described in terms of the architecture, 

algorithms, and data structures. 

Test Method: Inspection 

Test Entity: Manufacturer 

8.4.14 Programming Specifications Details 

8.4.14.1 Programming specifications details 

The programming specifications SHALL describe individual application logic 

modules and their component units, if applicable. 

Test Method: Inspection 

Test Entity: Manufacturer 

8.4.14.2 Module and callable unit documentation 

For each application logic module and callable unit, manufacturers SHALL 

document: 

a. Significant module and unit design decisions, if any, such as algorithms 

used; 

b. Any constraints, limitations, or unusual features in the design of the module 

or callable unit; and 

c. A description of its inputs, outputs, and other data elements as applicable 

with respect to communication over system interfaces. (See section 8.4.16 

Interfaces.) 

Test Method: Inspection 

Test Entity: Manufacturer 

8.4.14.3 Mixed-language software 

If an application logic module is written in a programming language other than that 

generally used within the system, the specification for the module SHALL indicate 

the programming language used and the reason for the difference. 

Section 8 | Page 96
8.4 Application Logic Design and Specification 

Test Method: Inspection 

Test Entity: Manufacturer 

8.4.14.4 References for foreign programming languages 

If a module contains embedded border logic commands for an external library or 

package (e.g., menu selections in a database management system for defining 

forms and reports, on-line queries for database access and manipulation, input to a 

graphical user interface builder for automated code generation, commands to the 

operating system, or shell scripts), the specification for the module SHALL contain 

a reference to user manuals or other documents that explain them. 

Test Method: Inspection 

Test Entity: Manufacturer 

8.4.14.5 Source code 

For each callable unit (e.g., function, method, operation, subroutine, procedure) in 

application logic, border logic, and third-party logic, manufacturers SHALL supply 

the source code. 

Test Method: Inspection 

Test Entity: Manufacturer 

8.4.14.6 Inductive assertions 

For each callable unit (e.g., function, method, operation, subroutine, procedure) in 

core logic, manufacturers SHALL specify: 

a. Preconditions and postconditions of the callable unit, including any 

assumptions about capacities and limits within which the system is 

expected to operate; and 

b. A sound argument (preferably, but not necessarily, a formal proof) that the 

preconditions and postconditions of the callable unit accurately represent 

its behavior, assuming that the preconditions and postconditions of any 

invoked units are similarly accurate. 

Test Method: Inspection 

Test Entity: Manufacturer 

8.4.14.7 High-level constraints 

Manufacturers SHALL specify a sound argument (preferably, but not necessarily, a 

formal proof) that the core logic as a whole satisfies each of the constraints for all 

cases within the aforementioned capacities and limits, assuming that the 

preconditions and postconditions of callable units accurately characterize their 

behaviors. 

Test Method: Inspection 

Test Entity: Manufacturer 

Section 8 | Page 97
8.4 Application Logic Design and Specification 

8.4.14.8 Safety of concurrency 

Manufacturers SHALL specify a sound argument (preferably, but not necessarily, a 

formal proof) that application logic is free of race conditions, deadlocks, livelocks, 

and resource starvation. 

Test Method: Inspection 

Test Entity: Manufacturer 

8.4.15 System Database 

8.4.15.1 System database 

Manufacturers SHALL identify and provide a diagram and narrative description of 

the system's databases and any external files used for data input or output. 

Test Method: Inspection 

Test Entity: Manufacturer 

8.4.15.2 Database design levels 

For each database or external file, manufacturers SHALL specify the number of 

levels of design and the names of those levels (e.g., conceptual, internal, logical, 

and physical). 

Test Method: Inspection 

Test Entity: Manufacturer 

8.4.15.3 Database design conventions 

For each database or external file, the manufacturer SHALL specify any design 

conventions and standards (which may be incorporated by reference) needed to 

understand the design. 

Test Method: Inspection 

Test Entity: Manufacturer 

8.4.15.4 Data models 

For each database or external file, manufacturers SHALL identify and describe all 

logical entities and relationships and how these are implemented physically (e.g., 

tables, files). 

Test Method: Inspection 

Test Entity: Manufacturer 

8.4.15.5 Schemata 

Manufacturers SHALL document the details of table, record or file contents (as 

applicable), individual data elements and their specifications, including: 

Section 8 | Page 98
8.4 Application Logic Design and Specification 

a. Names/identifiers; 

b. Data type (e.g., alphanumeric, integer); 

c. Size and format (such as length and punctuation of a character string); 

d. Units of measurement (e.g., meters, seconds 

e. Range or enumeration of possible values (e.g., 0–99 

f. Accuracy (how correct) and precision (number of significant digits); 

g. Priority, timing, frequency, volume, sequencing, and other constraints, such 

as whether the data element may be updated and whether business rules 

apply; 

h. Security and privacy constraints; and 

i. Sources (setting/sending entities) and recipients (using/receiving entities). 

Test Method: Inspection 

Test Entity: Manufacturer 

8.4.15.6 External file maintenance and security 

For external files, manufacturers SHALL document the procedures for file 

maintenance, management of access privileges, and security. 

Test Method: Inspection 

Test Entity: Manufacturer 

8.4.16 Interfaces 

8.4.16.1 Description of interfaces 

Using a combination of text and diagrams, manufacturers SHALL identify and 

provide a complete description of all major internal and external interfaces. 

Test Method: Inspection 

Test Entity: Manufacturer 

8.4.17 Interface Identification 

8.4.17.1 Interface identification details 

For each interface identified in the system overview, manufacturers SHALL: 

a. Provide a unique identifier assigned to the interface; 

b. Identify the interfacing entities (e.g., systems, configuration items, users) 

by name, number, version, and documentation references, as applicable; 

and 

c. Identify which entities have fixed interface characteristics (and therefore 

impose interface requirements on interfacing entities) and which are being 

Section 8 | Page 99
8.4 Application Logic Design and Specification 

developed or modified (thus having interface requirements imposed upon 

them). 

Test Method: Inspection 

Test Entity: Manufacturer 

8.4.18 Interface Description 

8.4.18.1 Interface types 

For each interface identified in the system overview, manufacturers SHALL 

describe the type of interface (e.g., real-time data transfer, data storage-andretrieval) to be implemented. 

Test Method: Inspection 

Test Entity: Manufacturer 

8.4.18.2 Interface signatures 

For each interface identified in the system overview, manufacturers SHALL 

describe characteristics of individual data elements that the interfacing entity (ies) 

will provide, store, send, access, receive, etc., such as: 

a. Names/identifiers; 

b. Data type (e.g., alphanumeric, integer); 

c. Size and format (such as length and punctuation of a character string); 

d. Units of measurement (e.g., meters, seconds); 

e. Range or enumeration of possible values (e.g., 0–99); 

f. Accuracy (how correct) and precision (number of significant digits); 

g. Priority, timing, frequency, volume, sequencing, and other constraints, such 

as whether the data element may be updated and whether business rules 

apply; 

h. Security and privacy constraints; and 

i. Sources (setting/sending entities) and recipients (using/receiving entities). 

Test Method: Inspection 

Test Entity: Manufacturer 

8.4.18.3 Interface protocols 

For each interface identified in the system overview, manufacturers SHALL 

describe characteristics of communication methods that the interfacing entity (ies) 

will use for the interface, such as: 

a. Communication links/bands/frequencies/media and their characteristics; 

b. Message formatting; 

c. Flow control (e.g., sequence numbering and buffer allocation); 

Section 8 | Page 100
8.4 Application Logic Design and Specification 

d. Data transfer rate, whether periodic/aperiodic, and interval between 

transfers; 

e. Routing, addressing, and naming conventions; 

f. Transmission services, including priority and grade; and 

g. Safety/security/privacy considerations, such as encryption, user 

authentication, compartmentalization, and auditing. 

Test Method: Inspection 

Test Entity: Manufacturer 

8.4.18.4 Protocol details 

For each interface identified in the system overview, manufacturers SHALL 

describe characteristics of protocols the interfacing entity (ies) will use for the 

interface, such as: 

a. Priority/layer of the protocol; 

b. Packeting, including fragmentation and reassembly, routing, and 

addressing; 

c. Legality checks, error control, and recovery procedures; 

d. Synchronization, including connection establishment, maintenance, 

termination; and 

e. Status, identification, and any other reporting features. 

Test Method: Inspection 

Test Entity: Manufacturer 

8.4.18.5 Characteristics of interfaces 

For each interface identified in the system overview, manufacturers SHALL 

describe any other pertinent characteristics, such as physical compatibility of the 

interfacing entity (ies) (e.g., dimensions, tolerances, loads, voltages, plug 

compatibility). 

Test Method: Inspection 

Test Entity: Manufacturer 

8.4.19 Appendices 

Manufacturers SHALL provide descriptive material and data supplementing the 

various sections of the body of the logic specifications. The content and arrangement 

of appendices are at the discretion of the manufacturer. Topics recommended for 

amplification or treatments in appendix form include: 

 Glossary: A listing and brief definition of all module names and variable 

names, with reference to their locations in the logic structure. Abbreviations, 

acronyms, and terms should be included, if they are either uncommon in data 

processing and software development or are used with an unorthodox 

meaning; 

Section 8 | Page 101
8.5 System Security Specification 

 References: A list of references to all related manufacturer documents, data, 

standards, and technical sources used in logic development and testing; and 

 Program Analysis: The results of logic configuration analysis, algorithm 

analysis and selection, timing studies, and hardware interface studies that 

are reflected in the final logic design and coding. 

Test Method: Inspection 

Test Entity: Manufacturer 

8.5 System Security Specification 

This section defines the security documentation requirements for systems. These 

recommendations apply to the full scope of system functionality, including functionality for 

defining the ballot and other pre-voting functions, as well as functions for casting and 

storing votes, vote reporting, system logging, and maintenance of the system. User 

documentation includes all public information that is provided to end users. The 

Technical Data Package (TDP) includes the user documentation along with proprietary 

information that is viewed only by the VSTL. 

8.5.1 General 

8.5.1.1 Overall security 

Manufacturers SHALL document in the TDP all aspects of system design, 

development, and proper usage that are relevant to system security. This includes, 

but is not limited to the following: 

 System security objectives; 

 All hardware and software security mechanisms; 

 All cryptographic algorithms, protocols and schemes that are used; 

 Development procedures employed to ensure absence of malicious code; 

 Initialization, usage, and maintenance procedures necessary to secure 

operation; 

 All attacks the system is designed to resist or detect; and 

 Any security vulnerabilities known to the manufacturer. 

Test Method: Inspection 

Test Entity: Manufacturer 

8.5.1.2 High level security 

Manufacturers SHALL provide at a minimum the high-level documents listed in 

Table 8-1 as part of the TDP. 

Test Method: Inspection 

Test Entity: Manufacturer 

Table 8-1 High level system documentation 

Section 8 | Page 102
8.5 System Security Specification 

DOCUMENT DESCRIPTION

Security Threats Controls This document identifies the threats the system protects against and the 

implemented security controls on the system and system components. 

Security Architecture 

This document provides an architecture level description of how the 

security requirements are met, and SHALL include the various 

authentication, access control, audit, confidentiality, integrity, and 

availability requirements. 

Interface Specification This document describes external interfaces (programmatic, human, and 

network) provided by each of the components of the system. 

Design Specification This document provides a high-level design of each system component. 

Development Environment 

Specification 

This document provides descriptions of the physical, personnel, 

procedural, and technical security of the development environment 

including configuration management, tools used, coding standards used, 

software engineering model used, and description of developer and 

independent testing. 

Security Testing and 

Vulnerability Analysis 

Documentation 

This document describes security tests performed to identify vulnerabilities 

and the results of the testing. This also includes testing performed as part 

of software development, such as unit, module, and subsystem testing. 

8.5.2 Access Control 

8.5.2.1 General user 

Manufacturers SHALL provide user documentation of access control capabilities of 

the system. 

Test Method: Inspection 

Test Entity: Manufacturer 

8.5.2.2 General access control technical specification 

Manufacturers SHALL provide descriptions and specifications of all access control 

mechanisms of the system including management capabilities of authentication, 

authorization, and passwords. 

Test Method: Inspection 

Test Entity: Manufacturer 

8.5.2.3 Unauthorized access technical specification 

Manufacturers SHALL provide descriptions and specifications of methods to 

prevent unauthorized access to the access control mechanisms of the system. 

Test Method: Inspection 

Test Entity: Manufacturer 

Section 8 | Page 103
8.5 System Security Specification 

8.5.2.4 Access control dependent system mechanisms 

Manufacturers SHALL provide descriptions and specifications of all system 

mechanisms that are dependent upon, support, and interface with access controls. 

Test Method: Inspection 

Test Entity: Manufacturer 

8.5.2.5 Voting operations and roles 

Manufacturers SHALL provide a list of all of the operations possible on the voting 

system and list the default roles that have permission to perform each such 

operation. 

Test Method: Inspection 

Test Entity: Manufacturer 

8.5.2.6 Critical event escalation 

Manufacturers SHALL document a prioritized critical event escalation list of 

appropriate personnel to be notified. 

Test Method: Inspection 

Test Entity: Manufacturer 

8.5.3 System Event Logging 

8.5.3.1 General 

Manufacturers SHALL provide documentation of event logging capabilities of the 

system. 

Test Method: Inspection 

Test Entity: Manufacturer 

8.5.4 Software Installation 

8.5.4.1 Software list 

Manufacturers SHALL provide a list of all software related to the system. 

Test Method: Inspection 

Test Entity: Manufacturer 

Section 8 | Page 104
8.5 System Security Specification 

8.5.4.2 Software information 

Manufacturers SHALL provide, at a minimum, the following information for each 

piece of software related to the system: 

 Software product name; 

 Software version number; 

 Software manufacturer name; 

 Software manufacturer contact information; 

 Type of software (application logic, border logic, third party logic, COTS 

software, or installation software); 

 List of software documentation; 

 Component identifier(s) (such as filename(s)) of the software; and 

 Type of software component (executable code, source code, or data). 

Test Method: Inspection 

Test Entity: Manufacturer 

8.5.4.3 Software location information 

Manufacturers SHALL provide the location (such as full path name or memory 

address) and storage device (such as type and part number of storage device) 

where each piece of software is installed on programmed devices of the system. 

Test Method: Inspection 

Test Entity: Manufacturer 

8.5.4.4 Software functionality for programmed devices 

Manufacturers SHALL document the functionality provided to the system by the 

software installed on programmed devices. 

Test Method: Inspection 

Test Entity: Manufacturer 

8.5.4.5 Software dependencies and interaction 

Manufacturers SHALL map the dependencies and interactions between software 

installed on programmed devices. 

Test Method: Inspection 

Test Entity: Manufacturer 

8.5.4.6 Build environment software and hardware 

Manufacturers SHALL provide a list of all software and hardware required to 

assemble the build environment used to create system software executable code 

including application logic, border logic, and third party logic. 

Section 8 | Page 105
8.5 System Security Specification 

Test Method: Inspection 

Test Entity: Manufacturer 

8.5.4.7 Build environment assembly procedures 

Manufacturers SHALL document the procedures to assemble the build 

environment(s) used to create system software executable code including 

application logic, border logic, and third party logic. 

Test Method: Inspection 

Test Entity: Manufacturer 

8.5.4.8 System software build procedures 

Manufacturers SHALL document the procedures used to build the system software 

executable code including application logic, border logic, and third party logic. 

Test Method: Inspection 

Test Entity: Manufacturer 

8.5.5 Physical Security 

8.5.5.1 Unauthorized physical access 

Manufacturers SHALL provide a list of all system components to which access 

must be restricted and a description of the function of each such component. 

Test Method: Inspection 

Test Entity: Manufacturer 

8.5.5.2 Physical port and access point 

Manufacturers SHALL provide a listing of all ports and access points. 

Test Method: Inspection 

Test Entity: Manufacturer 

8.5.5.3 Physical lock use 

For each lock, manufacturers SHALL document whether the lock was installed to 

secure an access point. 

Test Method: Inspection 

Test Entity: Manufacturer 

Section 8 | Page 106
8.5 System Security Specification 

8.5.5.4 Power usage 

Manufacturer SHALL provide a list of all physical security countermeasures that 

require power supplies. 

Test Method: Inspection 

Test Entity: Manufacturer 

8.5.5.5 Physical security 

Manufacturer SHALL document the design and implementation of all physical 

security controls for the system and its components. 

Test Method: Inspection 

Test Entity: Manufacturer 

8.5.6 System Integrity Management 

8.5.6.1 Binaries per system 

Manufacturers SHALL provide a list of the binaries that are required to be executed 

on the system devices. 

Test Method: Inspection 

Test Entity: Manufacturer 

8.5.7 Setup Inspection 

8.5.7.1 Software integrity verification 

Manufacturers SHALL provide a technical specification of how the integrity of 

software installed on programmed devices of the system is verified. 

Test Method: Inspection 

Test Entity: Manufacturer 

8.5.7.2 Software integrity verification technique software nonmodification 

Manufacturers SHALL provide documentation of software integrity verification 

techniques that prevent the modification of software installed on programmed 

devices of the system. 

Test Method: Inspection 

Test Entity: Manufacturer 

Section 8 | Page 107
8.5 System Security Specification 

8.5.7.3 Register and variable value inspection 

Manufacturers SHALL provide a technical specification of how the inspection of all 

the system registers and variables is implemented by the system. 

Test Method: Inspection 

Test Entity: Manufacturer 

8.5.7.4 Backup power inspection 

Manufacturers SHALL provide a technical specification of how the inspection of the 

remaining charge of the backup power sources is implemented by the system. 

Test Method: Inspection 

Test Entity: Manufacturer 

8.5.7.5 Cabling connectivity inspection 

Manufacturers SHALL provide a technical specification of how the inspection of the 

connectivity of cabling attached is implemented by the system. 

Test Method: Inspection 

Test Entity: Manufacturer 

8.5.7.6 Communications operational status inspection 

Manufacturers SHALL provide a technical specification of how the inspection of the 

operational status of the communications capability is implemented by the system. 

Test Method: Inspection 

Test Entity: Manufacturer 

8.5.7.7 Communications on/off inspection 

Manufacturers SHALL provide a technical specification of how the inspection of the 

on/off status of the communications capability is implemented by the system. 

Test Method: Inspection 

Test Entity: Manufacturer 

8.5.7.8 Consumable inspection 

Manufacturers SHALL provide a technical specification of how the inspection of the 

remaining amount of each consumable is implemented by the system. 

Test Method: Inspection 

Test Entity: Manufacturer 

Section 8 | Page 108
8.6 Test Specifications 

8.5.7.9 Calibration of voting device components inspection 

Manufacturers SHALL provide a technical specification of how the inspection of the 

calibration for each component is implemented by the system. 

Test Method: Inspection 

Test Entity: Manufacturer 

8.5.7.10 Calibration of voting device components adjustment 

Manufacturers SHALL provide a technical specification of how the adjustment to 

the calibration of each component is implemented by the system. 

Test Method: Inspection 

Test Entity: Manufacturer 

8.6 Test Specifications 

Manufacturers SHALL provide test specifications for: 

a. Development test specifications; and 

b. System test specifications. 

Test Method: Inspection 

Test Entity: Manufacturer 

8.6.1 Development Test Specifications 

8.6.1.1 Development test specifications 

Manufacturers SHALL describe the plans, procedures, and data used during 

development and system integration to verify system logic correctness, data 

quality, and security. This description SHALL include: 

a. Test identification and design, including test structure, test sequence or 

progression, and test conditions; 

b. Standard test procedures, including any assumptions or constraints; 

c. Special purpose test procedures including any assumptions or constraints; 

d. Test data, including the data source, whether it is real or simulated, and 

how test data are controlled; 

e. Expected test results; and 

f. Criteria for evaluating test results. 

Test Method: Inspection 

Test Entity: Manufacturer 

Section 8 | Page 109
8.7 Configuration for Testing 

8.6.2 System Test Specifications 

8.6.2.1 Specifications for verification and validation of system 

performance 

Manufacturers SHALL provide specifications for verification and validation of 

overall system performance. These specifications SHALL cover: 

a. Control and data input/output; 

b. Processing accuracy; 

c. Data quality assessment and maintenance; 

d. Ballot interpretation logic; 

e. Exception handling; 

f. Security; 

g. Production of audit trails and statistical data; 

h. Expected test results; and 

i. Criteria for evaluating test results. 

Test Method: Inspection 

Test Entity: Manufacturer 

8.6.2.2 Demonstrate fitness for purpose 

The specifications SHALL identify procedures for assessing and demonstrating the 

suitability of the system for election use. 

Test Method: Inspection 

Test Entity: Manufacturer 

8.7 Configuration for Testing 

8.7.1 Configuration Description 

Configuration of hardware and software, both operating systems and applications, is 

critical to proper system functioning. Correct test design and sufficient test execution 

must account for the intended and proper configuration of all system components. If 

the system can be set up in both conforming and nonconforming configurations, the 

configuration actions necessary to obtain conforming behavior must be specified. 

8.7.1.1 Hardware set-up 

Manufacturers SHALL provide instructions and photographs illustrating the proper 

set up of the system hardware. 

Test Method: Inspection 

Test Entity: Manufacturer 

Section 8 | Page 110
8.7 Configuration for Testing 

8.7.1.2 Provide answers to installation prompts 

Manufacturers SHALL provide a record of all user selections that must be made 

during software/firmware installation for the system to meet the requirements of the 

UOCAVA Pilot Testing Requirements. 

Test Method: Inspection 

Test Entity: Manufacturer 

8.7.1.3 Configuration data 

Manufacturers SHALL submit all configuration data needed to set up and operate 

the system. 

Test Method: Inspection 

Test Entity: Manufacturer 

Section 8 | Page 111
9.1 Scope 

Section 9: System Users Manual 

9.1 Scope 

This section contains requirements on the content of the documentation that 

manufacturers supply to jurisdictions that use their systems. In this context, "user" refers 

to election officials, others in the jurisdictions who implement systems, and VSTLs. The 

user documentation is also included in the TDP provided to the VSTL. 

It is not the intent of these requirements to prescribe an outline for user documentation. 

Manufacturers are encouraged to innovate in the quality and clarity of their user 

documentation. The intent of these requirements is to ensure that certain information that 

is of interest to end users and VSTLs will be included within the user documentation. To 

expedite the VSTL review, manufacturers SHALL provide the VSTL with a short index 

that relates the corresponding sections of the user documentation to the specific 

requirements in this document. 

9.2 System Overview 

9.2.1 User Documentation System Overview 

In the system overview, manufacturers SHALL provide information that enables the 

user to identify the functional and physical components of the system, how the 

components are structured, and the interfaces between them. 

Test Method: Inspection 

Test Entity: Manufacturer 

9.2.2 System Overview Functional Diagram 

The system overview SHALL include a high-level functional diagram of the system 

that includes all of its components. The diagram SHALL portray how the various 

components relate and interact. 

Test Method: Inspection 

Test Entity: Manufacturer 

9.2.3 System Description 

9.2.3.1 User documentation system description 

The system description SHALL include written descriptions, drawings and 

diagrams that present: 

a. A description of the functional components or subsystems, (e.g., 

environment, election management and control, vote recording, vote 

conversion, reporting, and their logical relationships); 

Section 9 | Page 112
9.2 System Overview 

b. A description of the operational environment of the system that provides an 

overview of the hardware, firmware, software, and communications 

structure; 

c. A description that explains each system function and how the function is 

achieved in the design; 

d. Descriptions of the functional and physical interfaces between subsystems 

and components; 

e. Identification of all COTS products (both hardware and software) included 

in the system and/or used as part of the system's operation, identifying the 

name, manufacturer, and version used for each such component; 

f. Communications (network) software; 

g. Interfaces among internal components and interfaces with external 

systems. For components that interface with other components for which 

multiple products may be used, the manufacturers SHALL identify file 

specifications, data objects, or other means used for information exchange, 

and the public standard used for such file specifications, data objects, or 

other means; and 

h. Listings of all software and firmware and associated documentation 

included in the manufacturer's release in the order in which each piece of 

software or firmware would normally be installed upon system setup and 

installation. 

Test Method: Inspection 

Test Entity: Manufacturer 

9.2.3.2 Identify software and firmware by origin 

The system description SHALL include the identification of all software and 

firmware items, indicating items that were: 

a. Written in-house; 

b. Written by a subcontractor; 

c. Procured as COTS; and 

d. Procured and modified, including descriptions of the modifications to the 

software or firmware and to the default configuration options. 

Test Method: Inspection 

Test Entity: Manufacturer 

9.2.3.3 Traceability of procured software 

The system description SHALL include a declaration that procured software items 

were obtained directly from the manufacturer or from a licensed dealer or 

distributor. 

Test Method: Inspection 

Test Entity: Manufacturer 

Section 9 | Page 113
9.3 System Functionality Description 

9.2.4 System Performance 

9.2.4.1 User documentation system performance 

Manufacturers SHALL provide system performance information including: 

a. Device capacities and limits that were stated in the implementation 

statement; 

b. Performance characteristics of each operating mode and function in terms 

of expected and maximum speed, throughput capacity, maximum volume 

(maximum number of voting positions and maximum number of ballot 

styles supported), and processing frequency; 

c. Quality attributes such as reliability, maintainability, availability, usability, 

and portability; 

d. Provisions for safety, security, voter privacy, ballot secrecy, and continuity 

of operations; and 

e. Design constraints, applicable standards, and compatibility requirements. 

Test Method: Inspection 

Test Entity: Manufacturer 

9.3 System Functionality Description 

9.3.1 User Documentation, System Functionality Description 

Manufacturers SHALL provide a listing of the system's functional processing 

capabilities, encompassing capabilities required by the UOCAVA Pilot Program 

Testing Requirements, and any additional capabilities provided by the system, with 

a description of each capability. 

a. Manufacturers SHALL explain, in a manner that is understandable to 

users, the capabilities of the system declared in the implementation 

statement; 

b. Additional capabilities (extensions) SHALL be clearly indicated; 

c. Required capabilities that may be bypassed or deactivated during 

installation or operation by the user SHALL be clearly indicated; 

d. Additional capabilities that function only when activated during installation 

or operation by the user SHALL be clearly indicated; and 

e. Additional capabilities that normally are active but may be bypassed or 

deactivated during installation or operation by the user SHALL be clearly 

indicated. 

Test Method: Inspection 

Test Entity: Manufacturer 

Section 9 | Page 114
9.4 System Security Specification 

9.4 System Security Specification 

9.4.1 Access Control 

9.4.1.1 Access control implementation, configuration, and 

management 

Manufacturers SHALL provide user documentation containing guidelines and 

usage instructions on implementing, configuring, and managing access control 

capabilities. 

Test Method: Inspection 

Test Entity: Manufacturer 

9.4.1.2 Access control policy 

Manufacturers SHALL provide, within the user documentation, the access control 

policy under which the system was designed to operate. 

Test Method: Inspection 

Test Entity: Manufacturer 

9.4.1.3 Privileged account 

Manufacturers SHALL disclose and document information on all privileged 

accounts included on the system. 

Test Method: Inspection 

Test Entity: Manufacturer 

9.4.2 System Event Logging 

9.4.2.1 System event logging 

Manufacturers SHALL provide user documentation that describes system event 

logging capabilities and usage. 

Test Method: Inspection 

Test Entity: Manufacturer 

9.4.2.2 Log format 

Manufacturers SHALL provide fully documented log format information. 

Test Method: Inspection 

Test Entity: Manufacturer 

Section 9 | Page 115
9.4 System Security Specification 

9.4.3 Ballot Decryption 

9.4.3.1 Ballot decryption process 

Manufacturers SHALL provide documentation on the proper procedures for the 

authorized entity to implement ballot decryption while maintaining the security and 

privacy of the data. 

Test Method: Inspection 

Test Entity: Manufacturer 

9.4.3.2 Ballot decryption key reconstruction 

Manufacturers SHALL provide documentation describing the proper procedure for 

the authorized entity to reconstruct the election private key to decrypt the ballots. 

Test Method: Inspection 

Test Entity: Manufacturer 

9.4.3.3 Ballot decryption key destruction 

Manufacturers SHALL document when any cryptographic keys created or used by 

the system may be destroyed. The documentation SHALL describe how to delete 

keys securely and irreversibly at the appropriate time. 

Test Method: Inspection 

Test Entity: Manufacturer 

9.4.4 Physical Security 

9.4.4.1 Physical security 

Manufacturers SHALL provide user documentation explaining the implementation 

of all physical security controls for the system, including procedures necessary for 

effective use of countermeasures. 

Test Method: Inspection 

Test Entity: Manufacturer 

9.4.5 Audit 

9.4.5.1 Ballot count and vote total auditing 

The system’s user documentation SHALL fully specify a secure, transparent, 

workable and accurate process for producing all records necessary to verify the 

accuracy of the electronic tabulation result. 

Test Method: Inspection 

Test Entity: Manufacturer 

Section 9 | Page 116
9.5 Software 

9.5 Software 

9.5.1 Software installation 

9.5.1.1 Software list 

Manufacturers SHALL provide a list of all software to be installed on the 

programmed devices of the system and installation software used to install the 

software. 

Test Method: Inspection 

Test Entity: Manufacturer 

9.5.1.2 Software information 

Manufacturers SHALL provide at a minimum, the following information for each 

piece of software to be installed or used to install software on programmed devices 

of the system: software product name, software version number, software 

manufacturer name, software manufacturer contact information, type of software 

(application logic, border logic, third party logic, COTS software, or installation 

software), list of software documentation, component identifier(s) (such 

filename(s)) of the software, type of software component (executable code, source 

code, or data). 

Test Method: Inspection 

Test Entity: Manufacturer 

9.5.1.3 Software location information 

Manufacturers SHALL provide the location (such as full path name or memory 

address) and storage device (such as type and part number of storage device) 

where each piece of software is installed on programmed devices of the system. 

Test Method: Inspection 

Test Entity: Manufacturer 

9.5.1.4 Election specific software identification 

Manufacturers SHALL identify election specific software in the user documentation. 

Test Method: Inspection 

Test Entity: Manufacturer 

9.5.1.5 Installation software and hardware 

Manufacturers SHALL provide a list of software and hardware required to install 

software on programmed devices of the system in the user documentation. 

Test Method: Inspection 

Test Entity: Manufacturer 

Section 9 | Page 117
9.5 Software 

9.5.1.6 Software installation procedure 

Manufacturers SHALL document the software installation procedures used to 

install software on programmed devices of the system. 

Test Method: Inspection 

Test Entity: Manufacturer 

9.5.1.7 Compiler installation prohibited 

The software installation procedures used to install software on programmed 

devices of the system SHALL specify that no compilers SHALL be installed on the 

programmed device. 

Test Method: Inspection 

Test Entity: Manufacturer 

9.5.1.8 Procurement of system software 

The software installation procedures SHALL specify that system software SHALL 

be obtained from the VSTL or approved distribution repositories. 

Test Method: Inspection 

Test Entity: Manufacturer 

9.5.1.9 Erasable storage media preparation 

The software installation procedures SHALL specify how previously stored 

information on erasable storage media is removed before installing software on the 

media. 

Test Method: Inspection 

Test Entity: Manufacturer 

9.5.1.10 Installation media unalterable storage media 

The software installation procedures SHALL specify that unalterable storage media 

SHALL be used to install software on programmed devices of the system. 

Test Method: Inspection 

Test Entity: Manufacturer 

9.5.1.11 Software hardening 

Manufacturers SHALL provide documentation that describes the hardening 

procedures for the system. 

Test Method: Inspection 

Test Entity: Manufacturer 

Section 9 | Page 118
9.6 Setup Inspection 

9.6 Setup Inspection 

9.6.1 Setup inspection process 

Manufacturers SHALL provide a setup inspection process that the system was 

designed to support. 

Test Method: Inspection 

Test Entity: Manufacturer 

9.6.1.1 Minimum properties included in a setup inspection process 

A setup inspection process SHALL, at a minimum, include the inspection of system 

software, storage locations that hold election information that changes during an 

election, and execution of logic and accuracy testing related to readiness for use in 

an election. 

Test Method: Inspection 

Test Entity: Manufacturer 

9.6.1.2 Setup inspection record generation 

The setup inspection process SHALL describe the records that result from 

performing the setup inspection process. 

Test Method: Inspection 

Test Entity: Manufacturer 

9.6.1.3 Installed software identification procedure 

Manufacturers SHALL provide the procedures to identify all software installed on 

programmed devices. 

Test Method: Inspection 

Test Entity: Manufacturer 

9.6.1.4 Software integrity verification procedure 

Manufacturers SHALL describe the procedures to verify the integrity of software 

installed on programmed devices of system. 

Test Method: Inspection 

Test Entity: Manufacturer 

Section 9 | Page 119
9.6 Setup Inspection 

9.6.1.5 Election information value 

Manufacturers SHALL provide the values of system storage locations that hold 

election information that changes during the election, except for the values set to 

conduct a specific election. 

Test Method: Inspection 

Test Entity: Manufacturer 

9.6.1.6 Maximum values of election information storage locations 

Manufacturers SHALL provide the maximum values for the storage locations where 

election information is stored. 

Test Method: Inspection 

Test Entity: Manufacturer 

9.6.1.7 Backup power operational range 

Manufacturers SHALL provide the nominal operational range for the backup power 

sources of the voting system. 

Test Method: Inspection 

Test Entity: Manufacturer 

9.6.1.8 Backup power inspection procedure 

Manufacturers SHALL provide the procedures to inspect the remaining charge of 

the backup power sources of the voting system. 

Test Method: Inspection 

Test Entity: Manufacturer 

9.6.1.9 Cabling connectivity inspection procedure 

Manufacturers SHALL provide the procedures to inspect the connectivity of the 

cabling attached to the vote capture device. 

Test Method: Inspection 

Test Entity: Manufacturer 

9.6.1.10 Communications operational status inspection procedure 

Manufacturers SHALL provide the procedures to inspect the operational status of 

the communications capabilities of the vote capture device. 

Test Method: Inspection 

Test Entity: Manufacturer 

Section 9 | Page 120
9.6 Setup Inspection 

9.6.1.11 Communications on/off status inspection procedure 

Manufacturers SHALL provide the procedures to inspect the on/off status of the 

communications capabilities of the vote capture device. 

Test Method: Inspection 

Test Entity: Manufacturer 

9.6.1.12 Consumables quantity of vote capture device 

Manufacturers SHALL provide a list of consumables associated with the vote 

capture device, including estimated number of usages per quantity of consumable. 

Test Method: Inspection 

Test Entity: Manufacturer 

9.6.1.13 Consumable inspection procedure 

Manufacturers SHALL provide the procedures to inspect the remaining amount of 

each consumable of the vote capture device. 

Test Method: Inspection 

Test Entity: Manufacturer 

9.6.1.14 Calibration of vote capture device components nominal range 

Manufacturers SHALL provide a list of components associated with the vote 

capture devices that require calibration and the nominal operating ranges for each 

component. 

Test Method: Inspection 

Test Entity: Manufacturer 

9.6.1.15 Calibration of vote capture device components inspection 

procedure 

Manufacturers SHALL provide the procedures to inspect the calibration of each 

component. 

Test Method: Inspection 

Test Entity: Manufacturer 

9.6.1.16 Calibration of vote capture device components adjustment 

procedure 

Manufacturers SHALL provide the procedures to adjust the calibration of each 

component. 

Test Method: Inspection 

Test Entity: Manufacturer 

Section 9 | Page 121
9.7 System Operations Manual 

9.6.1.17 Checklist of properties to be inspected 

Manufacturers SHALL provide a checklist of other properties of the system to be 

inspected. 

Test Method: Inspection 

9.7 System Operations Manual 

9.7.1 General 

9.7.1.1 System operations manual 

The system operations manual SHALL provide all information necessary for 

system set up and use by all personnel who administer and operate the system at 

the state and/or local election offices and at the kiosk locations, with regard to all 

system functions and operations identified in Section 9.3 System Functionality 

Description. 

Test Method: Inspection 

Test Entity: Manufacturer 

9.7.1.2 Support training 

The system operations manual SHALL contain all information that is required for 

the preparation of detailed system operating procedures and for the training of 

administrators, state and/or local election officials, election judges, and kiosk 

workers. 

Test Method: Inspection 

Test Entity: Manufacturer 

9.7.2 Introduction 

9.7.2.1 Functions 

Manufacturers SHALL provide a summary of system operating functions to permit 

understanding of the system's capabilities and constraints. 

Test Method: Inspection 

Test Entity: Manufacturer 

9.7.2.2 Roles 

The roles of operating personnel SHALL be identified and related to the functions 

of the system. 

Test Method: Inspection 

Section 9 | Page 122
9.7 System Operations Manual 

Test Entity: Manufacturer 

9.7.2.3 Conditional actions 

Decision criteria and conditional operator functions (such as error and failure

recovery actions) SHALL be described. 

Test Method: Inspection 

Test Entity: Manufacturer 

9.7.2.4 References 

Manufacturers SHALL list all reference and supporting documents pertaining to the 

use of the system during election operations. 

Test Method: Inspection 

Test Entity: Manufacturer 

9.7.3 Operational Environment 

9.7.3.1 Operational environment 

Manufacturers SHALL describe the system environment and the interfaces 

between the system and state and/or local election officials, kiosk workers, system 

administrators, and voters. 

Test Method: Inspection 

Test Entity: Manufacturer 

9.7.3.2 Operational environment; equipment and facility 

Manufacturers SHALL identify all facilities, furnishings, fixtures, and utilities that will 

be required for equipment operations, including equipment that operates at the: 

a. Kiosk locations; 

b. State and/or local election offices; and 

c. Other locations. 

Test Method: Inspection 

Test Entity: Manufacturer 

9.7.3.3 Operational environment; installation 

The operations manual SHALL include a statement of all requirements and 

restrictions regarding environmental protection, electrical service, recommended 

auxiliary power, telecommunications service, and any other facility or resource 

required for the proper installation and operation of the system. 

Test Method: Inspection 

Section 9 | Page 123
9.7 System Operations Manual 

Test Entity: Manufacturer 

9.7.4 System Installation and Test Specification 

9.7.4.1 Readiness testing 

Manufacturers SHALL provide specifications for testing of system installation and 

readiness. 

Test Method: Inspection 

Test Entity: Manufacturer 

9.7.4.1.1 Readiness test entire system 

These specifications SHALL cover testing of all components of the system and 

all locations of installation (e.g., kiosk locations, state and/or local election 

offices), and SHALL address all elements of system functionality and 

operations identified in Section 9.3 System Functionality Description above, 

including general capabilities and functions specific to particular voting 

activities. 

Test Method: Inspection 

Test Entity: Manufacturer 

9.7.5 Operational Features 

9.7.5.1 Features 

Manufacturers SHALL provide documentation of system operating features that 

includes: 

a. Detailed descriptions of all input, output, control, and display features 

accessible to the operator or voter; 

b. Examples of simulated interactions to facilitate understanding of the 

system and its capabilities; 

c. Sample data formats and output reports; and 

d. Illustration and description of all status indicators and information 

messages. 

Test Method: Inspection 

Test Entity: Manufacturer 

9.7.5.2 Document straight party override algorithms 

For systems that support straight party voting, manufacturers SHALL document the 

available algorithms for counting straight party overrides. 

Test Method: Inspection 

Test Entity: Manufacturer 

Section 9 | Page 124
9.7 System Operations Manual 

9.7.5.3 Document double vote reconciliation algorithms 

For systems that support write-in voting, manufacturers SHALL document the 

available algorithms for reconciling write-in double votes. 

Test Method: Inspection 

Test Entity: Manufacturer 

9.7.6 Operating Procedures 

9.7.6.1 Operating procedures 

Manufacturers SHALL provide documentation of system operating procedures that: 

a. Provides a detailed description of procedures required to initiate, control, 

and verify proper system operation; 

b. Enables the operator to assess the correct flow of system functions (as 

evidenced by system-generated status and information messages); 

c. Enables the administrator to intervene in system operations to recover from 

an abnormal system state; 

d. Defines and illustrates the procedures and system prompts for situations 

where operator intervention is required to load, initialize, and start the 

system; 

e. Defines and illustrates procedures to enable and control the external 

interface to the system operating environment if supporting hardware and 

software are involved. Such information also SHALL be provided for the 

interaction of the system with other data processing systems or data 

interchange protocols; 

f. Provides administrative procedures and off-line operator duties (if any) if 

they relate to the initiation or termination of system operations, to the 

assessment of system status, or to the development of an audit trail; 

g. Supports successful ballot and program installation and control by state 

and/or local election officials; 

h. Provides a schedule and steps for the software and ballot installation, 

including a table outlining the key dates, events and deliverables; and 

i. Specifies diagnostic tests that may be employed to identify problems in the 

system, verify the correction of problems, and isolate and diagnose faults 

from various system states. 

Test Method: Inspection 

Test Entity: Manufacturer 

9.7.6.2 Printer error recovery guidelines 

Manufacturers SHALL provide documentation for procedures to recover from 

printer errors and faults including procedures for how to cancel a vote suspended 

during an error. 

Section 9 | Page 125
9.7 System Operations Manual 

Test Method: Inspection 

Test Entity: Manufacturer 

9.7.7 Transportation and Storage 

9.7.7.1 Transportation 

Manufacturers SHALL include any special instructions for preparing vote capture 

devices for shipment. 

Test Method: Inspection 

Test Entity: Manufacturer 

9.7.7.2 Storage 

Manufacturers SHALL include any special storage instructions for vote capture 

devices. 

Test Method: Inspection 

Test Entity: Manufacturer 

9.7.7.3 Precautions for removable media 

Manufacturers SHALL detail the care and handling precautions necessary for 

removable media and records. 

Test Method: Inspection 

Test Entity: Manufacturer 

9.7.8 Appendices 

Manufacturers SHALL provide descriptive material and data supplementing the 

various sections in the body of the system operations manual. The content and 

arrangement of appendices are at the discretion of the manufacturer. Topics 

required for discussion include: 

 Glossary: A listing and brief definition of all terms that may be unfamiliar to 

persons not trained in either systems or computer operations; 

 References: A list of references to all manufacturer documents and to other 

sources related to operation of the system; 

 Detailed Examples: Detailed scenarios that outline correct system responses 

to faulty operator input; and 

 Manufacturer's Recommended Security Procedures: Security procedures 

that are to be executed by the system operator. 

Test Method: Inspection 

Test Entity: Manufacturer 

Section 9 | Page 126
9.8 System Maintenance Manual 

9.8 System Maintenance Manual 

9.8.1.1 User documentation system maintenance manual 

The system maintenance manual SHALL provide information to support election 

officials, kiosk workers, information systems personnel, or maintenance personnel 

in the adjustment or removal and replacement of components or modules in the 

field. 

Test Method: Inspection 

Test Entity: Manufacturer 

9.8.1.2 General contents 

Manufacturers SHALL describe service actions recommended to correct 

malfunctions or problems; personnel and expertise required to repair and maintain 

the system, equipment, and materials; and facilities needed for proper 

maintenance. 

Test Method: Inspection 

Test Entity: Manufacturer 

9.8.2 Introduction 

9.8.2.1 Equipment overview, maintenance viewpoint 

Manufacturers SHALL describe the structure and function of the hardware, 

firmware and software for election preparation, programming, vote recording, 

tabulation, and reporting in sufficient detail to provide an overview of the system for 

maintenance and for identification of faulty hardware or software. 

Test Method: Inspection 

Test Entity: Manufacturer 

9.8.3 Maintenance Procedures 

9.8.3.1 Maintenance manual maintenance procedures 

Manufacturers SHALL describe preventive and corrective maintenance procedures 

for hardware, firmware and software. 

Test Method: Inspection 

Test Entity: Manufacturer 

9.8.3.2 Maintenance manual preventive maintenance procedures 

Manufacturers SHALL identify and describe: 

Section 9 | Page 127
9.8 System Maintenance Manual 

a. All required and recommended preventive maintenance tasks, including 

software and data backup, database performance analysis, and database 

tuning; 

b. Number and skill levels of personnel required for each task; 

c. Parts, supplies, special maintenance equipment, software tools, or other 

resources needed for maintenance; and 

d. Any maintenance tasks that must be referred to the manufacturer. 

Test Method: Inspection 

Test Entity: Manufacturer 

9.8.3.3 Corrective maintenance procedures 

9.8.3.3.1 Troubleshooting procedures 

Manufacturers SHALL provide fault detection, fault isolation, correction 

procedures, and logic diagrams for all operational abnormalities identified by 

design analysis and operating experience. 

Test Method: Inspection 

Test Entity: Manufacturer 

9.8.3.3.2 Troubleshooting procedures details 

Manufacturers SHALL identify specific procedures to be used in diagnosing 

and correcting problems in the system hardware, firmware and software. 

Descriptions SHALL include: 

a. Steps to replace failed or deficient equipment; 

b. Steps to correct deficiencies or faulty operations in software or 

firmware; 

c. Number and skill levels of personnel needed to accomplish each 

procedure; 

d. Special maintenance equipment, parts, supplies, or other resources 

needed to accomplish each procedure; and 

e. Any coordination required with the manufacturer. 

Test Method: Inspection 

Test Entity: Manufacturer 

9.8.4 Maintenance Equipment 

9.8.4.1 Special equipment 

Manufacturers SHALL identify and describe any special purpose test or 

maintenance equipment recommended for fault isolation and diagnostic purposes. 

Test Method: Inspection 

Test Entity: Manufacturer 

Section 9 | Page 128
9.8 System Maintenance Manual 

9.8.5 Parts and Materials 

Manufacturers SHALL provide detailed documentation of parts and materials needed 

to operate and maintain the system. 

Test Method: Inspection 

Test Entity: Manufacturer 

9.8.6 Maintenance Facilities and Support 

9.8.6.1 Maintenance environment 

Manufacturers SHALL identify all facilities, furnishings, fixtures, and utilities that will 

be required for equipment maintenance. 

Test Method: Inspection 

Test Entity: Manufacturer 

9.8.6.2 Maintenance support and spares 

Manufacturers SHALL specify: 

a. Recommended number and locations of spare devices or components to 

be kept on hand for repair purposes during periods of system operation; 

b. Recommended number and locations of qualified maintenance personnel 

who need to be available to support repair calls during system operation; 

and 

c. Organizational affiliation (e.g., jurisdiction, manufacturer) of qualified 

maintenance personnel. 

Test Method: Inspection 

Test Entity: Manufacturer 

9.8.7 Appendices 

Manufacturers SHALL provide descriptive material and data supplementing the 

various sections in the body of the system maintenance manual. The content and 

arrangement of appendices are at the discretion of the manufacturer. Topics required 

for amplification or treatment in an appendix includes: 

 Glossary: A listing and brief definition of all terms that may be unfamiliar to 

persons not trained in either systems or computer maintenance; 

 References: A list of references to all manufacturer documents and other 

sources related to maintenance of the system; 

 Detailed Examples: Detailed scenarios that outline correct system 

responses to faulty operator input; and 

Section 9 | Page 129
9.9 Personnel Deployment and Training Requirements 

 Maintenance and Security Procedures: Technical illustrations and schematic 

representations of electronic circuits unique to the system. 

Test Method: Inspection 

Test Entity: Manufacturer 

9.9 Personnel Deployment and Training Requirements 

Manufacturers SHALL describe the personnel resources and training required for a 

jurisdiction to operate and maintain the system for the duration of the pilot project. 

Test Method: Inspection 

Test Entity: Manufacturer 

9.9.1 Personnel 

9.9.1.1 Training manual personnel 

Manufacturers SHALL specify the number of personnel and skill levels required to 

perform each of the following functions: 

a. Pre-voting or election preparation functions; 

b. System operations for system functions performed at the kiosk locations; 

c. System operations for system functions performed at the state and/or local 

election offices; 

d. Preventive maintenance tasks; 

e. Diagnosis of faulty hardware, firmware, or software; 

f. Corrective maintenance tasks; and 

g. Testing to verify the correction of problems. 

Test Method: Inspection 

Test Entity: Manufacturer 

9.9.1.2 User functions versus manufacturer functions 

Manufacturers SHALL distinguish which functions may be carried out by user 

personnel and which must be performed by manufacturer personnel. 

Test Method: Inspection 

Test Entity: Manufacturer 

Section 9 | Page 130
9.9 Personnel Deployment and Training Requirements 

Section 9 | Page 131

9.9.2 Training 

9.9.2.1 Training requirements 

Manufacturers SHALL provide training materials to instruct system administrators, 

kiosk workers, and state and/or local election officials on how to set up, configure 

and operate the system. 

Test Method: Inspection 

Test Entity: Manufacturer 
Appendix A: Glossary 

Appendix A: Glossary 

This section defines selected terms and acronyms used in this document. Readers 

may be familiar with many of these terms, but the definitions as used herein may 

differ from those in other contexts. 

Terminology for standardization purposes must be sufficiently precise and formal to 

avoid ambiguity in the interpretation and testing of the requirements. Any term that 

is not defined here retains its common English usage meaning. 

absentee ballot: A ballot cast from any location not defined as a polling place. 

absentee model: The ballot remains associated with the voter ID until the close of the voting period 

and is subject to an adjudication process to be accepted for tabulation. 

absentee voting: The process of casting a ballot from any location not defined as a polling place. 

accessible voting station: Voting station specially equipped for individuals with disabilities referred to in HAVA 

301 (a)(3)(B). 

administrator: The role responsible for installing, configuring, and managing the technical 

operations of the system. 

alert time: The amount of time the system will wait for detectible voter activity after issuing an 

alert before going into an inactive state requiring poll worker intervention. 

application logic: Software, firmware, or hardwired logic from any source that is specific to the system, 

with the exception of border logic. 

audio-tactile interface 

Voter interface designed to not require visual reading of a ballot. Audio is used to 

convey information to the voter and sensitive tactile controls allow the voter to convey 

information to the voting system. 

authenticated session: Process that requires all users to provide proof of identity. 

ballot image: Human-readable electronic representation of the ballot, including the voter’s 

selections. 

ballot measure: Contest in which the choices are Yes and No. 

ballot secrecy: Not being able to associate the selections of the ballot with the voter who cast it. 

ballot style: 

Particular set of contests to appear on the ballot for a particular election district, their 

order, the list of ballot positions for each contest, and the binding of candidate names 

to ballot positions 

ballot: The official presentation of all of the contests to be decided in a particular election. 

See also ballot image, cast vote record, and paper record. 

baseline configuration: 

The exact system configuration tested by the VSTL. It includes all the system 

components that were tested, including the specific hardware, operating system, 

application software, and third-party COTS applications.

border logic: Software, firmware, or hardwired logic that is developed to connect application logic 

to COTS or third-party logic. 

Appendix A:| Page 132
Appendix A: Glossary 

callable unit: Function, method, operation, subroutine, procedure, or analogous structural unit that 

appears within a module (of a software program or analogous logical design). 

candidate: Person contending in a contest for office. 

cast ballot: Ballot in which the voter has taken final action in the selection of contest choices and 

submitted it for tabulation. 

cast vote record: The record of all votes selected by a voter. 

common industry format: Format described in ISO/IEC 25062:2006 "Common Industry Format (CIF) for 

Usability Test Reports". 

completed system 

response time 

The time taken from when the voter performs some detectible action to when the 

voting system completes its response and settles into a stable state (e.g., finishes 

"painting" the screen with a new page). 

component: A discrete and identifiable element of hardware or software within a system. 

concept of operations: Description of roles and responsibilities for system administration, operation and use. 

configuration data: Non-executable input to software, firmware, or hardwired logic, not including vote 

data. 

conformity assessment: Demonstration that specified requirements relating to a product, process, system, 

person or body are fulfilled. 

contest: A single decision being put before the voters (e.g., the selection of a candidate for 

office or the response to ballot questions). 

core logic: Subset of application logic that is responsible for vote recording and tabulation. 

COTS: Commercial Off the Shelf 

credible methodologies: 

Methodologies (e.g., coding conventions, cryptographic algorithms) are considered 

credible if at least two organizations other than the voting system manufacturer have 

independently adopted them and made active use of them at some time within the 

three years before conformity assessment was first sought. 

cryptography: The protection of information by converting the information into an unreadable 

format. 

CVR: Cast vote record 

device: Functional unit that performs its assigned tasks as an integrated whole. 

election definition: Definition of the contests and questions that will appear on the ballot for a specific 

election. 

election judge: A member of the canvassing board that adjudicates the acceptance of absentee 

ballots 

election management 

system: 

Set of processing functions and databases within a system that defines, develops 

and maintains election databases, performs election definitions and setup functions, 

formats ballots, counts votes, consolidates and reports results, and maintains audit 

trails 

election officials: The persons responsible for administering and conducting elections. 

election title: The heading on a ballot specifying the name of the election (e.g., General Election, 

Primary Election). 

Appendix A:| Page 133
Appendix A: Glossary 

equivalent configuration: A system configuration that has been attested to by the manufacturer to perform 

identically to the baseline configuration. 

error rate: Ratio of the number of errors detected in relation to the volume of data processed: 

failure: 

Events that result in (a) loss of one or more functions, (b) degradation of performance 

such that the device is unable to perform its intended function for longer than 10 

seconds, (c) automatic reset, restart or reboot of the voting device, operating system 

or application software, (d) a requirement for an unanticipated intervention by a 

person in the role of kiosk worker or technician before normal operation can continue, 

or (e) error messages and/or audit log entries indicating that a failure has occurred.

fault: 

Flaw in design or implementation that may result in the qualities or behavior of the 

system deviating from the qualities or behavior that are specified in the UOCAVA 

Pilot Program Testing Requirements and/or in manufacturer-provided documentation.

functional: 

Functional testing is the determination through operational testing of whether the 

behavior of a system or device in specific scenarios conforms to requirements. 

Functional tests are derived by analyzing the requirements and the behaviors that 

should result from implementing those requirements. 

hardwired logic: 

Logic implemented through the design of an integrated circuit; the programming of a 

Programmable Logic Device (PLD), Field-Programmable Gate Array (FPGA), 

Peripheral Interface Controller (PIC), or similar; the integration of smaller hardware 

components; or mechanical design (e.g., as in lever machines). 

initial system response 

time 

The time taken from when the voter performs some detectible action (such as 

pressing a button) to when the voting system begins responding in some obvious 

way (such as an audible response or any change on the screen). 

implementation 

statement: 

Statement by a manufacturer indicating the capabilities, features, and optional 

functions and extensions that have been implemented in a system. 

inspection: 

Examination of a product design, product, process or installation and determination 

of its conformity with specific requirements or, on the basis of professional judgment, 

with general requirements. 

kiosk: A terminal tasked to display information, accepts user input, and transmit information

kiosk workers: Election workers who staff the remote voting kiosk locations. 

manufacturer: Entity with ownership and control over a system submitted for testing. 

module: Structural unit of software or analogous logical design, typically containing several 

callable units that are tightly coupled. 

paper record identifier: Unique randomly generated code that links the paper record to the corresponding 

cast vote record. 

paper record receptacle: A secure unit for storing paper records at kiosk locations. 

paper record: Printed record of ballot selections made by the voter. 

programmed device: Electronic device that includes application logic. 

published: Methodologies (e.g., coding conventions, cryptographic algorithms) are considered 

published if they appear in publicly available media. 

straight party override: Ability to make an exception to straight party voting in selected races. 

Appendix A:| Page 134
Appendix A: Glossary 

straight party voting: Mechanism that allows voters to cast a single vote to select all candidates on the 

ballot from a single political party. 

tabulation device: A device used to calculate election results. 

third-party logic: 

Software, firmware, or hardwired logic that is neither application logic nor COTS; e.g., 

general-purpose software developed by a third party that is either customized (e.g., 

ported to a new platform, as is Windows CE) or not widely used, or source code 

generated by a COTS package. 

UOCAVA: Uniformed and Overseas Citizens Absentee Voting Act 

vote capture device: Device that is used directly by a voter to vote a ballot. 

voted ballot: Ballot that contains all of a voter's selections and has been cast. 

voter inactivity time: 

The amount of time from when the system completes its response until there is 

detectible voter activity. In particular, note that audio prompts from the system may 

take several minutes and that this time does not count as voter inactivity. 

voter privacy: The inability of anyone to observe, or otherwise determine, what selections a voter 

has made. 

voting process: Entire array of procedures, people, resources, equipment and locations associated 

with the conduct of elections. 

voting session: Span of time beginning when a ballot is enabled or activated and ending when the 

ballot is cast. 

voting system: 

Equipment (including hardware, firmware, and software), materials, and 

documentation used to define elections and ballot styles, configure voting equipment, 

identify and validate voting equipment configurations, perform readiness tests, 

activate ballots, capture votes, count votes, generate reports, transmit election data, 

archive election data, and audit elections. 

VPN: Virtual Private Network 

VSTL: Voting System Test Laboratory 

white-box testing: 

Uses an internal perspective of the system to design test cases based on internal 

structure. White box testing strategy deals with the internal logic and structure of the 

code. 

write-in: To make a selection of an individual not listed on the ballot. 

Appendix A:| Page 135
Appendix B: List of References 

Appendix B: List of References 

The following is a list of documents or publications used in the creation of the 

UOCAVA Pilot Program Testing Requirements. 

ANSI 02: ANSI/TIA-968-A: 2002, Technical Requirements for Connection of Terminal Equipment 

to the Telephone Network. 

BS 7799: Data center certification standard 

CERT 06: CERT® Coordination Center, Secure Coding homepage, July 2006, Available from 

http://www.cert.org/secure-coding/. 

DHS 06: Department of Homeland Security, Build Security In, July 2006, Available from 

https://buildsecurityin.us-cert.gov/. 

EAC06: 

U.S. Election Assistance Commission, Testing and Certification Program Manual, 

Version 1.0, December 5, 2006. Available from 

http://www.eac.gov/program-areas/votingsystems/docs/testingandcertmanual.pdf/attachment_download/file. 

FIPS 81: (1980): DES Modes of Operation 

FIPS 46-3: (1999): Data Encryption Standard (DES) 

FIPS 140-2: Security Requirements for Cryptographic Modules 

FIPS 180-2: (2002): Secure Hash Standard (SHA1) 

FIPS 186-2: (2000): Digital Signature Standard (DSS) 

FIPS 197: (2001): Advanced Encryption Standard (AES) 

FIPS 198: (2002): The Keyed-Hash Message Authentication Code (HMAC) 

FIPS 200: Minimum security requirements for federal information and information systems. 

FCC 07a: Title 47, Part 68, Rules and Regulations of the Federal Communications Commission, 

Connection of Terminal Equipment to the Telephone Network: 2000. 

GPO 90: 

Performance and Test Standards for Punchcard, Marksense, and Direct Recording 

Electronic Voting Systems, January 1990 edition with April 1990 revisions, in Voting 

System Standards, U.S. Government Printing Office, 1990.14 Available from 

http://josephhall.org/fec_vss_1990_pdf/1990_VSS.pdf. 

GPO 99: Government Paper Specification Standards No. 11, February 1999. 

HAVA 02: The Help America Vote Act of 2002, Public Law 107-252. Available from 

http://www.fec.gov/hava/hava.htm. 

HFP 07: 

Human Factors and Privacy Subcommittee of the TGDC, “Usability Performance 

Benchmarks for the VVSG,” August 2007. Available from http://vote.nist.gov/meeting08172007/Usability-Benchmarks-081707.pdf. 

IEEE 00: IEEE 100:2000 The Authoritative Dictionary of IEEE Standard Terms, Seventh Edition. 

Appendix B:| Page 136
Appendix B: List of References 

IEEE 97: 

IEEE/EIA 12207.1-1997, Industry implementation of International Standard ISO/IEC 

12207:1995—(ISO/IEC 12207) standard for information technology—software life cycle 

processes—life cycle data. 

IEEE 98: IEEE Std 829-1998, IEEE standard for software test documentation. 

IETF RFC 2246:(1999): The TLS Protocol Version 1.0 

IETF RFC 2510:(1999): Internet X.509 PKI Certificate Management Protocols 

IETF RFC 2817:(2000): Upgrading to TLS within HTTP/1.1 

IETF RFC 2818:(2000): HTTP Over TLS 

IETF RFC 3280:(1999): Internet X.509 PKI Certificate and CRL Profile 

IETF RFC 3369:(2002): Cryptographic Message Syntax 

IETF RFC 3370:(2002): Cryptographic Message Syntax (CMS) Algorithms 

IETF RFC 3546:(2003): TLS Extensions 

IETF RFC 3739:(2004): Internet X.509 PKI Qualified Certificates Profile 

IETF RFC 4279:(2005): Pre-Shared Key Cipher suites for TLS 

ISO 00: ISO 9001:2000, Quality management systems – Requirements. 

ISO 00a: ISO/IEC TR 15942:2000, Information technology—Programming languages—Guide for 

the use of the Ada programming language in high integrity systems. 

ISO 03: ISO 10007:2003, Quality management systems – Guidelines for configuration 

management. 

ISO 03a: ISO/IEC 14882:2003, Programming languages—C. 

ISO 04a: ISO 17000:2004, Conformity assessment—Vocabulary and general principles. 

ISO 05: ISO 9000:2005, Quality management systems – Fundamentals and vocabulary. 

ISO 06: ISO/IEC 23270:2006, Information technology—Programming languages—C#. 

ISO 06e: ISO/IEC 25062:2006 Common Industry Format (CIF) for Usability Test Reports. 

ISO 94: ISO 9706:1994, Information and documentation—Paper for documents—Requirements 

for permanence. 

ISO 95: ISO/IEC 8652:1995, Information technology—Programming languages—ADA. 

ISO 98a: ISO 9241-11:1998, Ergonomic requirements for office work with visual display terminals 

(VDTs) -- Part 11: Guidance on usability. 

ISO 99: ISO/IEC 9899:1999, Programming languages—C. 

ITU-T X.509: (2000)/ISO/IEC 9594-8 (2001): Information Technology – Open Systems Interconnection 

– The Directory: Authentication Framework 

Java 05: The Java Language Specification, Third Edition, 2005. Available from 

http://java.sun.com/docs/books/jls/index.html. 

Appendix B:| Page 137
Appendix B: List of References 

LOTSE-V: Legal, Operational and Technical Standards for E-Voting 

MIL 83: MIL-STD-810-D, Environmental Test Methods and Engineering Guidelines, 1983-7-19. 

MIL 85: MIL-STD-1521B (USAF) Technical Reviews and Audits for Systems, Equipments [sic], 

and Computer Software, rev. December 19, 1985. 

MIL 96: MIL-HDBK-781A, Handbook for Reliability Test Methods, Plans, and Environments for 

Engineering, Development, Qualification, and Production, April 1, 1996. 

MIRA 04: MISRA-C: 2004: Guidelines for the use of the C language in critical systems, MIRA 

Limited, U.K., November 2004. 

Morris 84: F. L. Morris and C. B. Jones, "An Early Program Proof by Alan Turing," IEEE Annals of 

the History of Computing, v. 6, n. 2, April 1984, pp. 139-143. 

Moulding 89: 

M. R. Moulding, "Designing for high integrity: the software fault tolerance approach," 

Section 3.4. In C. T. Sennett, ed., High-Integrity Software, Plenum Press, New York and 

London, 1989. 

MS 05: Request For Proposal #3443, Mississippi, April 28, 2005. 

MS 05: Paul Vick, The Microsoft® Visual Basic® Language Specification, Version 8.0, 2005. 

Available from Microsoft Download Center, http://go.microsoft.com/fwlink/?linkid=62990.

NGC 06: 

Nevada Gaming Commission and State Gaming Control Board, Technical Standards for 

Gaming Devices and On-Line Slot Systems, March 2006. Available from 

http://gaming.nv.gov/stats_regs/reg14_tech_stnds.pdf. 

NIST 02: 

John P. Wack, Ken Cutler, Jamie Pole, National Institute of Standards and Technology 

Special Publication 800-41: Guidelines on Firewalls and Firewall Policy, January 2002. 

Available from http://csrc.nist.gov/publications/nistpubs/800-41/sp800-41.pdf. 

NIST 03: 

Fred R. Byers, Care and Handling of CDs and DVDs—A Guide for Librarians and 

Archivists, National Institute of Standards and Technology Special Publication 500-252, 

2003-10. Available from http://www.itl.nist.gov/div895/carefordisc/index.html. 

NIST 05: 

Recommended Security Controls for Federal Information Systems, National Institute of 

Standards and Technology Special Publication 800-53, 2005-02. Available from 

http://csrc.nist.gov/publications/nistpubs/. 

NIST 05a: 

Peter Mell, Karen Kent, Joseph Nusbaum, National Institute of Standards and 

Technology Special Publication 800-83: Guide to Malware Incident Prevention and 

Handling, November 2005. Available from http://csrc.nist.gov/publications/nistpubs/800-

83/SP800-83.pdf. 

NIST 07: 

Karen Scarfone, Peter Mell, National Institute of Standards and Technology Special 

Publication 800-94: Guide to Intrusion Detection and Prevention Systems, February 

2007. Available from http://csrc.nist.gov/publications/nistpubs/800-94/SP800-94.pdf. 

NIST 75: 

Saltman, Roy, National Institute of Standards Special Publication 500-30, Effective Use 

of Computing Technology in Vote-Tallying, 1975. Available from 

http://csrc.nist.gov/publications/nistpubs/NBS_SP_500-30.pdf. 

ODBP CR: ODBP Code Review 

ODBP CRM: ODBP Certification Matrix 

Appendix B:| Page 138
Appendix B: List of References 

ODBP DSF: ODBP Description of System Features 

ODBP P: ODBP Plan 

ODBP SPV: ODBP System Performance Validation 

ODBP SR: ODBP System Requirements 

ODBP SM: ODBP Security Requirements Mapped to VVSG 2005 

ODBP TR: ODBP Test Report 

OMG 07: 

OMG Unified Modeling Language Superstructure Specification, version 2.1.1. Document 

formal/2007-02-05, Object Management Group, February 2007. Available from 

http://www.omg.org/cgi-bin/doc?formal/2007-02-05. 

Oxford 93: New Shorter Oxford English Dictionary, Clarendon Press, Oxford, 1993. 

Pietrek 97: 

Matt Pietrek, "A Crash Course on the Depths of Win32TM Structured Exception 

Handling," Microsoft Systems Journal, January 1997. Available from 

http://www.microsoft.com/msj/0197/exception/exception.aspx. 

PKCS #1: RSA Cryptography Standard 

PKCS #5: Password-based Encryption Standard 

PKCS #7: Cryptographic Message Syntax Standard 

PKCS #8: Private Key Information Syntax Standard 

PKCS #10: Certification Request Standard 

PKCS #11: Cryptographic Token Interface 

PKCS #12: Personal Information Exchange Syntax Standard 

SCAM 01: Joel Scambray, Stuart McClure, George Kurtz, Hacking Exposed: Network Security 

Secrets and Solutions, Second Edition, 2001. 

SERVE DSF: SERVE Description of System Features 

SERVE EV: SERVE Election Validation 

SERVE R: SERVE Requirements 

SERVE SA: SERVE Security Architecture 

SERVE SACP: SERVE System Accreditation and Certification Process 

SERVE STC: SERVE Security Test Conditions 

SERVE TDP C: SERVE TDP Checklist 

SERVE TRA: SERVE Threat Risk Assessment 

SERVE VVP: SERVE Vote Verification Process 

SERVE WH: SERVE White Hat 

Sourceforge CEXCEPT (exception handling in C), software package, 2000. Available from 

Appendix B:| Page 139
Appendix B: List of References 

00: http://cexcept.sourceforge.net/. 

SP 800-53: Rev 2 Recommended Security Controls for Federal Information Systems 

SP 800-63: Electronic Authentication Guideline, April 2006. Available from: 

http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf. 

SP 800-113: (2007): DRAFT Guide to SSL VPNs 

TRIVS RN: Testing Requirements for Internet Voting Systems Robert Naegele 

UL 05: UL 60950-1:2005, Information Technology Equipment – Safety – Part 1: General 

Requirements. 

UL 437: UL 437:2003, Standard for Key Locks. (2003). 

UOCAVA PT: UOCAVA Penetration Testing 

UT 04: Solicitation #DG5502, Utah, 2004-07-09. January 27, 2006. 

VOI CAR: VOI Certification and Accreditation Report 

VOI COD: VOI Concepts of Operations 

VOI DSF: VOI Description of System Features 

VOI LEO M: VOI LEO Manual 

VOI LEO 

SSRS: VOI LEO Server Software Requirement Spec 

VOI PPR: VOI Pilot Peer Review 

VOI PSR: VOI Pilot System Requirements 

VOI Report: VOI Test Report 2001 

VOI SA: VOI System Arch 

VOI SD: VOI System Design 

VOI SP: VOI Security Policy 

VOI SRS: VOI Software Requirement Spec 

VOI STEP: VOI System Test and Evaluation Plan 

VOI STP: VOI Software Test Plan 

VOI TP: VOI Test Procedures 

VOI TR: VOI Test Report 1999 

VSS 2002: 

2002 Voting Systems Standards. Available from 

http://www.eac.gov/program-areas/voting-systems/docs/voting-systems-standardsvolume-i-performance.pdf/attachment_download/file 

VVSG 2005: 2005 Voluntary Voting System Guidelines, Version 1.0, March 6, 2006. Available from 

http://www.eac.gov/program-areas/votingAppendix B:| Page 140
Appendix B: List of References 

systems/docs/vvsgvolumei.pdf/attachment_download/file 

VVSG 2.0: VVSG Recommendations to the EAC, TGDC, August 31, 2007. 

RFI 2007-03: 

EAC Decision on Request for Interpretation 2007-03, 2005 VVSG Vol. 1 Section 3.1.1, 

 September 5, 2007. Available from 

http://www.eac.gov/program-areas/voting-systems/docs/certification-docs-eac-decisionon-request-for-interpretation-2007-03.pdf-1/attachment_download/file. 

Wald 47: Abraham Wald, Sequential Analysis, John Wiley & Sons, 1947. 

Appendix B:| Page 141
Appendix C: Accuracy Test Case 

Appendix C: Accuracy Test Case 

Some voting system performance attributes are tested by inducing an event or 

series of events and the relative or absolute time intervals between repetitions of 

the event has no significance. Although equivalence between a number of events 

and a time period can be established when the operating scenarios of a system 

can be determined with precision, another type of test is required when such 

equivalence cannot be established. It uses event based failure frequencies to 

arrive at ACCEPT/REJECT criteria. This test may be performed simultaneously 

with time-based tests. 

For example, the failure of a device is usually dependent on the processing volume 

that it is required to perform. The elapsed time over which a certain number of 

actuation cycles occur is, under most circumstances, not important. Another 

example of such an attribute is the frequency of errors in reading, recording, and 

processing vote data. 

The error frequency, called “ballot position error rate,” applies to such functions as 

the process of detecting the presence or absence of a voting punch or mark, or to 

the closure of a switch corresponding to the selection of a candidate. 

Certification and acceptance test procedures that accommodate event-based 

failures are, therefore, based on a discrete, rather than a continuous probability 

distribution. A Probability Ratio Sequential Test using the binomial distribution is 

recommended. In the case of ballot position error rate, the calculation for a specific 

device (and the processing function that relies on that device) is based on: 

 HO: Desired error rate = 1 in 10,000,000 

 H1: Maximum acceptable error rate = 1 in 500,000 

 a = 0.05 

 b = 0.05 

The minimum error-free sample size to accept for qualification tests is 1,549,703 

votes. 

The nature of the problem may be illustrated by the following example, using the 

criteria contained in the VVSG 2005 for system error rate. A target for the desired 

accuracy is established at a very low error rate. A threshold for the worst error rate 

that can be accepted is then fixed at a somewhat higher error rate. Next, the 

decision risk is chosen, that is, the risk that the test results may not be a true 

indicator of either the system's acceptability or unacceptability. The process is as 

follows: 

 The desired accuracy of the voting system, whatever its true error rate

(which may be far better), is established as no more than one error in every 

ten million characters (including the null character). 

 If it can be shown that the system's true error rate does not exceed one in 

every five hundred thousand votes counted, it will be considered 

acceptable. This is more than accurate enough to declare the winner 

correctly in almost every election. 

 A decision risk of 5 percent is chosen, to be 95 percent certain that the test 

data will not indicate that the system is bad when it is good or good when it 

is bad. 

This results in the following decision criteria: 

Appendix C:| Page 142
Appendix C: Accuracy Test Case 

Appendix C:| Page 143

a. If the system makes one error before counting 26,997 consecutive ballot 

positions correctly, it will be rejected. The vendor is then required to 

improve the system. 

b. If the system reads at least 1,549,703 consecutive ballot positions 

correctly, it will be accepted. 

c. If the system correctly reads more than 26,997 ballot positions but less 

than 1,549,703 when the first error occurs, the testing will have to be 

continued until another 1,576,701 consecutive ballot positions are counted 

without error (a total of 3,126,404 with one error).