2675 South Abilene Street, #300, Aurora, Colorado, 80014

Form-E: VSTL Test Report template

Appendix A, B, and G of the ES&S Unity 3.2.0.0 

Revision 1 Voting System Certification Test 

Report for DS200 Modifications to the EAC 

Certified ESSUNITY3200

Prepared for 

Election System and Software

11208 John Galt Blvd.

Omaha, NE 68137

EAC Application ESS1002

Version 4.0

EAC Certification # ESSUNITY3200REV1

iBeta Report Number: (V)2010-30Jun-001(D)

Trace to Standards

NIST Handbook 150-22

Section 5.5, 5.10.1 through 5.10.3, 5.10.5, 5.10.6

VVSG

Vol. # Section(s) #

1 1.4.1

1 2, 3, 4, 5, 6, & 7

2 1.8.3

2 2, 3, 4, 5, & 6

2 7.4 & 7.5.

2 Appendix B

Test Results in this report apply to the voting system configuration tested. Testing of voting systems that have been 

modified may or may not produce the same test results. This report shall not be reproduced, except in full.

iBeta Quality Assurance is accredited for Voting System Testing:

EAC Lab Code: 0702 – Effective thru 7/16/11
EAC Certification # ESSUNITY3200REV1.

iBeta Report Number: (V)2010-30Jun-001(D)

ii

Version History

Ver # Description of Change Author Approved by Date

v.1.0 Initial release Carolyn Coggins

Jenn Garcia

Steve Brown

Steve Pearson and John 

Lento

6/30/10

v.2.0 Update version to be consistent 

with the main report; no changes to 

Appendix A, B or G

Carolyn Coggins Carolyn Coggins 7/20/10

v.3.0 Updated 

 Report version and added EAC 

Certification #

 Appendix A with comments per 

EAC review

Jenn Garcia Carolyn Coggins 10/4/10

v.4.0 Update version to be consistent 

with the main report; no changes to 

Appendix A, B or G

Carolyn Coggins Carolyn Coggins 10/12/10
EAC Certification # ESSUNITY3200REV1.

Page 3 of 51 iBeta Report Number: (V)2010-30Jun-001(D)

TABLE OF CONTENTS

APPENDIX A. B, AND G: TEST OPERATION, FINDINGS & DATA ANALYSIS................................................. 4

APPENDIX A: CERTIFICATION TEST REQUIREMENTS ................................................................................................ 4

APPENDIX B: PCA SOURCE CODE REVIEW........................................................................................................... 46

iBeta Unity 3.2.0.0 Revision 1 Source Code Review Results ...................................................................... 46

APPENDIX G: TRUSTED BUILD & VALIDATION TOOLS UNITY 3.2.0.0 REVISION 1..................................................... 48

Witness of the Trusted Build DS200 v.1.4.3.0.............................................................................................. 48

Witness of the Trusted Build DS200 Ancillary Devices ................................................................................ 49

System Identification Tools........................................................................................................................... 51
EAC Certification # ESSUNITY3200REV1.

Page 4 of 51 iBeta Report Number: (V)2010-30Jun-001(D)

APPENDIX A. B, and G: TEST OPERATION, FINDINGS & DATA ANALYSIS

Appendix A: Certification Test Requirements

Appendix A identifies the test results to the Certification Test Requirement in the original certified ESSUNITY3200 to the VSS 2002 of and the VVSG 2005 for the changes to 

the DS200 submitted in the Unity 3.2.0.0 Revision 1voting system. Requirements marked: 

 Accept: met the requirement

 Reject: did not meet the requirement

 NA: the requirement is not applicable to the voting system type submitted for Certification Testing 

Requirements marked Reject or NA include an explanatory note. (Example: If a voting system is only a Central Count Scanner, a DRE requirement is marked “NA” and a 

comment indicates “Not a DRE.") Optional requirements which apply to the voting system type but are not supported by the ES&S Unity 3.2.0.0 or Unity 3.2.0.0 Revision 

1are not marked "NA". Instead they are marked “Accept”, with an explanatory comment. The reason for this is to provide a positive identification that iBeta reviewed the 

voting system for all applicable requirements, including this optional functionality and confirmed non-support. (Example: If a voting system does not have a VVPAT. The 

requirements are marked “Accept” and a comment indicates “DRE does not have a VVPAT”.) The test case trace corresponds to the Test Methods identified in the Test 

Plan & Appendix D:

Unity 3.2.0.0 Revision 1 Testing

F -DS200= The DS200 Cosmetic and Functional Enhancements and Issues 

NA=The requirement is not applicable to the voting system type or is 

unmodified from Unity 3.2.0.0

E-DS200= Environmental testing enhancements to DS200

ESSUNITY3200 Unmodified= No changes, all testing is completed, the 

testing for results listed here is documented in the Unity 3.2.0.0 Test 

Report

E= Reuse Environmental & Reliability

F= Reuse SysTest Functional, Characteristics, Maintenance, Accessibility, 

Availability, Data Accuracy

R= Regression System Level

S= Security Test Case 

T= Telephony & Cryptographic Test Case

V1-10= Volume 1 through 10 Test Cases

NA= The requirement is not applicable to the voting system type

Issues identified during testing are cross-referenced to the Appendix E- Discrepancy Report. 

Maufacturer Voting System & Version Scope Prior EAC Certification#

ES&S Unity 3.2.0.0 Revision 1 Voting System Changes to the DS200 (VSS 2005) ESSUnity3200 (VSS 2002)

VSS 2002

VVSG 2005 

Certification Test Requirements: Test 

Results

Unity 3.2.0.0 

Revision 1

Comment ESSUNITY

3200

Comment

2.2 Overall System Capabilities 

2.2.1 Security

System security is achieved through a combination of technical capabilities and 

sound administrative practices. Te ensure security all systems shall:

a. Provide security access controls that limits limit or detect access to critical 

system components to guard against loss of system integrity, availability, 

confidentiality, and accountability. 

Accept S

b.

VVSG 2005 

2.1.1

Provide system functions that are executable only in the intended manner and 

order, and only under the intended conditions.

Accept S, R See Section 6 field issue 2

c. Use the system's control logic to prevent a system function from executing, if any 

preconditions to the function have not been met.

Accept S, R
EAC Certification # ESSUNITY3200REV1.

Page 5 of 51 iBeta Report Number: (V)2010-30Jun-001(D)

VSS 2002

VVSG 2005 

Certification Test Requirements: Test 

Results

Unity 3.2.0.0 

Revision 1

Comment ESSUNITY

3200

Comment

d. Provide safeguards to protect against tampering during system repair, or 

interventions in system operations, in response to system failure.

Accept S

e. Provide security provisions that are compatible with the procedures and 

administrative tasks involved in equipment preparation, testing, and operation.

Accept S

f. If access to a system function is to be restricted or controlled the system shall 

incorporate the means of implementing this capability.

Accept S

g. Provide documentation of mandatory administrative procedures for effective 

system security.

Accept S

2.2.2 Accuracy : To ensure vote accuracy, all systems shall:

2.2.2.1 Common Standards to Ensure Vote Accuracy To ensure vote accuracy, all 

systems shall:

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

election officials.

Accept F, R

b. Records the appropriate options for casting and recording votes. Accept F, R

c. Records each vote precisely as indicated by the voter and have the ability to 

produce an accurate report of all votes cast.

Accept F, R RFI 2007-06

d. Control logic and data processing methods incorporation parity and check sums 

(or equivalent error detection and correction methods) to demonstrate the 

system has been designed for accuracy.

Accept S

e. The software monitors the overall quality of data read-write and transfer quality 

status, checks the number and types of errors that occur in any of the relevant 

operations on data and how they were corrected.

Accept S

2.2.2.2 DRE System Standards: In additional DRE systems shall:

As an additional means of ensuring accuracy in DRE systems, voting devices 

record and retain redundant copies of the original ballot image. A ballot image 

electronic record of all votes cast by the voter, including undervotes.

Accept NA RFI 2007-06

No DRE

2.2.3

VVSG 2005 

2.1.3

Error Recovery: To recover from a non-catastrophic failure of a device, or from 

any error or malfunction that is within the operator's ability to correct, the system 

shall provide the following capabilities:

See Section 6 field issue 2

a. Restoration of the device to the operating condition existing immediately prior to 

an error or failure, without loss or corruption of voting data previously stored in 

the device

Accept S, V1-10, 

R, F

b. Resumption of normal operation following the correction of a failure in a memory 

component, or in a data processing component, including the central processing 

unit

Accept S, R, F

c. Recovery from any other external condition that causes equipment to become 

inoperable, provided that catastrophic electrical or mechanical damage due to 

external phenomena has not occurred.

Accept S, R, F

2.2.4 Integrity: Integrity measures ensure the physical stability and function of the 

vote recording and counting processes. To ensure system integrity, all systems 

shall:

2.2.4.1 Common Standards: To ensure system integrity, all systems shall:

a. Protect against a single point of failure that would prevent further voting at the 

polling place. 

Accept F

b. Protects against the interruption of electronic power. Accept F, V-5

c. Protects against electromagnetic radiation. Accept E

d. Protects against the ambient temperature and humidity fluctuations. Accept E

e. Protects against failure of any data input or storage device. Accept S, V4

f. Protects against any attempt at improper data entry or retrieval Accept S

g

VVSG 2005 

2.1.4.

Records and reports of any normal or abnormal events. Accept S See Section 6 field issue 2
EAC Certification # ESSUNITY3200REV1.

Page 6 of 51 iBeta Report Number: (V)2010-30Jun-001(D)

VSS 2002

VVSG 2005 

Certification Test Requirements: Test 

Results

Unity 3.2.0.0 

Revision 1

Comment ESSUNITY

3200

Comment

h. Maintains a permanent record of original audit data that cannot be bypassed or 

turned off.

Accept S

i.

VVSG 2005 

2.1.4.

Detect and record every event, including the occurrence of an error condition 

that the system cannot overcome, and time-dependent or programmed events 

that occur without the intervention of the voter or a polling place operator

Accept R See Section 6 field issue 2

j. Include built-in measurement, self-test, and diagnostic software and hardware 

for detecting and reporting the system's status and degree of operability

Accept F -DS200 S

2.2.4.2 DRE Systems Standards: 

In addition to the common requirements, DRE systems shall:

a. Maintain a record of each ballot cast using a process and storage location that 

differs from the main vote detection, interpretation, processing, and reporting 

path

Accept NA No DRE

b. Provide a capability to retrieve ballot images in a form readable by humans Accept NA No DRE

2.2.5 System Audit: See the requirement for context of these requirements. RFI 2008-12

2.2.5.2 Operational Requirements

VVSG 2005 

2.1.5.1

Audit records shall be prepared for all phases of election operations performed 

using devices controlled by the jurisdiction or its contractors. These records rely 

upon automated audit data acquisition and machine-generated reports, with 

manual input of some information. These records shall address the ballot 

preparation and election definition phase, system readiness tests, and voting 

and ballot-counting operations. The software shall activate the logging and 

reporting of audit data as described below.

Accept S, R, F See Section 6 field issue 2

2.2.5.2.1 Time, Sequence, and Preservation of Audit Records

The timing and sequence of audit record entries is as important as the data 

contained in the record. All voting systems shall meet the requirements for time, 

sequence and preservation of audit records outlined below.

a. Except where noted, systems shall provide the capability to create and maintain 

a real-time audit record. This capability records and provides the operator or 

precinct official with continuous updates on machine status. This information 

allows effective operator identification of an error condition requiring intervention, 

and contributes to the reconstruction of election-related events necessary for 

recounts or litigation.

Accept S, R, F

b. All systems shall include a real-time clock as part of the system‟s hardware. The 

system shall maintain an absolute record of the time and date or a record 

relative to some event whose time and data are known and recorded.

Accept S, R, F

c. All audit record entries shall include the time-and-date stamp. Accept S, R, F

d. The audit record shall be active whenever the system is in an operating mode. 

This record shall be available at all times, though it need not be continually 

visible.

Accept S, R, F

e. The generation of audit record entries shall not be terminated or altered by 

program control, or by the intervention of any person. The physical security and 

integrity of the record shall be maintained at all times.

Accept S, R, F

f. Once the system has been activated for any function, the system shall preserve 

the contents of the audit record during any interruption of power to the system 

until processing and data reporting have been completed.

Accept S, R, F

g.

1)

2)

3)

The system shall be capable of printing a copy of the audit record. A separate 

printer is not required for the audit record, and the record may be produced on

the standard system printer if all the following conditions are met:

• The generation of audit trail records does not interfere with the production

of output reports

• The entries can be identified so as to facilitate their recognition,

segregation, and retention

• The audit record entries are kept physically secure

Accept S, R, F
EAC Certification # ESSUNITY3200REV1.

Page 7 of 51 iBeta Report Number: (V)2010-30Jun-001(D)

VSS 2002

VVSG 2005 

Certification Test Requirements: Test 

Results

Unity 3.2.0.0 

Revision 1

Comment ESSUNITY

3200

Comment

2.2.5.2.2 Error messages

All voting systems shall meet the requirements for error messages below.

a.

VVSG 

2.1.5.1.b.i

The voting system shall generate, store, and report to the user all error 

messages as they occur. 

Accept F -DS200 Field Report 2: 

Accepted per 

VVSG Appx. B5 

no documented 

report of loss or 

corruption of vote 

data.

S, R, F See: Voting System Technical 

Advisory Intermittent 

Freeze/Shutdowns with EAC 

Certified ES&S Unity 3.2.0.0 

System

See Section 6 field issue 2

b.

VVSG 

2.1.5.1.b.ii

All error messages requiring intervention by an operator or precinct official shall 

be displayed or printed clearly in easily understood language text, or by means 

of other suitable visual indicators.

Accept F -DS200 Field Report 2: 

Accepted per 

VVSG Appx. B5 

no documented 

report of loss or 

corruption of vote 

data.

S, R, F See: Voting System Technical 

Advisory Intermittent 

Freeze/Shutdowns with EAC 

Certified ES&S Unity 3.2.0.0 

System

See Section 6 field issue 2

c.

VVSG 

2.1.5.1.b.iii

When the voting system uses numerical error codes for trained technician 

maintenance or repair, the text corresponding to the code shall be self-contained 

or affixed inside the voting machine. This is intended to reduce inappropriate 

reactions to error conditions, and to allow for ready and effective problem 

correction.

Accept

F -DS200

S, R, F

d.

VVSG 

2.1.5.1.b.iv

All error messages for which correction impacts vote recording or vote 

processing shall be written in a manner that is understandable to an election 

official who possesses training on system use and operation, but does not 

possess technical training on system servicing and repair.

Accept F -DS200 Discrepancy #2

Closed

S, R, F

e.

VVSG 

2.1.5.1.b.v

The message cue for all voting systems shall clearly state the action to be 

performed in the event that voter or operator response is required. 

Accept F -DS200 S, R, F

f.

VVSG 

2.1.5.1.b.vi

Voting system design shall ensure that erroneous responses will not lead to 

irreversible error. 

Accept F -DS200 S, R, F

g.

VVSG 

2.1.5.1.b.vii

Nested error conditions are corrected in a controlled sequence such that voting 

system status shall be restored to the initial state existing before the first error 

occurred.

Accept F -DS200 S, R, F

2.2.5.2.3 Status Messages: The Standards/Guidelines provide latitude in software design 

so that vendors can consider various user processing and reporting needs. The 

jurisdiction may require some status and information messages to be displayed 

and reported in real-time. Messages that do not require operator intervention 

may be stored in memory to be recovered after ballot processing has been 

completed.

The voting system shall display and report critical status messages using clear 

indicators or English language text. The voting system need not display noncritical status messages at the time of occurrence. Voting systems may display 

non-critical status messages (i.e., those that do not require operator intervention) 

by means of numerical codes for subsequent interpretation and reporting as 

unambiguous text.

Accept F -DS200 S, R, F

Voting systems shall provide a capability for the status messages to become 

part of the real-time audit record.

Accept F -DS200 S, R, F

The voting system shall provide a capability for a jurisdiction to designate critical 

status messages.

Accept F -DS200 S, R, F

2.2.5.3 COTS General Purpose Computer System Requirements: See the standards 

for the context these requirements. Three operating system protections are 

required on all such systems on which election software is hosted. 

RFI 2008-03

RFI 2008-12
EAC Certification # ESSUNITY3200REV1.

Page 8 of 51 iBeta Report Number: (V)2010-30Jun-001(D)

VSS 2002

VVSG 2005 

Certification Test Requirements: Test 

Results

Unity 3.2.0.0 

Revision 1

Comment ESSUNITY

3200

Comment

Authentication shall be configured on the local terminal (display screen and 

keyboard) and on all external connection devices (“network cards” and “ports”). 

This ensures that only authorized and identified users affect the system while 

election software is running.

Accept S

Operating system audit shall be enabled for all session openings and closings, 

for all connection openings and closings, for all process executions and 

terminations, and for the alteration or deletion of any memory or file object. This 

ensures the accuracy and completeness of election data stored on the system. It 

also ensures the existence of an audit record of any person or process altering 

or deleting system data or election data.

Accept S

The system shall be configured to execute only intended and necessary 

processes during the execution of election software. The system shall also be 

configured to halt election software processes upon the termination of any 

critical system process (such as system audit) during the execution of election 

software.

Accept S

2.2.6 Election Management System

VVSG 2005 

2.1.6

The Election Management System (EMS) is used to prepare ballots and 

programs for use in casting and counting votes, and to consolidate, report, and 

display election results. An EMS shall generate and maintain a database, or one 

or more interactive databases, that enables election officials or their designees 

to perform the following functions:

Accept F, R

a

VVSG 2005 

2.1.6

Define of the political subdivision boundaries and multiple election districts, as 

indicated in the system documentation.

Accept F -DS200 F, R

b.

VVSG 2005 

2.1.6

Identify of contests, candidates, and issues. Accept F -DS200 F, R

c.

VVSG 2005 

2.1.6

Define of ballot formats and appropriate voting options. Accept F -DS200 F, R

d. Generate ballots and election-specific programs for vote recording and vote 

counting equipment.

Accept F, R

e. Install ballots and election-specific programs. Accept F, R

f. Test that ballots and programs have been properly prepared and installed. Accept F, R

g. Accumulate vote totals at multiple reporting levels as indicated in the system 

documentation.

Accept F, R

h. Generate of post-voting reports per Section 2.4. Accept F, R

VVSG 2005 Generate of post-voting reports per Section 2.4. Accept F, R

i. Process and produce audit reports of the data indicated in Section 4.5. Accept F, R

2.2.7 Accessibility

2.2.7.1 Common Standards: See the standard for diagrams. The voting system meets 

the following conditions: 

a. Where clear floor space only allows forward approach to an object, the 

maximum high forward reach allowed shall be 48inches. The minimum low 

forward reach is 15 inches.

Accept F

b. Where forward reach is over an obstruction with knee space below, the 

maximum level forward reach is 25 inches. When the obstruction is less than 20 

inches deep, the maximum high forward reach is 48 inches. When the 

obstruction projects 20 to 25 inches, the maximum high forward reach is 44 

inches.

Accept F
EAC Certification # ESSUNITY3200REV1.

Page 9 of 51 iBeta Report Number: (V)2010-30Jun-001(D)

VSS 2002

VVSG 2005 

Certification Test Requirements: Test 

Results

Unity 3.2.0.0 

Revision 1

Comment ESSUNITY

3200

Comment

c. The position of any operable control is determined with respect to a vertical 

plane that is 48 inches in length, centered on the operable control, and at the 

maximum protrusion of the product within the 48-inch length.

Accept F

d. Where any operable control is 10 inches or less behind the reference plane, 

have a height that is between 15 inches and 54 inches above the floor.

Accept F

e. Where any operable control is more than 10 inches and not more than 24 inches 

behind the reference plane, have a height between 15 inches and 46 inches 

above the floor.

Accept F

f. Have operable controls that are not more than 24 inches behind the reference 

plane.

Accept F

2.2.7.2 DRE Standards for Accessibility: DRE voting systems shall provide, as part of 

their configuration, the capability to provide access to voters with a broad range 

of disabilities. This capability shall:

a. Not require the voter to bring their own assistive technology to a polling place. Accept F VAT - Ballot marking only

b Provide Audio information and stimulus that:

b.1. Communicates to the voter the complete content of the ballot. Accept F VAT - Ballot marking only

b.2. Provides instruction to the voter in operation of the voting device. Accept F VAT - Ballot marking only

b.3. Provides instruction so that the voter has the same vote capabilities and options 

as those provided by the system to individuals who are not using audio 

technology

Accept F VAT - Ballot marking only

b.4. For a system that supports write-in voting, enables the voter to review the voter‟s 

write-in input, edit that input, and confirm that the edits meet the voter‟s intent.

Accept F VAT - Ballot marking only

b.5. Enables the voter to request repetition of any system provided information. Accept F VAT - Ballot marking only

b.6. Supports the use of headphones provided by the system that may be discarded 

after each use

Accept F VAT - Ballot marking only

b.7. Provides the audio signal through an industry standard connector for private 

listening using a 1/8 inch stereo headphone jack to allow individual voters to 

supply personal headsets

Accept F VAT - Ballot marking only

b.8. Provides a volume control with an adjustable amplification up to a maximum of 

105 dB that automatically resets to the default for each voter

Accept F VAT - Ballot marking only

c. Provide, in conformance with FCC Part 68, a wireless coupling for assistive 

devices used by people who are hard of hearing when a system utilizes a 

telephone style handset to provide audio information

Accept F VAT - Ballot marking only

d. Meet the requirements of ANSI C63.19-2001 Category 4 to avoid 

electromagnetic interference with assistive hearing devices

Accept F VAT - Ballot marking only

e. For Electronic Image Displays, permit the voter to:

e.1. Adjust contrast settings Accept F VAT - Ballot marking only

e.2. Adjust color settings, when color is used Accept F VAT - Ballot marking only

e.3. Adjust the size of the text so that the height of capital letters varies over a range 

of 3 to 6.3 millimeters

Accept F VAT - Ballot marking only

f. For a devise with touch screen or contact-sensitive controls, provide an input 

method using mechanically operated controls or keys that shall:

f.1. Be tactilely discernible without activating the controls or keys. Accept F VAT - Ballot marking only

f.2. Be operable with one hand and not require tight grasping, pinching, or twisting of 

the wrist.

Accept F VAT - Ballot marking only

f.3. Require a force less than 5 lbs (22.2 N) to operate. Accept F VAT - Ballot marking only

f.4. Provide no key repeat function. Accept F VAT - Ballot marking only

g. For a system that requires a response by a voter in a specific period of time, 

alert the voter before this time period has expired and allow the voter additional 

time to indicate that more time is needed

Accept F VAT - Ballot marking only
EAC Certification # ESSUNITY3200REV1.

Page 10 of 51 iBeta Report Number: (V)2010-30Jun-001(D)

VSS 2002

VVSG 2005 

Certification Test Requirements: Test 

Results

Unity 3.2.0.0 

Revision 1

Comment ESSUNITY

3200

Comment

h. For a system that provides sound cues as a method to alert the voter about a 

certain condition, such as the occurrence of an error, or a confirmation, the tone 

shall be accompanied by a visual cue for users who cannot hear the audio 

prompt

Accept F VAT - Ballot marking only

i. Provide a secondary means of voter identification or authentication when the 

primary means of doing so uses biometric measures that require a voter to 

possess particular biological characteristics

Accept F VAT has no biometric measures

2.2.8 Vote Tabulating Program

2.2.8.1 Functions 

The vote tabulating program software resident in each voting machine, vote 

count server, or other devices shall include all software modules required to:

a. Monitor of system status and generating machine-level audit reports Accept F, R

b. Accommodate device control functions performed by polling place officials and 

maintenance personnel

Accept F, R

c. Register and accumulating votes Accept F, R

d. Accommodate variations in ballot counting logic Accept F, R

2.2.8.2 Voting Variation 

The Technical Data Package accompanying the system shall specifically identify 

which of the following items can and cannot be supported by the voting system, 

as well as how the voting system can implement the items support.

a. Documented support or non-support of closed primaries. Accept F

b. 

VVSG 2005 

2.1.7.2

Documented support or non-support of open primaries. Accept

F -DS200

F

c. 

VVSG 2005 

2.1.7.2

Documented support or non-support of partisan offices. Accept

F -DS200

F

d. Documented support or non-support of non-partisan offices. Accept F

e. 

VVSG 2005 

2.1.7.2

Documented support or non-support of write-in voting. Accept

F -DS200

F

f. Documented support or non-support of Primary presidential delegation 

nomination.

Accept F

g. Documented support or non-support of ballot rotation. Accept F

h. Documented support or non-support of straight party voting. Accept F

i. Documented support or non-support of cross-party endorsement Accept F

j. Documented support or non-support of split precincts. Accept F

k. . 

VVSG 2005 

2.1.7.2

Documented support or non-support of vote for N of M. Accept F -DS200 F

l. Documented support or non-support of recall issues, with options. Accept F

m. Documented support or non-support of cumulative voting. Accept F

n. Documented support or non-support of ranked over voting. Accept F

o. Documented support or non-support of provisional or challenged ballots. Accept F

2.2.9 Ballot Counter : For all voting systems, each device that tabulates ballots shall 

provide a counter that:.

a. Can be set to zero before any ballots are submitted for tally Accept F, R

b. Records the number of ballots cast during a particular test cycle or election Accept F, R

c. Increases the count only by the input of a ballot Accept F, R

d. Prevents or disables the resetting of the counter by any person other than 

authorized persons at authorized points

Accept F

e. Is visible to designated election officials Accept F, R
EAC Certification # ESSUNITY3200REV1.

Page 11 of 51 iBeta Report Number: (V)2010-30Jun-001(D)

VSS 2002

VVSG 2005 

Certification Test Requirements: Test 

Results

Unity 3.2.0.0 

Revision 1

Comment ESSUNITY

3200

Comment

2.2.10 Telecommunications

For all voting systems that use telecommunications for the transmission of data 

during pre-voting, voting or post-voting activities, capabilities shall be provided 

that ensure data are transmitted with no alteration or unauthorized disclosure 

during transmission. Such transmissions shall not violate the privacy, secrecy, 

and integrity demands of the Standards. Section 5 of the Standards describes 

telecommunications standards that apply to, at a minimum, the following types of 

data transmissions:

Voter Authentication: Coded information that confirms the identity of a voter for 

security purposes for a system that transmit votes individually over a public 

network 

Accept S, T Telecommunications is disabled in 

Unity 3.2.0.0

Ballot Definition: Information that describes to voting equipment the content and 

appearance of the ballots to be used in an election

Accept S, T Telecommunications is disabled in 

Unity 3.2.0.0

Vote Transmission to Central Site: For voting systems that transmit votes 

individually over a public network, the transmission of a single vote to the county 

(or contractor) for consolidation with other county vote data

Accept S, T Telecommunications is disabled in 

Unity 3.2.0.0

Vote Count: Information representing the tabulation of votes at any one of 

several levels: polling place, precinct, or central count

Accept S, T Telecommunications is disabled in 

Unity 3.2.0.0

List of Voters: A listing of the individual voters who have cast ballots in a specific 

election

Accept S, T Telecommunications is disabled in 

Unity 3.2.0.0

2.2.11 Data Retention: See standard/guideline for context.

All voting systems shall provide for maintaining the integrity of voting and audit 

data during an election and for a period of at least 22 months thereafter.

Accept TDP Attestation from ESS

2.3 Pre-voting Functions #50 Closed

2.3.1 Ballot Preparation

2.3.1.1 General Capabilities

 VVSG2005

2.2.1.1

All systems shall provide the general capability for ballot preparation, ballot 

formatting and ballot production. All systems shall be capable of:

Accept F -DS200 F, R

2.3.1.1.1 Common Standards: All systems shall be capable of: 

a. Enable the automatic formatting of ballots in accordance with the requirements 

for offices, candidates, and measures qualified to be placed on the ballot for 

each political subdivision and election district.

Accept F, R

b.

1)

2)

3)

Collecting and maintaining the following data: 

Offices with labels/instructions

Candidate names with labels

Issues or measures with their text

Accept F, R

c. Supporting the maximum number of potentially active voting positions as 

indicated in the system documentation.

Accept F, V8

d. For a primary election, generating ballots that segregate the choices in partisan 

races by party affiliation

Accept F, R

e. Generating ballots that contain identifying codes or marks uniquely associated 

with each format.

Accept F, R

f. Ensuring voter response fields, selection buttons, or switches properly align with 

the specific candidate names and/or issues printed on the ballot display, ballot 

card or sheet, or separate ballot pages.

Accept F, R

2.3.1.1.2 Paper-Based System Standards: Paper-based voting systems shall also meet 

the following requirements applicable to the technology used.

a. 

VVSG 2005 

2.2.1.1.g

Enable voters to make selections by punching a hole or by making a mark in 

areas designated for this purpose upon each ballot card or sheet.

Accept F -DS200 F, R

b. For punchcard systems ensure that the vote response fields can be properly 

aligned with punching devices used to record votes.

Accept NA Not a punchcard system
EAC Certification # ESSUNITY3200REV1.

Page 12 of 51 iBeta Report Number: (V)2010-30Jun-001(D)

VSS 2002

VVSG 2005 

Certification Test Requirements: Test 

Results

Unity 3.2.0.0 

Revision 1

Comment ESSUNITY

3200

Comment

c. . 

VVSG 2005 

2.2.1.1.h

For marksense systems, the timing marks align properly with the vote response 

fields.

Accept F -DS200 F, R

2.3.1.2 Ballot Formatting All voting systems shall provide a capability for: 

a. Creation of newly defined elections Accept F, R

b. Rapid and error-free definition of elections and their associated ballot layouts Accept F,R

c. Uniform allocation of space and fonts used for each office, candidate, and 

contest such that the voter perceives no active voting position to be preferred to 

any other.

Accept F, R

d. Simultaneous display of the maximum number of choices for a single contest as 

indicated by the vendor in the system documentation

Accept F

e. Retention of previously defined formats for an election Accept F, R

f. Prevention of unauthorized modification of any ballot formats Accept F, R

g. Modification by authorized persons of a previously defined ballot format for use 

in a subsequent election

Accept F, V3 & 4

2.3.1.3 Ballot Production

Ballot production is the process of converting ballot formats to a media ready for 

use in the physical ballot production or electronic presentation.

2.3.1.3.1 Common Standards

The voting system shall provide a means of printing or other wise generating a 

ballot display that can be installed in all system voting devices for which it is 

intended: All systems shall provide a capability to ensure. 

a. The electronic display or printed document on which the user views the ballot is 

capable of rendering an image of the ballot in any of the languages required by 

The Voting Rights Act of 1965, as amended

Accept F RFI 2008-04

b. The electronic display or printed document where the user views the ballot does 

not show any advertising or commercial logos of any kind, whether public 

service, commercial, or political, unless specifically provided for in State law. 

Electronic displays do not provide connection through hyperlink.

Accept F

c. The ballot conforms to vendor specifications for type of paper stock, weight, size, 

shape, size and location of punch or mark field used to record votes, folding, 

bleed through, and ink for printing if paper ballot documents or paper displays 

are part of the system

Accept F, R

2.3.1.3.2 Paper-based System Standards

Vendor documentation for marksense systems shall include specifications for 

ballot materials to ensure that vote selections are read from only a single ballot 

at a time, without detection of marks from multiple ballots concurrently (e.g., 

reading of bleed-through from other ballots)

Accept F

2.3.2 Election Programming 

Process by which election officials or their designees use election databases 

and vendor system software to logically define the voter choices associated with 

the contents of the ballots. All systems shall provide for: 

a. Logical definition of the ballot, including the definition of the number of allowable 

choices for each office and contest

Accept F, R

b. Logical definition of political and administrative subdivisions, where the list of 

candidates or contests varies between polling places

Accept F, R

c. Exclusion of any contest on the ballot in which the voter is prohibited from 

casting a ballot because of place of residence, or other such administrative or 

geographical criteria

Accept F, R

d. Ability to select from a range of voting options to conform to the laws of the 

jurisdiction in which the system will be used

Accept F, R
EAC Certification # ESSUNITY3200REV1.

Page 13 of 51 iBeta Report Number: (V)2010-30Jun-001(D)

VSS 2002

VVSG 2005 

Certification Test Requirements: Test 

Results

Unity 3.2.0.0 

Revision 1

Comment ESSUNITY

3200

Comment

e. Generation of all required master and distributed copies of the voting program, in 

conformance with the definition of the ballots for each voting device and polling 

place, and for each tabulating device

Accept F, R

2.3.3 Ballot and Program Installation and Control: All systems shall include the 

following at the time of ballot an program installation:

Accept

All systems provide a means of installing ballots and programs on each piece of 

polling place or central count equipment according to the ballot requirements of 

the election and the jurisdiction. 

Accept F, R

a. A detailed work plan or other documentation providing a schedule and steps for 

the software and ballot installation, including a table outlining the key dates, 

events and deliverables.

Accept F

b. A capability for automatically verifying that the software has been properly 

selected and installed in the equipment or in programmable memory devices and 

for indicating errors. 

Accept F,S

c. A capability for automatically validating that software correctly matches the ballot 

formats that it is intended to process, for detecting errors, and for immediately 

notifying an election official of detected errors. 

Accept F, S

2.3.4 Readiness Testing: Election personnel conduct voting equipment and voting 

system readiness tests prior to the start of an election to ensure that the voting 

system functions properly, to confirm that voting equipment has been properly 

integrated, and to obtain equipment status reports. All voting systems shall 

provide the capabilities to

2.3.4.1 Common Standards: All voting systems shall provide the capabilities to:

a. Verify the voting machines or vote recording and data processing equipment, 

precinct count equipment, and central count equipment are properly prepared for 

an election, and collect data that verifies equipment readiness

Accept F, S

b. 

VVSG 2005 

2.2.4.b

Obtains status and data reports from each set of equipment Accept

F -DS200

F, R

c. Verify the correct installation and interface of all system equipment Accept F, R

d. Verify that hardware and software function correctly Accept F, R

e. Generate consolidated data reports at the polling place and higher jurisdictional 

levels

Accept F, R

f. Segregate test data from actual voting data, either procedurally or by 

hardware/software features

Accept F, R

Resident test software, external devices, and special purpose test software 

connected to or installed in voting devices to simulate operator and voter 

functions used for these tests meeting the following standards: 

a. These elements are capable of being tested separately, and are proven to be 

reliable verification tools prior to their use

Accept F

b. These elements are incapable of altering or introducing any residual effect on 

the intended operation of the voting device during any succeeding test and 

operational phase.

Accept F

2.3.4.2 Paper-Based Systems

Paper-based systems shall:

a. Supports conversion testing that uses all potential ballot positions as active 

positions

Accept F

b. Supports conversion testing of ballots with active position density for systems 

without pre-designated ballot positions

Accept F

2.3.5 Verification at the Polling Place

All systems shall provide a formal record of the following, in any media, upon 

verification of the authenticity of the command source:

RFI 2008-07

a. The election's identification data; Accept F, R
EAC Certification # ESSUNITY3200REV1.

Page 14 of 51 iBeta Report Number: (V)2010-30Jun-001(D)

VSS 2002

VVSG 2005 

Certification Test Requirements: Test 

Results

Unity 3.2.0.0 

Revision 1

Comment ESSUNITY

3200

Comment

b. The identification of all equipment units; Accept F, R

c. The identification of the polling place; Accept F, R

d. The identification of all ballot formats; Accept F, R

e. The contents of each active candidate register by office and of each active 

measure register at all storage locations (showing that they contain only zeros);

Accept F, R, S

f. A list of all ballot fields that can be used to invoke special voting options Accept F

g. Other information needed to confirm the readiness of the equipment, and to 

accommodate administrative reporting requirements

Accept F, R

To prepare voting devices to accept voted ballots, all voting systems shall 

provide the capability to test each device prior to opening to verify that each is 

operating correctly. At a minimum the tests shall include.

Accept F, R

a. Confirmation that there are no hardware or software failures. Accept F, R

b. Confirmation that the device is ready to be activated for accepting votes. Accept F, R

If a precinct count system includes equipment for the consolidation of polling 

place data at one or more central counting locations, it shall have means to 

verify the correct extraction of voting data from transportable memory devices, or 

to verify the transmission of secure data over secure communication links.

Accept F, R Telecommunications is disabled in 

Unity 3.2.0.0

2.3.6 Verification at Central Location

Election officials perform verification at the central location to ensure that vote 

counting and vote consolidation equipment and software function properly before 

and after an election. Upon verification of the authenticity of the command 

source, any system used in a central count environment shall provide a printed 

record of the following:

RFI 2008-07

a. The election's identification data Accept F, R

b. The contents of each active candidate register by office and of each active 

measure register at all storage locations (showing that they contain only zeros);

Accept F, R S S - per v.2: 3.3.1

c. Other information needed to confirm the readiness of the equipment, and to 

accommodate administrative reporting requirements.

Accept F, R

2.4 Voting Functions 

All voting systems shall support

Opening the polls Accept F, R

Casting the ballot Accept F, R

In addition, all DRE systems shall support:

Activating the ballot

Accept F, R

Augmenting the election counter Accept F, R VAT

Augmenting the life-cycle counter Accept NA No DRE

2.4.1. Opening the Polls

At a minimum, the systems shall provide the functional capabilities indicated 

below.

RFI 2008-07

2.4.1.1 Opening the polling Place (Precinct Count Systems) 

To allow voting devices to be activated for voting, the system shall provide:

a An internal test or diagnostic capability to verify that all of the polling place tests 

specified in 2.3.5 have been successfully completed.

Accept F, R,S S - per v.2: 3.3.1

VVSG 2005 

2.3.1.1

Paper-Based System Requirements

To facilitate opening the polls, all paper-based systems shall include:

a. An internal test or diagnostic capability to verify that all of the polling place tests 

specified in 2.2.5 have been successfully completed.

Accept F -DS200, F, R,S S - per v.2: 3.3.1

b. Automatic disabling any device that has not been tested until it has been tested. Accept F, R,S S - per v.2: 3.3.1

2.4.1.2 Paper-Based System Standards

2.4.1.2.1 All Paper-Based systems

To facilitate opening the polls, all paper-based systems shall include: 
EAC Certification # ESSUNITY3200REV1.

Page 15 of 51 iBeta Report Number: (V)2010-30Jun-001(D)

VSS 2002

VVSG 2005 

Certification Test Requirements: Test 

Results

Unity 3.2.0.0 

Revision 1

Comment ESSUNITY

3200

Comment

VVSG 2005 

2.3.1.2

Precinct Count Systems

To allow voting devices to be activated for voting, all precinct count systems 

shall provide:

a. A means of verifying ballot punching or marking devices are prepared and ready 

to used;

Accept

F -DS200

F, R No ballot punching

b. A voting booth or similar facility, in which the voter may punch or mark the ballot 

in privacy

Accept F No ballot punching

c. Secure receptacles for holding voted ballots. Ballot boxes. Accept F, R, S DS200

2.4.1.2.2 Precinct Count Paper-Based Systems

In addition to the above requirements, all paper-based precinct count equipment 

shall include a means of: 

a. 

VVSG 2005 

2.3.1.2.d

Activating the ballot counting device. Accept

F -DS200

F, R

b. 

VVSG 2005 

2.3.1.2.e

Verifying that the device has been correctly activated and is functioning properly Accept

F -DS200

F, R

c. 

VVSG 2005 

2.3.1.2.f.

Identifying device failure and corrective action needed. Accept

F -DS200

F, R

2.4.1.3 DRE System Standards

To facilitate opening the polls, all DRE systems shall include:

a. A security seal, a password, or a data code recognition capability to prevent the 

inadvertent or unauthorized actuation of the poll-opening function

Accept F, R, S VAT doesn't open polls; it just 

switches to election marking mode

b. A means of enforcing the execution of steps in the proper sequence if more than 

one step is required

Accept F

c. A means of verifying the system has been activated correctly Accept F, R

d. A means of identifying system failure and any corrective action needed Accept F

2.4.2 Activating the Ballot (DRE Systems)

To activate the ballot, all DRE systems shall:

a. Enable election officials to control the content of the ballot presented to the 

voter, whether presented in printed form or electronic display, such that each 

voter is permitted to record votes only in contests in which that voter is 

authorized to vote

Accept F, R VAT ballot marking functionality

b. Allow each eligible voter to cast a ballot Accept F, R

c. Prevent a voter from voting on a ballot to which he or she is not entitled Accept F, R

d. Prevent a voter from casting more than one ballot in the same election Accept F, R Blank paper ballot required

e. Activate the casting of a ballot in a general election Accept F

f. Enable the selection of the ballot that is appropriate to the party affiliation 

declared by the voter in a primary election

Accept F, R Appropriate blank paper ballot 

required

g. Activate all parts of the ballot upon which the voter is entitled to vote Accept F,R Some controls in addition to the 

paper ballot

h. Disable of all parts of the ballot upon which the voter is not entitled to vote Accept F,R Some controls in addition to the 

paper ballot

2.4.3 Casting a Ballot

2.4.3.1 Common Standards

To facilitate casting a ballot, all systems shall:

VVSG 2005 

2.3.3.1

Common Requirements

To facilitate casting a ballot. all systems shall:

a. Provide test that is at least 3 millimeters high and provide the capability to adjust 

or magnify the text to an apparent size of 6.3 millimeters

Accept F
EAC Certification # ESSUNITY3200REV1.

Page 16 of 51 iBeta Report Number: (V)2010-30Jun-001(D)

VSS 2002

VVSG 2005 

Certification Test Requirements: Test 

Results

Unity 3.2.0.0 

Revision 1

Comment ESSUNITY

3200

Comment

b. Protect the secrecy of the vote such that the system cannot reveal any 

information about how a particular voter voted, except as otherwise required by 

individual State law

Accept

F -DS200

F, R

c. Record the selection and non-selection (undervote) of individual vote choices for 

each contest and ballot measure

Accept

F -DS200

F, R

d. 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-in votes as the 

number of candidates the voter is allowed to select

Accept

F -DS200

F, R

e. 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 voters to resume voting once 

the voting system has reverted to back-up power 

Accept F, V5

f. Provide the capability for voters to continue cast ballots in the event of a failure 

of a telecommunications connection within the polling place or between the 

polling place and any other location

Accept S, T Telecommunications is disabled in 

Unity 3.2.0.0

2.4.3.2 paper-based System Standards

2.4.3.2.1 All Paper-Based Systems

All paper-based systems shall: 

VVSG 2005 

2.3.3.2

Paper-based System Requirement

All paper-based systems shall:

a. Allow the voter to easily identify the voting field that is associated with each 

candidate or ballot measure response

Accept

F -DS200

F, R

b. Allow the voter to punch or mark the ballot to register a vote Accept F, R

VVSG 2005 

2.3.3.2.b.

Allow the voter to mark the ballot to register a vote Accept F -DS200 F, R

c. Allow either the voter or the appropriate election official is able to place the voted 

ballot into the ballot counting device (precinct count systems) or a secure 

receptacle (central count systems)

Accept

F -DS200

F, R

d. Protect the secrecy of the vote throughout the process Accept

F -DS200

F, R

2.4.3.2.2 Precinct Count Paper-Based Systems

In addition to the above requirements, all paper-based precinct count equipment 

shall include a means of: 

a. VVSG 

2005 

2.3.3.2.e.

Provide feedback to the voter identifies specific contests or ballot issues for 

which an overvote or undervote is detected

Accept

F -DS200

F, R

b. Allow the voter, at the voter‟s choice, to vote a new ballot or submit the ballot „as 

is‟ without correction

Accept F, R

c. Allow an authorized election official to turn off the capabilities defined in the two 

prior provisions. 

Accept F

VVSG 2005 

2.3.3.2.f.

Notify the voter if he or she has made more than the allowable number of 

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

Accept F -DS200

VVSG 2005 

2.3.3.2.g

Notify the voter before the ballot is cast and counted of the effect of making more 

than the allowable number of selections for a contest

Accept F -DS200

VVSG 2005 

2.3.3.2.h

Provide the voter opportunity to correct the ballot for either an undervote or 

overvote before the ballot is cast and counted

Accept F -DS200

2.4.3.3 DRE Systems Standards
EAC Certification # ESSUNITY3200REV1.

Page 17 of 51 iBeta Report Number: (V)2010-30Jun-001(D)

VSS 2002

VVSG 2005 

Certification Test Requirements: Test 

Results

Unity 3.2.0.0 

Revision 1

Comment ESSUNITY

3200

Comment

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

screen that has not been authorized by election officials and preprogrammed 

into the voting system (i.e., no potential for display of external information or 

linking to other information sources)

Accept F,S VAT ballot marking

b. Enable the voter to easily identify the selection button or switch, or the active 

area of the ballot display that is associated with each candidate or ballot 

measure response

Accept F, R VAT ballot marking

c. Allow the voter to select his or her preferences on the ballot in any legal number 

and combination

Accept F, R VAT ballot marking

d. Indicate that a selection has been made or canceled Accept F, R VAT ballot marking

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

has been made in a contest (e.g. undervotes)

Accept F, R VAT ballot marking

f. Prevent the voter from overvoting Accept F, R VAT ballot marking

g. Notify the voter when the selection of candidates and measures is completed Accept F, R VAT ballot marking

h. Allowing the voter, before the ballot is cast, to review his or her choices and, if 

the voter desires, to delete or change his or her choices before the ballot is cast

Accept F, R VAT ballot marking

i. For electronic image displays, prompt the voter to confirm the voter's choices 

before casting his or her ballot, signifying to the voter that casting the ballot is 

irrevocable and directing the voter to confirm the voter‟s intention to cast the 

ballot

Accept F, R VAT ballot marking: printing is 

irrevocable but not casting of the 

ballot

j. Notify the voter after the vote has been stored successfully that the ballot has 

been cast

Accept No DRE

k Notify the voter that the ballot has not been cast successfully if it is not stored 

successfully, including storage of the ballot image, and provide clear instruction 

as to the steps the voter should take to cast his or her ballot should this event 

occur

Accept No DRE

l. Provides sufficient computational performance to provide responses back to 

each voter entry in no more than three seconds

Accept F VAT ballot marking; printing 

exceeds 3 seconds

m. The votes stored accurately represent the actual votes cast Accept F, R Storage is ballot printing

n. Preventing modification of the voter‟s vote after the ballot is cast Accept S Paper ballot handling 

documentation

o. Provides a capability to retrieve ballot images in a form readable by humans (in 

accordance with the requirements of Section 2.2.2.2 and 2.2.4.2)

Accept No DRE

p. Incrementing the proper ballot position registers or counters Accept F, R Counts successful prints, not votes 

cast

q. Protecting the secrecy of the vote throughout the voting process Accept F, R

r. Prohibiting access to voted ballots until after the close of polls Accept No DRE

s. Provides the ability for election officials to submit test ballots for use in verifying 

the end-to-end integrity of the system

Accept F, R

t. Isolating test ballots such that they are accounted for accurately in vote counts 

and are not reflect in official vote counts for specific candidates or measures

Accept F, R VAT has a separate test mode; 

isolating ballot is procedural

2.5 Post-Voting Functions

All systems shall provide capabilities to accumulate and report results for 

the jurisdiction and to generate audit trails. In additions precinct count 

systems must provide a means to close the polling place including 

generating appropriate reports if the system provide the capability to 

broadcast results, additional standards apply.

VVSG 2005 

2.4

Post Vote Capabilities

All systems shall provide capabilities to accumulate and report results for the 

jurisdiction and to generate audit trails. In additions precinct count systems must 

provide a means to close the polls including generating appropriate reports if the 

system provide the capability to broadcast results, additional standards apply
EAC Certification # ESSUNITY3200REV1.

Page 18 of 51 iBeta Report Number: (V)2010-30Jun-001(D)

VSS 2002

VVSG 2005 

Certification Test Requirements: Test 

Results

Unity 3.2.0.0 

Revision 1

Comment ESSUNITY

3200

Comment

2.5.1 Closing the Polling Place (Precinct Count)

These standards for closing the polls are specific to precinct count systems. The 

system shall provide the means for:

VVSG 2005 

2.4.1

Closing the Polls

These requirements for closing the polls and locking voting systems against 

future voting are specific to precinct count systems. The voting system shall 

provide the means for:

a. Preventing the further casting of ballots once the polls has closed Accept F, R VAT doesn't close, switched to Off 

b. Provides an internal test that verifies that the prescribed closing procedure has 

been followed, and that the device status is normal

Accept

F -DS200

F, R

c. Incorporating a visible indication of system status Accept F, R

d. Producing a diagnostic test record that verifies the sequence of events, and 

indicates that the extraction of voting data has been activated

Accept F, R

e. Precluding the unauthorized reopening of the polls once the poll closing has 

been completed for that election

Accept F, R DS200 reopened with authorization

2.5.2 Consolidating Vote Data

VVSG 2005 

2.4.2

All systems provide a means to consolidate and report vote data from all polling 

places, and optionally from other sources such as absentee ballots, provisional 

ballots, and voted ballots requiring human review (e.g., write-in votes).

Accept

F -DS200

F, R

2.5.3 Producing Reports

VVSG 2005 

2.4.3

All systems shall be able to create reports summarizing the data on multiple 

levels.

Accept

F -DS200

F, R

2.5.3.1 Common Standards

All systems shall provide capabilities to:

a. 

VVSG 2005 

2.4.3.a

Support of geographic reporting, which requires the reporting of all results for 

each contest at the precinct level and additional jurisdictional levels

Accept

F -DS200

F, R

b. 

VVSG 2005 

2.4.3

Produce a printed report of the number of ballots counted by each tabulator Accept

F -DS200

F, R

c. 

VVSG 2005 

2.4.3.c

Produce a printed report for each tabulator of the results of each contest that 

includes the votes cast for each selection, the count of undervotes, and the 

count of overvotes

Accept

F -DS200

F, R RFI 2007-06

d. 

VVSG 2005 

2.4.3.d

Produce a consolidated printed report of the results for each contest of all votes 

cast (including the count of ballots from other sources supported by the system 

as specified by the vendor) that includes the votes cast for each selection, the 

count of undervotes, and the count of overvotes

Accept

F -DS200

F, R RFI 2007-06

e. 

VVSG 2005 

2.4.3.e

Be capable of producing a consolidated printed report of the combination of 

overvotes for any contest that is selected by an authorized official (e.g.; the 

number of overvotes in a given contest combining candidate A and candidate B, 

combining candidate A and candidate C, etc.)

Accept

F -DS200

F, R

f. Produce all system audit information required in Section 4.4 in the form of 

printed reports, or in electronic memory for printing centrally

Accept F, R

VVSG 2005 

2.4.3.f.

Produce all system audit information required in Section 5.4 in the form of 

printed reports, or in electronic memory for printing centrally

Accept F -DS200

g. Prevent data from being altered or destroyed by report generation, or by the 

transmission of results over telecommunications lines

Accept F, R Telecommunications is disabled in 

Unity 3.2.0.0

2.5.3.2 Precinct Count Systems

In addition, all precinct count voting systems shall:

a. . 

VVSG 2005 

2.4.3

Prevent the printing of reports and the unauthorized extraction of data prior to 

the official close of the polling place

Accept

F -DS200

F, R
EAC Certification # ESSUNITY3200REV1.

Page 19 of 51 iBeta Report Number: (V)2010-30Jun-001(D)

VSS 2002

VVSG 2005 

Certification Test Requirements: Test 

Results

Unity 3.2.0.0 

Revision 1

Comment ESSUNITY

3200

Comment

b. 

VVSG 2005 

2.4.3

Provide a means to extract information from a transportable programmable 

memory device or data storage medium for vote consolidation

Accept

F -DS200

F, R

c. 

VVSG 2005 

2.4.3c

Consolidate the data contained in each unit into a single report for the polling 

place when more than one voting machine or precinct tabulator is used

Accept F -DS200 F, R

d. Prevent data in transportable memory from being altered or destroyed by report 

generation, or by the transmission of results over telecommunications lines

Accept F, R Telecommunications is disabled in 

Unity 3.2.0.0

2.5.4 Broadcasting Results

Some voting systems offer the capability to make unofficial results available to 

external organizations such as the news media, political party officials, and 

others. Although this capability is not required, systems that make unofficial 

results available shall:

a. Provide only aggregated results, and not data from individual ballots Accept F

b. Provide no access path from unofficial electronic reports or files to the storage 

devices for official data

Accept F

c. Clearly indicate on each report or file that the results it contains are unofficial Accept F

2.6 Maintenance, Transportation and Storage

All systems shall be designed and manufactured to facilitate preventive and 

corrective maintenance, conforming to the hardware standards described in 

Section 3. All vote casting and tally equipment designated for storage between 

elections shall:

a. Function without degradation in capabilities after transit to and from the place 

of use, as demonstrated by meeting the performance standards described in 

Section 3

b. Function without degradation in capabilities after storage between elections, 

as demonstrated by meeting the performance standards described in Section 3.

(See Section 3.2)

Test results are identified in the 

cross referenced sections

3 Hardware Standards

3.2 Performance Requirements

Performance requirements address a broad range of parameters (see below)

3.2.1 Accuracy Requirements 

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

individual ballot positions that could be selected by a voter, including the 

positions that are not selected. For a voting system, accuracy is defined as the 

ability of the system to capture, record, store, consolidate and report the specific 

selections and absence of selections, made by the voter for each ballot position 

without error. Required accuracy is defined in terms of an error rate that for 

testing purposes represents the maximum number of errors allowed while 

processing a specified volume of data.

RFI 2007-06

a.

1)

2)

For all paper-based voting systems:

Scanning ballot positions on paper ballots to detect selections for individual 

candidates and contests Conversion of selections detected on paper ballots into 

digital data

Accept F, R

b.

1)

2)

For all DRE voting systems:

Recording the voter selections of candidates and contests into voting data 

storage

Recording voter selections of candidates and contests into ballot image storage 

independently from voting data storage

Accept NA No DRE

c.

1)

For precinct-count voting systems (paper-based and DRE):

Consolidation of vote selection data from multiple precinct-based voting 

machines to generate jurisdiction-wide vote counts, including storage and 

reporting of the consolidated vote data

Accept F, R
EAC Certification # ESSUNITY3200REV1.

Page 20 of 51 iBeta Report Number: (V)2010-30Jun-001(D)

VSS 2002

VVSG 2005 

Certification Test Requirements: Test 

Results

Unity 3.2.0.0 

Revision 1

Comment ESSUNITY

3200

Comment

d.

1)

For central-count voting systems (paper-based and DRE):

Consolidation of vote selection data from multiple counting devices to generate

jurisdiction-wide vote counts, including storage and reporting of the consolidated 

vote data

Accept F, R

For testing purposes, the acceptable error rate is defined using two parameters: 

the desired error rate to be achieved, and the maximum error rate that should be 

accepted by the test process. For each processing function indicated above, 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.

Accept F, V9

3.2.2 Environmental Requirements

All voting systems shall be designed to withstand the environmental conditions 

contained in the appropriate test procedures of the Standards/Guidelines. These 

procedures will be applied to all devices for casting, scanning and counting 

ballots, except those that constitute COTS devices that have not been modified 

in any manner to support their use as part of a voting system and that have a 

documented record of performance under conditions defined in the 

Standards/Guidelines.

The Technical Data Package supplied by the vendor 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.

Accept E

3.2.2.1 Shelter Requirements

Precinct count systems are designed for storage and operation in any enclosed 

facility ordinarily used as a warehouse or polling place, with prominent 

instructions as to any special storage requirements

Accept F

3.2.2.2 Space Requirements

The arrangement of the voting system does not impede performance of their 

duties by polling place officials, the orderly flow of voters through the polling 

place, or the ability for the voter to vote in private

Accept F

3.2.2.3 Furnishings and Fixtures

Any furnishings or fixtures provided as a part of voting systems, and any 

components provided by the vendor that are not a part of the system but that are 

used to support its storage, transportation, or operation, comply with the design 

and safety requirements of Subsection 3.4.8.

Accept F, E

3.2.2.4 Electrical Supply

Components of voting systems that require an electrical supply shall meet the 

following standards: 

a. Precinct count systems operate with the electrical supply ordinarily found in 

polling places (Nominal 120 Vac/60Hz/1 phase)

Accept E

b. For components of voting systems that require an electrical supply, central count 

systems operate with the electrical supply ordinarily found in central tabulation 

facilities or computer room facilities (120vac/60hz/1, 208vac/60hz/3, or 

240vac/60hz/2);

Accept E

c. All voting machines shall also be capable of operating for a period of at least 2 

hours on backup power, such that no voting data is lost or corrupted nor normal 

operations interrupted. When backup power is exhausted the voting machine 

shall retain the contents of all memories intact. The backup power capability is 

not required to provide lighting of the voting area.

Accept E RFI 2008-02 

RFI 2008-06
EAC Certification # ESSUNITY3200REV1.

Page 21 of 51 iBeta Report Number: (V)2010-30Jun-001(D)

VSS 2002

VVSG 2005 

Certification Test Requirements: Test 

Results

Unity 3.2.0.0 

Revision 1

Comment ESSUNITY

3200

Comment

3.2.2.5 

VVSG 2005 

4.1.2.5

Electrical Power Disturbance

Vote scanning and counting equipment for paper-based systems, and all DRE 

equipment, shall be able to withstand, without disruption of normal operation or 

loss of data:

RFI 2008-02

RFI 2008-06

RFI 2008-02

RFI 2008-06

a. Surges of 30% dip @10 ms; Accept E-DS200 E

b. Surges of 60% dip @100 ms & 1 sec Accept E-DS200 E

c. Surges of >95% interrupt @5Sec; Accept E-DS200 E

d. Surges of + or - 15% line variations of nominal line voltage Accept E-DS200 E

e. Electric power increases of 7.5% and reductions of 12.5% of nominal specified 

power supply for a period of up to four hours at each power level.

Accept E-DS200 E

3.2.2.6

VVSG 2005 

4.1.2.6

Electrical Fast Transient

Vote scanning and counting equipment for paper-based systems, and all DRE 

equipment, shall be able to withstand, without disruption of normal operation or 

loss of data, electrical fast transients of:

RFI 2008-10 RFI 2008-10

a. 2 kV AC & DC External Power lines Accept E-DS200 E

b. + or - 1 kV all external wires > 3 m no control Accept E-DS200 E

c. + or - 2 kV all external wires control. Accept E-DS200 E

3.2.2.7

VVSG 2005 

4.1.2.7

Lighting Surge

Vote scanning and counting equipment for paper-based systems, and all DRE 

equipment, shall be able to withstand, without disruption of normal operation or 

loss of data, surges of:

a. + or - 2 kV AC line to line Accept E-DS200 E

b. + or - 2 kV AC line to earth Accept E-DS200 E

c. + or – 0.5 kV DC line to line >10m Accept E-DS200 E

d. + or – 0.5 kV DC line to earth >10m Accept E-DS200 E

e. + or - 1 kV I/O sig/control >30m Accept E-DS200 E

3.2.2.8

VVSG 2005 

4.1.2.8

Electrostatic Disruption

The vote scanning and counting equipment for paper-based systems, and all 

DRE equipment, is able to withstand ±15 kV air discharge and ±8 kV contact 

discharge without damage or loss of data. The equipment may reset or have 

momentary interruption so long as normal operation is resumed without human 

intervention or loss of data. Loss of data means votes that have been completed 

and confirmed to the voter.

Accept E-DS200 E

3.2.2.9 

VVSG 2005 

4.1.2.9

Electromagnetic Radiation

Vote scanning and counting equipment for paper-based systems, and all DRE 

equipment, complies with the Rules and Regulations of the Federal 

Communications Commission, Part 15, Class B requirements for both radiated 

and conducted emissions

Accept E-DS200 E

3.2.2.10

VVSG 2005 

4.1.2.10

Electromagnetic Susceptibility

Vote scanning and counting equipment for paper-based systems, and all DRE 

equipment, is able to withstand an electromagnetic field of 10 V/m modulated by 

a 1 kHz 80% AM modulation over the frequency range of 80 MHz to 1000 MHz, 

without disruption of normal operation or loss of data

Accept E-DS200 E
EAC Certification # ESSUNITY3200REV1.

Page 22 of 51 iBeta Report Number: (V)2010-30Jun-001(D)

VSS 2002

VVSG 2005 

Certification Test Requirements: Test 

Results

Unity 3.2.0.0 

Revision 1

Comment ESSUNITY

3200

Comment

3.2.2.11 

VVSG 2005 

4.1.2.11

Conducted RF Immunity

Vote scanning and counting equipment for paper-based systems, and all DRE 

equipment, shall be able to withstand, without disruption of normal operation or 

loss of data, conducted RF energy of:

a. 10V AC & DC power Accept E-DS200 E

b. 10V, 20 sig/control >3m. Accept E-DS200 E

3.2.2.12

VVSG 2005 

4.1.2.12

Magnetic Fields Immunity

Vote scanning and counting equipment for paper-based systems, and all DRE 

equipment, shall be able to withstand, without disruption of normal operation or 

loss of data, AC magnetic fields of 30 A/m at 60 Hz

Accept E-DS200 E

3.2.2.13 Environmental Control – Operating Environment

Equipment used for election management activities or vote counting (including 

both precinct and central count systems) shall be capable of operation in 

temperatures ranging from 50 to 95 degrees Fahrenheit.

Accept E-DS200 E

3.2.2.14 Environmental Control – Transit and Storage

Equipment used for vote casting or for counting votes in a precinct count system, 

shall meet these specific minimum performance standards that simulate 

exposure to physical shock and vibration associated with handling and 

transportation by surface and air common carriers, and to temperature 

conditions associated with delivery and storage in an uncontrolled warehouse 

environment:

a. High and low storage temperatures ranging from -4 to +140 degrees Fahrenheit, 

equivalent to MIL-STD-810D, Methods 501.2 and 502.2, Procedure I-Storage;

Accept E

b. Bench handling equivalent to the procedure of MIL-STD-810D, Method 516.3, 

Procedure VI;

Accept E

c. Vibration equivalent to the procedure of MIL-STD-810D, Method 514.3, Category 

1- Basic Transportation, Common Carrier

Accept E

d. Uncontrolled humidity equivalent to the procedure of MIL-STD-810D, Method 

507.2, Procedure I-Natural Hot-Humid.

Accept E

3.2.2.15 Data Network Requirements

Voting systems may use a local or remote data network. If such a network is 

used, then all components of the network shall comply with the 

telecommunications requirements described in Section 5 and the Security 

requirements described in Section 6.

Accept S, T Network functionality is disabled in 

the submitted voting system

3.2.3 Election Management System (EMS) Requirements

The Election Management System (EMS) requirements address electronic 

hardware and software used to conduct the pre-voting functions defined in 

Section 2 with regard to ballot preparation, election programming, ballot and 

program installation, readiness testing, verification at the polling place, and 

verification at the central location.

3.2.3.1 Recording Requirements

Voting systems shall accurately record all election management data entered by 

the user, including election officials or their designees.

a. Record every entry made by the user; Accept F, R

b. Add permissible voter selections correctly to the memory components of the 

device;

Accept F, R

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

selections correctly to memory

Accept F, R

d. Add various forms of data entered directly by the election official or designee, 

such as text, line art, logos, and images

Accept F
EAC Certification # ESSUNITY3200REV1.

Page 23 of 51 iBeta Report Number: (V)2010-30Jun-001(D)

VSS 2002

VVSG 2005 

Certification Test Requirements: Test 

Results

Unity 3.2.0.0 

Revision 1

Comment ESSUNITY

3200

Comment

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

addition of the selections correctly to memory

Accept F, R

f. Preserve the integrity of election management data stored in memory against 

corruption by stray electromagnetic emissions, and internally generated spurious 

electrical signals

Accept E

g. Log corrected data errors by the system. Accept F, R

3.2.3.2 Memory Stability

Memory devices used to retain election management data shall have 

demonstrated error-free data retention for a period of 22 months.

Accept TDP Attestation from ESS

3.2.4 Vote Recording Requirements 

3.2.4.1 Common Standards

All voting systems shall provide voting booths or enclosures for poll site use. 

Such booths or enclosures may be integral to the voting system or supplied as 

components of the voting system, and shall:

a. Be integral to, or make provisions for installation of the voting device; Accept F

b. Ensure by its structure stability against movement or overturning during entry, 

occupancy, and exit by the voter

Accept F

c. Provide privacy for the voter, and be designed in such a way as to prevent 

observation of the ballot by any person other than the voter

Accept F

d. Be capable of meeting the accessibility requirements of Subsection 2.2.7.1 Accept F

3.2.4.2 Paper-based Recording Standards 

The paper-based recording requirements govern:

• Ballot cards or sheets, and pages or assemblies of pages containing ballot field 

identification data

• Punching devices 

• Marking devices

• Frames or fixtures to hold the ballot while it is being punched

• Compartments or booths where voters record selections

• Secure containers for the collection of voted ballots

3.2.4.2.1 Paper Ballot Standards : Paper ballots used by paper-based voting systems 

shall meet the following standards: 

a. Paper ballots used by paper-based voting systems shall meet the following 

standards: Punches or marks that identify the unique ballot format, in 

accordance with Section 2.3.1.1.1.c., shall be outside the area in which votes 

are recorded, so as to minimize the likelihood that these punches or marks will 

be mistaken for vote responses and the likelihood that recorded votes will 

obliterate these punches or marks

Accept F, R No ballot punches

b. If printed or punched alignment marks are used to locate the vote response 

fields on the ballot, these marks shall be outside the area in which votes are 

recorded, so as to minimize the likelihood that these marks will be mistaken for 

vote responses and the likelihood that recorded votes will obliterate these marks

Accept F, R No ballot punches

c. The TDP shall specify the required paper stock, size, shape, opacity, color, 

watermarks, field layout, orientation, size and style of printing, size and location 

of punch or mark fields used for vote response fields and to identify unique ballot 

formats, placement of alignment marks, ink for printing, and folding and bleedthrough limitations for preparation of ballots that are compatible with the system.

Accept F

3.2.4.2.2 Punching Devices: Punching devices used by voting systems shall: 

a. Be suitable for the type of ballot card specified; Accept NA Not a punch card system

b. Facilitate the clear and accurate recording of each vote intended by the voter; Accept NA Not a punch card system

c. Be designed to avoid excessive damage to vote recorder components Accept NA Not a punch card system

d. Incorporate features to ensure that chad (debris) is removed, without damage to 

other parts of the ballot card.

Accept NA Not a punch card system
EAC Certification # ESSUNITY3200REV1.

Page 24 of 51 iBeta Report Number: (V)2010-30Jun-001(D)

VSS 2002

VVSG 2005 

Certification Test Requirements: Test 

Results

Unity 3.2.0.0 

Revision 1

Comment ESSUNITY

3200

Comment

3.2.4.2.3 Marking Devices : 

The Technical Data Package shall specify marking devices (such as pens or 

pencils) that, if used to make the prescribed form of mark, produce readable 

marked ballots such that the system meets the performance requirements for 

accuracy specified previously. These specifications shall identify:

a. Specific characteristics of marking devices that affect readability of marked 

ballots

Accept F

b. Performance capabilities with regard to each characteristic Accept F

c. For marking devices manufactured by multiple external sources, a listing of 

sources and model numbers that are compatible with the system.

Accept F

3.2.4.2.4 Frames or Fixtures for Punchcard Ballots : 

A frame or fixture for punchcard ballot shall:

a. Hold the ballot card securely in the proper location and orientation for voting: Accept NA Not a punch card system

b. When contests not directly printed on the ballot card or sheet, incorporate an 

assembly of ballot label pages that identify offices and issues corresponding to 

the proper ballot format for the polling place where it is used and are aligned with 

the voting fields assigned to them

Accept NA Not a punch card system

c. Incorporate a template to preclude perforation of the card except in the specified 

voting fields; a mask to allow punches only in fields designated by the format of 

the ballot; and a backing plate for the capture and removal of chad. The 

requirement may be satisfied by equipment of a different design as long it 

achieves the same result as the Standard with regard to:

Accept NA Not a punch card system

1) Positioning the card; Accept NA Not a punch card system

2) Association of ballot label information with corresponding punch fields; Accept NA Not a punch card system

3) Enable only those voting fields that correspond to the format of the ballot; and Accept NA Not a punch card system

4) Punching the fields and the positive removal of chad. Accept NA Not a punch card system

3.2.4.2.5 Frames or Fixtures for Printed Ballots: A frame or fixture for printed ballot cards 

is optional. If such a device is provided, it shall:

a. Be of any size and shape consistent with its intended use; Accept F

b. Position the card properly; Accept F

c. Hold the ballot card securely in its proper location and orientation for voting Accept F

d. Comply with the design and construction requirements in Subsection 3.4. Accept F

3.2.4.2.6 Ballot Boxes and Ballot Transfer Boxes

Ballot boxes and ballot transfer boxes which serve as secure containers for the 

storage and transportation of voted ballots, shall:

a. Be of any size, shape, and weight commensurate with their intended use Accept F

b. Incorporate locks or seals, and specifications in the system documentation Accept F, S DS200 v.1:2.2.1

c. Provide specific points where ballots are inserted, with all other points on the box 

constructed in a manner that prevents ballot insertion

Accept F

d. For precinct count systems, contain separate compartments for segregating 

unread ballots, ballots with write-in votes, or irregularities that may require 

special handling or processing. In lieu of compartments, conversion processing 

may mark such ballots with an identifying spot or stripe to facilitate manual 

segregation

Accept F

3.2.4.3 DRE Systems Recording Requirements

3.2.4.3.1 Activity Indicator

DRE systems shall include an audible or visible activity indicator providing the 

status of each voting device. This indicator shall:

a. Indicate whether the device has been activated for voting Accept F, R VAT prompts to insert a ballot

b. Indicate whether the device is in use. Accept F, R
EAC Certification # ESSUNITY3200REV1.

Page 25 of 51 iBeta Report Number: (V)2010-30Jun-001(D)

VSS 2002

VVSG 2005 

Certification Test Requirements: Test 

Results

Unity 3.2.0.0 

Revision 1

Comment ESSUNITY

3200

Comment

3.2.4.3.2 DRE System Vote Recording

To ensure vote recording accuracy and integrity while protecting the anonymity 

of the voter, all DRE systems shall: 

a. Contain all mechanical, electromechanical, and electronic components; 

software; and controls required to detect and record the activation of selections 

made by the voter in the process of voting and casting a ballot

Accept F, R

b. Incorporate redundant memories to detect and allow correction of errors caused 

by the failure of any of the individual memories

Accept NA No DRE

c.

1)

2)

Provide at least two processes that record the voter‟s selections that:

• To the extent possible, are isolated from each other

• Designate one process and associated storage location as the main vote 

detection, interpretation, processing and reporting path

Accept NA No DRE

Use a different process to store ballot images, for which the method of recording 

may include any appropriate encoding or data compression procedure 

consistent with the regeneration of an unequivocal record of the ballot as cast by 

the voter.

Accept NA No DRE

d. Provide a capability to retrieve ballot images in a form readable by humans. Accept NA No DRE

e. Ensure that all processing and storage protects the anonymity of the voter. Accept F

3.2.4.3.3 Recording Accuracy: DRE systems meet the following requirements for 

recording accurately each vote and ballot cast:'

a. Detect every selection made by the voter Accept F, R

b. Correctly add permissible selections to the memory components of the device Accept F, R Temporary memory prior to VAT 

printing

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

the selections to memory

Accept F, R

d. Achieve an error rate not to exceed the requirement indicated in Section 3.2.1 Accept F VAT paper ballot marking

e. Preserve the integrity of voting data and ballot images (for DRE machines) 

stored in memory for the official vote count and audit trail purposes against 

corruption by stray electromagnetic emissions, and internally generated spurious 

electrical signals

Accept NA No DRE

f. Maintain a log of corrected data Accept F, R

3.2.4.3.4 Recording Reliability

Recording reliability refers to the ability of the DRE system to record votes 

accurately at its maximum rated processing volume for a specified period of 

time. The DRE system shall record votes reliably in accordance with the 

requirements of Subsection 3.4.3.

Accept F VAT paper ballot marking

3.2.5 Paper-based Conversion Requirements

3.2.5.1 Ballot Handling

Ballot handling consists of a ballot card‟s acceptance, movement through the 

read station and transfer into a collection station or receptacle.

Accept F, R

3.2.5.1.1 Capacity (Central Count)

The capacity to convert the marks on individual ballots into signals is uniquely 

important to central count systems. The capacity for a central count system shall 

be documented by the vendor. This documentation shall include capacity for 

individual components that impact the overall capacity.

Accept F, R

3.2.5.1.2 Exception Handling (Central Count)

This requirement refers to the handling of ballots when they are unreadable or 

some condition is detected requiring that the cards be segregated from normally 

processed ballots for human review. In response to an unreadable ballot or a 

write-in vote all central count paper-based systems shall central count paperbased systems shall:
EAC Certification # ESSUNITY3200REV1.

Page 26 of 51 iBeta Report Number: (V)2010-30Jun-001(D)

VSS 2002

VVSG 2005 

Certification Test Requirements: Test 

Results

Unity 3.2.0.0 

Revision 1

Comment ESSUNITY

3200

Comment

a.

b.

c.

Outstack the ballot, or

Stop the ballot reader and display a message prompting the election official or 

designee to remove the ballot, or

Mark the ballot with an identifying mark to facilitate its later identification.

Accept F, R

Additionally, the system shall a capability that can be activated by an authorized 

election official to identify ballots containing overvotes, blank ballots, and ballots 

containing undervotes in a designated race. If enabled, these capabilities shall 

perform one of the above actions in response to the indicated condition

Accept F, R

3.2.5.1.3 Exception Handling (Precinct Count)

This requirement refers to the handling of ballots for precinct count system when 

they are unreadable or when some condition is detected requiring that the cards 

be segregated from normally processed ballots for human review. All paper 

based precinct count systems shall:

VVSG 2005 

4.1.5.1.d.

When ballots are unreadable or when some condition is detected requiring that 

the cards be segregated from normally processed ballots for human review. All 

paper based precinct count systems shall:

Accept F -DS200 F, R

a. 

VVSG 2005 

4.1.5.1.d.i.

In response to an unreadable or blank ballot, return the ballot and provide a 

message prompting the voter to examine the ballot

Accept F -DS200 F, R

b

VVSG 2005 

4.1.5.1.d.ii.

In response to a ballot with a write-in vote, segregate the ballot or mark the ballot 

with an identifying mark to facilitate its later identification

Accept F -DS200 F, R

c

1) 

2)

3)

4)

5)

VVSG 2005 

4.1.5.1.iii.

In response to a ballot with an overvote the system shall:

• Provide a capability to identify an overvoted ballot

• Return the ballot

• Provide an indication prompting the voter to examine the ballot

• Allow the voter to correct the ballot

• Provide a means for an authorized election official to deactivate this capability 

entirely and by contest

Accept F -DS200 F, R

d.

1)

2)

3)

4)

5)

In response to a ballot with an undervote, the system shall:

• Provide a capability to identify an undervoted ballot

• Return the ballot

• Provide an indication prompting the voter to examine the ballot

• Allow the voter to submit the ballot with the undervote

• Provide a means for an authorized election official to deactivate this capability

Accept F, R

VVSG 2005 

4.1.5.1.iv.

In response to a ballot with an undervote, the system shall:

• Provide a capability to identify an undervoted ballot

• Return the ballot

• Provide an indication prompting the voter to examine the ballot

• Allow the voter to correct the ballot

• Allow the voter to submit the ballot with the undervote

• Provide a means for an authorized election official to deactivate this

capability

Accept F -DS200

3.2.5.1.4 Multiple Feed Prevention: Multiple feed refers to the situation arising when a 

ballot reader attempts to read more than one ballot at a time. The requirements 

govern the ability of a ballot reader to prevent multiple feed or to detect and 

provide an alarm indicating multiple feed.

a. If multiple feed is detected, the card reader shall halt in a manner that permits 

the operator to remove the unread cards causing the error, and reinsert them in 

the card input hopper

Accept F

b. The frequency of multiple feeds with ballots intended for use with the system 

shall not exceed 1 in 10,000

Accept F
EAC Certification # ESSUNITY3200REV1.

Page 27 of 51 iBeta Report Number: (V)2010-30Jun-001(D)

VSS 2002

VVSG 2005 

Certification Test Requirements: Test 

Results

Unity 3.2.0.0 

Revision 1

Comment ESSUNITY

3200

Comment

3.2.5.2 Ballot Reading Accuracy

This paper-based system requirement governs the conversion of the physical 

ballot into electronic data. Reading accuracy for ballot conversion refers to the 

ability to:

♦ Recognize vote punches or marks, or the absence thereof, for each possible 

selection on the ballot 

♦ Discriminate between valid punches or marks and extraneous perforations, 

smudges, and folds 

♦ Convert the vote punches or marks, or the absence thereof, for each possible 

selection on the ballot into digital signals

To ensure accuracy, paper-based systems shall:

a. Detect punches or marks that conform to vendor specifications with an error rate 

not exceeding the requirement indicated in Section 3.2.1

Accept F, R

V1,2,4, 6-

10

b. Ignore, and not record, extraneous perforations, smudges, and folds; Accept F, R

c. Reject ballots that meet all vendor specifications at a rate not to exceed 2 

percent.

Accept F, R, 

V1,2,4,6-

10

1 incidence @ DS200 & M650 

prompted for maintenance at iBeta

3.2.6 Tabulation Processing Requirements

3.2.6.1 Paper-based Processing Requirements 

3.2.6.1.1 Processing Accuracy: 

Processing accuracy refers to the ability of the system to receive electronic 

signals produced by punches for punchcard systems and vote marks and timing 

information for marksense systems; perform logical and numerical operations 

upon these data; and reproduce the contents of memory when required, without 

error. Specific requirements are detailed below:

a. Processing accuracy shall be measured by vote selection error rate, the ratio of 

uncorrected vote selection errors to the total number of ballot positions that 

could be recorded across all ballots when the system is operated at its nominal 

or design rate of processing

Accept See 

3.2.6.1.1

d

There is no pass/fail criteria in this 

requirement. It is a definition of 

processing accuracy

b. VVSG 

2005 

4.1.6.1.ii.

The vote selection error rate shall include data that denotes ballot style or 

precinct as well as data denoting a vote in a specific contest or ballot proposition

Accept

F -DS200

F, R

c. VVSG 

2005 

4.1.6.1.iii.

The vote selection error rate shall include all errors from any source Accept

F -DS200

F, R

d. VVSG 

2005 

4.1.6.1.iv

The vote selection error rate shall not exceed the requirement indicated in 

Subsection 4.1.1

Accept F -DS200 F, R

V1,2,4, 6-

10

V1,2,6,7,9,10 -DS200

3.2.6.1.2 Paper-based system memory devices, used to retain control programs and data, 

shall have demonstrated error-free data retention for a period of 22 months 

under the environmental conditions for operation and non-operation (i.e. 

storage).

Accept TDP Attestation

3.2.6.2 DRE System Processing Requirements 

The DRE voting systems processing requirements address all mechanical 

devices, electromechanical devices, electronic devices, and software required to 

process voting data after the polls are closed.

3.2.6.2.1 Processing Speed: DRE voting systems shall meet the following requirements 

for processing speed:

a. Operate at a speed sufficient to respond to any operator and voter input without 

perceptible delay (no more than three seconds)

Accept F VAT ballot marking; printing 

exceeds 3 seconds
EAC Certification # ESSUNITY3200REV1.

Page 28 of 51 iBeta Report Number: (V)2010-30Jun-001(D)

VSS 2002

VVSG 2005 

Certification Test Requirements: Test 

Results

Unity 3.2.0.0 

Revision 1

Comment ESSUNITY

3200

Comment

b. if the consolidation of polling place data is done locally, perform this 

consolidation in a time not to exceed five minutes for each device in the polling 

place

Accept NA No DRE

3.2.6.2.2 Processing Accuracy

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

data stored in DRE voting devices or in removable memory modules installed in 

such devices. Processing includes all operations to consolidate voting data after 

the polls have been closed. DRE voting systems shall:

a. Produce reports that are completely consistent, with no discrepancy among 

reports of voting device data produced at any level

Accept F, R

b. Produce consolidated reports containing absentee, provisional or other voting 

data that are similarly error-free. Any discrepancy, regardless of source, is 

resolvable to a procedural error, to the failure of a non-memory device or to an 

external cause

Accept F, R

3.2.6.2.3 Memory Stability

DRE system memory devices used to retain control programs and data shall 

have demonstrated error-free data retention for a period of 22 months. Error-free 

retention may be achieved by the use of redundant memory elements, provided 

that the capability for conflict resolution or correction among elements is 

included.

Accept NA No DRE

3.2.7 Reporting Requirements 

3.2.7.1 Removable Storage Memory

All storage media that can be removed from the voting system and transported 

to another location for readout and report generation, these media shall use 

devices with demonstrated error-free retention for a period of 22 months under 

the environmental conditions for operation and non-operation contained in 

Section 3.2.2. Examples of removable storage media include: programmable 

read-only memory (PROM), random access memory (RAM) with battery backup, 

magnetic media or optical media.

Accept TDP 

Review

Attestation from ESS

3.2.7.2 Printers

All printers used to produce reports of the vote count shall be capable of 

producing:

a. Alphanumeric headers Accept F, R

b. Election, office and issue labels Accept F, R

c. Alphanumeric entries generated as part of the audit record. Accept F, R

3.2.8 VVSG 

2005 

4.1.8

Vote Data Management Requirements 

The vote data management requirements for all systems address capabilities 

that manage, process, and report voting data after the data has been 

consolidated at the polling place or other jurisdictional levels. These capabilities 

allow the system to:

a. Consolidate voting data from polling place data memory or transfer devices Accept F, R

b. Report polling place summaries; and Accept F, R

c. Process absentee ballots, data entered manually, and administrative ballot 

definition data.

Accept F, R

The requirements address all hardware and software required to generate output 

reports in the various formats required by the using jurisdiction.

Accept F, R

VVSG 2005 

4.1.8

• Consolidate voting data from polling place data memory or transfer devices 

• Report polling place summaries

• Process absentee ballots, data entered manually, and administrative ballot 

definition data

The requirements address all hardware and software required to generate output 

reports in the various formats required by the using jurisdiction.

Accept F -DS200
EAC Certification # ESSUNITY3200REV1.

Page 29 of 51 iBeta Report Number: (V)2010-30Jun-001(D)

VSS 2002

VVSG 2005 

Certification Test Requirements: Test 

Results

Unity 3.2.0.0 

Revision 1

Comment ESSUNITY

3200

Comment

3.2.8.1 

VVSG 2005 

4.1.8.1

Data File Management

All voting systems shall provide the capability to:

a

VVSG 2005 

4.1.8.1

Integrate voting data files with ballot definition files Accept

F -DS200

F, R

b

VVSG 2005 

4.1.8.1

Verify file compatibility. Accept

F -DS200

F, R

c.

VVSG 2005 

4.1.8.1

Edit and update files as required. Accept

F -DS200

F, R

3.2.8.2 Data Report Generation:

VVSG 2005 

4.1.8.2

All voting systems shall include report generators for producing output reports at 

the device, polling place and summary level, with provisions for administrative 

and judicial subdivision as required by the using jurisdiction

Accept

F -DS200

F, R

3.3 Physical Characteristics

3.3.1 Size

There is no numerical limitation on the size of any voting equipment, but the size 

of each voting machine should be compatible with its intended use and the 

location at which the equipment is to be used.

Accept F RFI 2007-05

3.3.2 Weight

There is no numerical limitation on the weight of any voting equipment, but the 

weight of each voting machine should be compatible with its intended use and 

the location at which the equipment is to be used.

Accept F

3.3.3 Transport and Storage of Precinct Systems: 

All precinct voting systems shall:

a. Provide a means to safely and easily handle, transport, and install voting 

equipment, such as wheels or a handle or handles

Accept F No handling issues noted by iBeta

b.

1)

2)

Be capable of using, or be provided with, a protective enclosure rendering the 

equipment capable of withstanding:

Impact, shock and vibration loads associated with surface and air transportation

Stacking loads associated with storage 

Accept F

3.4 Design, Construction, and Maintenance Characteristics

3.4.1 Materials Process and Parts

The approach to system design is unrestricted, and may incorporate any form or 

variant of technology capable of meeting the voting systems requirements and 

standards. Precinct count systems shall be designed in accordance with best 

commercial practice for microcomputers, process controllers, and their 

peripheral components. Central count voting systems and equipment used in a 

central tabulating environment shall be designed in accordance with best 

commercial and industrial practice. All voting systems shall:

a. Be designed and constructed so that the frequency of equipment malfunctions 

and maintenance requirements are reduced to the lowest level consistent with 

cost constraints. 

Accept F

b. Include, as part of the accompanying TDP, an approved parts list Accept F

c. Exclude parts or components not included in the approved parts list. Accept F

3.4.2 Durability

All voting systems shall be designed to withstand normal use without 

deterioration and without excessive maintenance cost for a period of ten years.

Accept F, TDP 

Review

RFI 2008-05

Attestation from ES&S

3.4.3 Reliability
EAC Certification # ESSUNITY3200REV1.

Page 30 of 51 iBeta Report Number: (V)2010-30Jun-001(D)

VSS 2002

VVSG 2005 

Certification Test Requirements: Test 

Results

Unity 3.2.0.0 

Revision 1

Comment ESSUNITY

3200

Comment

VVSG 2005 

4.3.3

The reliability of voting system devices shall be measured as Mean Time 

Between Failure (MTBF) for the system submitted for testing. MBTF is defined 

as the value of the ratio of operating time to the number of failures which have 

occurred in the specified time interval. A typical system operations scenario 

consists of approximately 45 hours of equipment operation, consisting of 30 

hours of equipment set-up and readiness testing and 15 hours of elections 

operations. For the purpose of demonstrating compliance with this requirement, 

a failure is defined as any event which results in either the:

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

The MTBF demonstrated during certification testing shall be at least 163 hours.

Accept E See Section 6 field issue 2

3.4.4 Maintainability: Maintainability represents the ease with which maintenance 

actions can be performed based on the design characteristics of equipment and 

software and the processes the vendor and election officials have in place for 

preventing failures and for reacting to failures. Maintainability includes the ability 

of equipment and software to self-diagnose problems and make non-technical 

election workers aware of a problem. Maintainability addresses all scheduled 

and unscheduled events, which are performed to: 

• Determine the operational status of the system or a component;

• Adjust, align, tune, or service components;

• Repair or replace a component having a specified operating life or replacement 

interval;

• Repair or replace a component that exhibits an undesirable predetermined 

physical condition or performance degradation; 

• Repair or replace a component that has failed; and 

• Verify the restoration of a component, or the system, to operational status.

Maintainability shall be determined based on the presence of specific physical 

attributes that aid system maintenance activities, and the ease with which 

system maintenance tasks can be performed by the ITA. Although a more 

quantitative basis for assessing maintainability, such as the mean to repair the 

system is desirable, the qualification of a system is conducted before it is 

approved for sale and thus before a broader base of maintenance experience 

can be obtained.

F

3.4.4.1 Physical Attributes

The following physical attributes will be examined to assess reliability:

a. Presence of labels and the identification of test points Accept F

b. Provision of built-in test and diagnostic circuitry or physical indicators of 

condition

Accept F

c. Presence of labels and alarms related to failures Accept F

d. Presence of features that allow non-technicians to perform routine maintenance 

tasks (such as update of the system database)

Accept F

3.4.4.2 Additional Attributes: 

The following additional attributes will be examined to assess maintainability:

a. Ease of detecting that equipment has failed by a non-technician Accept F

b. Ease of diagnosing problems by a trained technician Accept F

c. Low false alarm rates (i.e., indications of problems that do not exist) Accept F

d. Ease of access to components for replacement Accept F

e. Ease with which adjustment and alignment can be performed Accept F

f. Ease with which database updates can be performed by a non-technician Accept F

g. Adjust, align, tune or service components Accept F
EAC Certification # ESSUNITY3200REV1.

Page 31 of 51 iBeta Report Number: (V)2010-30Jun-001(D)

VSS 2002

VVSG 2005 

Certification Test Requirements: Test 

Results

Unity 3.2.0.0 

Revision 1

Comment ESSUNITY

3200

Comment

3.4.5 Availability: The availability of a voting system is defined as the probability that 

the equipment (and supporting software) needed to perform designated voting 

functions will respond to operational commands and accomplish the function. 

The voting system shall meet the availability standard for each of the following 

voting functions:

a. For all paper-based voting systems: Accept F, E

1 Recording voter selections (such as by ballot marking or punch) Accept F, E

2 Scanning the punches or marks on paper ballots and converting them into digital 

data

Accept F, E

b. For all DRE systems, recording and storing voter ballot selections Accept F, E

c. For precinct count systems (paper-based and DRE), consolidation of vote 

selection data from multiple precinct based systems to generate jurisdiction-wide 

vote counts, including storage and reporting of the consolidated vote data

Accept F, E

d. For central-count systems (paper-based and DRE), consolidation of vote 

selection data from multiple counting devices to generate jurisdiction-wide vote 

counts, including storage and reporting of the consolidated vote data 

Accept F, E

System availability is measured as the ratio of the time during which the system 

is operational (up time) to the total time period of operation (up time plus down 

time). Inherent availability (Ai) is the fraction of time a system is functional, 

based upon Mean Time Between Failure (MTBF) and Mean Time To Repair 

(MTTR), that is: Ai = (MTBF)/(MTBF + MTTR) MTTR is the average time 

required to perform a corrective maintenance task during periods of system 

operation. Corrective maintenance task time is active repair time, plus the time 

attributable to other factors that could lead to logistic or administrative delays, 

such as travel notification of qualified maintenance personnel and travel time for 

such personnel to arrive at the appropriate site. Corrective maintenance may 

consist of substitution of the complete device or one of its components, as in the 

case of precinct count and some central count systems, or it may consist of onsite repair. 

The voting system shall achieve at least 99 percent availability during normal 

operation for the functions indicated above. This standard encompasses for 

each function the combination of all devices and components that support the 

function, including their MTTR and MTBF attributes.

Accept F, E

Vendors shall specify the typical system configuration that is to be used to 

assess availability, and any assumptions made with regard to any parameters 

that impact the MTTR. These factors shall include at a minimum:

Accept F

a. Recommended number and locations of spare devices or components to be kept 

on hand for repair purposes during periods of system operation

Accept F

b. Recommended number and locations of qualified maintenance personnel who 

need to be available to support repair calls during system operation. 

Organizational affiliation (i.e., jurisdiction, vendor) of qualified maintenance 

personnel

Accept F

c. Organizational affiliation (i.e., jurisdiction, vendor) of qualified maintenance 

personnel

Accept F

3.4.6 Product Marking: All voting systems shall:

a. Identify all devices with a permanently affixed nameplate or label containing the 

name of the manufacturer or vendor, the name of the device, its part or model 

number, its revision letter, its serial number, and if applicable, its power 

requirements

Accept F

b. Display on each device a separate data plate containing a schedule for and list 

of operations required to service or to perform preventive maintenance

Accept F
EAC Certification # ESSUNITY3200REV1.

Page 32 of 51 iBeta Report Number: (V)2010-30Jun-001(D)

VSS 2002

VVSG 2005 

Certification Test Requirements: Test 

Results

Unity 3.2.0.0 

Revision 1

Comment ESSUNITY

3200

Comment

c. Display advisory caution and warning instructions to ensure safe operation of the 

equipment and to avoid exposure to hazardous electrical voltages and moving 

parts at all locations where operation or exposure may occur

Accept F

3.4.7 Workmanship: To help ensure proper workmanship, all manufacturers of voting 

systems shall:

a. Adopt and adhere to practices and procedures to ensure their products are free 

from damage or defect that could make them unsatisfactory for their intended 

purpose

Accept F

b. Ensure components provided by external suppliers are free from damage or 

defect that could make them unsatisfactory for their intended purpose.

Accept F

3.4.8 Safety: All voting systems shall meet the following requirements for safety: RFI 2008-09

a. All voting system and their components shall be designed to eliminate hazards 

to personnel or the equipment itself.

Accept E

b. Defects in design and construction that can result in personal injury or 

equipment damage must be detected and corrected before voting systems and 

components are placed into service.

Accept E

c. Equipment design for personnel safety is equal to or better than the appropriate 

requirements of the Occupational Safety and Health Act, Code of Federal 

Regulations, as identified in Title 29, part 1910

Accept E

3.4.9 Human Engineering- Controls and Displays

All voting systems and components shall be designed and constructed so as to 

simplify and facilitate the functions required , and to eliminate the likelihood of 

erroneous stimuli and responses on the part of the voter or operator. All voting 

systems shall meet the following requirements for controls and displays:

a. In all systems, controls used by the voter or equipment operator shall be 

conveniently located, shall use designs consistent with their functions, and shall 

be clearly labeled. Instruction plates are provided, if necessary to avoid 

ambiguity or incorrect actuation.

Accept F

b. Information or data displays are large enough to be readable by voters and 

operators with no disabilities and by voters with disabilities consistent with the 

requirements defined is Section 2.2.7 of the Standards.

Accept F

c. Status displays meet the same requirements as data displays, and they shall 

also follow conventional industrial practice with respect to color:

Accept F

1 Green, blue, or white displays shall be used for indications of normal status; Accept F

2 Amber indicators shall be used to indicate warnings or marginal status; and Accept F

3 Red indicators shall be used to indicate error conditions or equipment states that 

may result in damage or hazard to personnel; and unless the equipment is 

designed to halt under conditions of incipient damage or hazard, an audible 

alarm is also be provided.

Accept F

d. Color coding shall be selected so as to assure correct perception by voters and 

operators with color blindness; and shall not bet used as the only means of 

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

distinguishing a visual element (see Appendix C for suggested references).

Accept F

e. The system‟s display does not use flashing or blinking text objects, or other 

elements having a flash or blink frequency, greater than 2 Hz and lower than 55 

Hz

Accept F

4 Software Standards

4.1.1 Software Sources RFI 2008-03
EAC Certification # ESSUNITY3200REV1.

Page 33 of 51 iBeta Report Number: (V)2010-30Jun-001(D)

VSS 2002

VVSG 2005 

Certification Test Requirements: Test 

Results

Unity 3.2.0.0 

Revision 1

Comment ESSUNITY

3200

Comment

4.2 Source Design and Coding Standards

The software used by voting systems is selected by the vendor and not 

prescribed by the Standards. This sections provides standards for voting system 

software with regard to: 

 Selection of programming languages

 Software integrity

 Software modularity and programming;

 Control constructs;

 Naming conventions; 

 Coding conventions; and 

 Comment conventions.

SysTest 

Report & 

Appendix 

B

Source code review conducted by 

SysTest was approved for reuse. 

The detail of requirements 4.2.1 

through 4.2.7 is found in the test 

results provided by SysTest and 

Unity 3.2.0.0 test report

4.3 Data and Document Retention : All systems shall:

a. Maintain the integrity of voting and audit data during an election, and for at least 

22 months thereafter, a time sufficient to resolve most contested elections and 

support other activities related to the reconstruction and investigation of a 

contested election

Accept TDP 

Review

Attestation from ESS

b. Protect against the failure of any data input or storage device at a location 

controlled by the jurisdiction or its contractors, and against any attempt at 

improper data entry or retrieval

Accept S, V4

4.4 Audit Record Data

Audit trails are essential to ensure the integrity of a voting system. Operational 

requirements for audit trails are described in Subsection 2.2.5.2 of the 

Standards. Audit record data are generated by these procedures. The audit 

record data in the following subsections are essential to the complete recording 

of election operations and reporting of the vote tally. This list of audit records 

may not reflect the design constructs of some systems. Therefore, vendors shall 

supplement it with information relevant to the operation of their specific systems.

Accept F, S Document review

4.4.1 Pre-election Audit Records

During election definition and ballot preparation, the system shall audit the 

preparation of the baseline ballot formats and modifications to them, a 

description of these modifications, and corresponding dates. The log shall 

include:

Accept F,R

a. The allowable number of selections for an office or issue; Accept F, R

b. The combinations of voting patterns permitted or required by the jurisdiction Accept F, R

c. The inclusion or exclusion of offices or issues as the result of multiple districting 

within the polling place

Accept F, R

d. Any other characteristics that may be peculiar to the jurisdiction, the election, or 

the polling place's location

Accept F, R

e. Manual data maintained by election personnel Accept F, R

f. Samples of all final ballot formats Accept F, R

g. Ballot preparation edits listings. Accept F, R

4.4.2 System Readiness Audit Records

The following minimum requirements apply to system readiness audit records:

a. Prior to the start of ballot counting, a system process shall verify hardware and 

software status and generate a readiness audit record. This record shall include 

the identification of the software release, the identification of the election to be 

processed, and the results of software and hardware diagnostic tests

Accept F, R

b. In the case of systems used at the polling place, the record shall include polling 

place identification

Accept F, R

c. The ballot interpretation logic shall test and record the correct installation of 

ballot formats on voting devices

Accept F, R
EAC Certification # ESSUNITY3200REV1.

Page 34 of 51 iBeta Report Number: (V)2010-30Jun-001(D)

VSS 2002

VVSG 2005 

Certification Test Requirements: Test 

Results

Unity 3.2.0.0 

Revision 1

Comment ESSUNITY

3200

Comment

d. The software shall check and record the status of all data paths and memory 

locations to be used in vote recording to protect against contamination of voting 

data 

Accept F, R

e. Upon the conclusion of the tests, the software shall provide evidence in the audit 

record that the test data have been expunged

Accept F, R

f. If required and provided, the ballot reader and arithmetic-logic unit shall be 

evaluated for accuracy, and the system shall record the results. It shall allow the 

processing or simulated processing of sufficient test ballots to provide a 

statistical estimate of processing accuracy

Accept F

g.

1)

2)

3)

4)

For systems that use a public network, provide a report of test ballots that 

includes:

Number of ballots sent

When each ballot was sent

Machine from which each ballot was sent

specific votes or selections contained in the ballot

Accept S, T Telecommunications is disabled in 

Unity 3.2.0.0

4.4.3 In-Process Audit Records :In-process audit records document system 

operations during diagnostic routines and the casting and tallying of ballots. At a 

minimum, the in-process audit records shall contain:

RFI 2008-07

a. Machine generated error and exception messages to demonstrate successful 

recovery. Examples include, but are not necessarily limited to:

Accept V1-10 Code review v.1:4.2.3e

1) The source and disposition of system interrupts resulting in entry into exception 

handling routines

Accept V1-10. F, 

R

2) All messages generated by exception handlers Accept V1-10, F, 

R

3) The identification code and number of occurrences for each hardware and 

software error or failure

Accept F, R

4) Notification of system login or access errors, file access errors, and physical 

violations of security as they occur, and a summary record of these events after 

processing

Accept S

5) Other exception events such as power failures, failure of critical hardware 

components, data transmission errors or other types of operating anomalies

Accept S

b. Critical system status messages other than informational messages displayed by 

the system during the course of normal operations. These items include, but are 

not limited to:

Accept F, R, S v.2: 3.3.1

1) Diagnostic and status messages upon startup Accept F, R

2) The “zero totals” check conducted before opening the polling place or counting a 

precinct centrally

Accept F, R, S v.2: 3.3.1

3) For paper-based systems, the initiation or termination of card reader and 

communications equipment operation

Accept F, R

4) For DRE machines at controlled voting locations, the event (and time, if 

available) of activating and casting each ballot (i.e., each voter's transaction as 

an event). This data can be compared with the public counter for reconciliation 

purposes

Accept F VAT ballot printing

c. Non-critical status messages that are generated by the machine's data quality 

monitor or by software and hardware condition monitors

Accept F

d. System generated log of all normal process activity and system events that 

require operator intervention, so that each operator access can be monitored 

and access sequence can be constructed

Accept F, R, S v.2: 3.3.1
EAC Certification # ESSUNITY3200REV1.

Page 35 of 51 iBeta Report Number: (V)2010-30Jun-001(D)

VSS 2002

VVSG 2005 

Certification Test Requirements: Test 

Results

Unity 3.2.0.0 

Revision 1

Comment ESSUNITY

3200

Comment

4.4.4 Vote Tally Data: In addition to the audit requirements described above, other 

election-related data is essential for reporting results to interested parties, the 

press, and the voting public, and is vital to verifying an accurate count. Voting 

systems shall meet these reporting requirements by providing software capable 

of obtaining data concerning various aspects of vote counting and producing 

printed reports. At a minimum, vote tally data shall include:

a.

VVSG 2005 

5.4.4.a

Number of ballots cast, using each ballot configuration, by tabulator, by precinct, 

and by political subdivision

Accept F-DS200 Discrepancy #1 

Closed

F, R

b. Candidate and measure vote totals for each contest, by tabulator Accept F, R

c. The number of ballots read within each precinct and for additional jurisdictional 

levels, by configuration, including separate totals for each party in primary 

elections

Accept F, R

d. Separate accumulation of overvotes and undervotes for each contest, by 

tabulator, precinct and for additional jurisdictional levels (no overvotes would be 

indicated for DRE voting devices)

Accept F, R

e. For paper-based systems only, the total number of ballots both able to be 

processed and unable to be processed; and if there are multiple card ballots, the 

total number of cards read

Accept F, R

For systems that produce an electronic file containing vote tally data, the 

contents of the file shall include the same minimum data cited above for printed 

vote tally reports.

Accept F, R

4.5 Voter Secrecy on DRE Systems: 

All DRE systems shall ensure vote secrecy by:

a. Immediately after the voter chooses to cast his or her ballot, record the voter‟s 

selections in the memory to be used for vote counting and audit data (including 

ballot images), and erase the selections from the display, memory, and all other 

storage, including all forms of temporary storage

Accept S Post printing on the VAT

b. Immediately after the voter chooses to cancel his or her ballot, erase the 

selections from the display and all other storage, including buffers and other 

temporary storage

Accept S Pre-printing on the VAT

5 Telecommunications 

5.2 Design, Construction, and Maintenance Requirement

Design, construction, and maintenance requirements for telecommunications 

represent the operational capability of both system hardware and software. 

These capabilities shall be considered basic to all data transmissions.

Accept S, T Telecommunications is disabled in 

Unity 3.2.0.0

5.2.1 Accuracy

The telecommunications components of all voting systems shall meet the 

accuracy requirements of 3.4.1.

Accept S, T Telecommunications is disabled in 

Unity 3.2.0.0

5.2.2 Durability

The telecommunications components of all voting systems shall meet the 

Durability requirements of 3.4.2.

Accept S, T Telecommunications is disabled in 

Unity 3.2.0.0

5.2.3 Reliability

The telecommunications components of all voting systems shall meet the 

Reliability requirements of 3.4.3.

Accept S, T Telecommunications is disabled in 

Unity 3.2.0.0

5.2.4 Maintainability

The telecommunications components of all voting systems shall meet the 

maintainability requirements of 3.4.4.

Accept S, T Telecommunications is disabled in 

Unity 3.2.0.0

5.2.5 Availability

The telecommunications components of all voting systems shall meet the 

availability requirements of 3.4.5.

Accept S, T Telecommunications is disabled in 

Unity 3.2.0.0

5.2.6 Integrity: For WANs using public telecommunications, boundary definition and 

implementation shall meet the requirements below.
EAC Certification # ESSUNITY3200REV1.

Page 36 of 51 iBeta Report Number: (V)2010-30Jun-001(D)

VSS 2002

VVSG 2005 

Certification Test Requirements: Test 

Results

Unity 3.2.0.0 

Revision 1

Comment ESSUNITY

3200

Comment

a. Outside service providers and subscribers of such providers shall not be given 

direct access or control of any resource inside the boundary.

Accept S, T Telecommunications is disabled in 

Unity 3.2.0.0

b. Voting system administrators shall not require any type of control of resources 

outside this boundary. Typically, an end point of a telecommunications circuit will 

be a subscriber termination on a Digital Service Unit/Customer Service Unit 

although the specific technology configuration may vary. Regardless of the 

technology used, the boundary point must ensure that everything on the voting 

system side is locally configured and controlled by the election jurisdiction while 

everything on the public network side is controlled by an outside service 

provider.

Accept S, T Telecommunications is disabled in 

Unity 3.2.0.0

c. The system shall be designed and configured such that it is not vulnerable to a 

single point of failure in the connection to the public network which could cause 

total loss of voting capabilities at any polling place.

Accept S, T Telecommunications is disabled in 

Unity 3.2.0.0

5.2.7 Confirmation: Confirmation occurs when the system notifies the user of the 

successful or unsuccessful completion of the data transmission, where 

successful completion is defined as accurate receipt of the transmitted data. To 

provide confirmation, the telecommunications components of a voting system 

shall 

d. Notify the user of the successful or unsuccessful completion of the data 

transmission; and 

Accept S, T No network trans-mission; see 

2.2.2.1 d & e

e. In the event of unsuccessful transmission, notify the user of the action to be

taken.

Accept S, T No network trans-mission; see 

2.2.2.1 d & e

6 Security Standards

6.2 Access Controls 

6.2.1 Access Control Policy 

6.2.1.1 General Access Control Policy RFI 2008-03

Although the jurisdiction in which the voting system is operated is responsible for 

determining the access policies for each election, the vendor shall provide a 

description of recommended policies for:

Accept S- Doc 

Review

a. Software access controls; Accept S- Doc 

Review

b. Hardware access controls; Accept S- Doc 

Review

c. Communications; Accept S- Doc 

Review

Networking is disabled

d. Effective password management; Accept S- Doc 

Review

e. Protection abilities of a particular operating system; Accept S- Doc 

Review

f. General characteristics of supervisory access privileges; Accept S- Doc 

Review

g. Segregation of duties; and Accept S- Doc 

Review

h. Any additional relevant characteristics. Accept S- Doc 

Review

6.2.1.2 Individual Access Privileges: Voting system vendors shall:

a. Identify each person to whom access is granted, and the specific functions and 

data to which each person holds authorized access

Accept S- Doc 

Review

b. Specify whether an individual‟s authorization is limited to a specific time, time 

interval or phase of the voting or counting operations

Accept S- Doc 

Review

c. Permit the voter to cast a ballot expeditiously, but preclude voter access to all 

aspects of the vote counting processes

Accept S- Doc 

Review
EAC Certification # ESSUNITY3200REV1.

Page 37 of 51 iBeta Report Number: (V)2010-30Jun-001(D)

VSS 2002

VVSG 2005 

Certification Test Requirements: Test 

Results

Unity 3.2.0.0 

Revision 1

Comment ESSUNITY

3200

Comment

6.2.2 Access Control Measures: Vendors shall provide a detailed description of all 

system access control measures designed to permit authorized access to the 

system and prevent unauthorized access, such as:

a. Use of data and user authorization Accept S- Doc & 

Review

b. Program unit ownership and other regional boundaries Accept S- Doc 

Review

c. One-end or two-end port protection devices Accept S- Doc 

Review

d. Security kernels Accept S- Doc 

Review

e. Computer-generated password keys Accept S- Doc & 

Code 

Review

f. Special protocols Accept S- Doc 

Review

g. Message encryption and Accept S- Doc & 

Code 

Review

h. Controlled access security. Accept S- Doc 

Review

Vendors also shall define and provide a detailed description of the methods used

to prevent unauthorized access to the access control capabilities of the system 

itself.

Accept S- Doc 

Review

6.3 Physical Security Measures

A voting system‟s sensitivity to disruption or corruption of data depends, in part, 

on the physical location of equipment and data media, and on the establishment 

of secure telecommunications among various locations. Most often, the 

disruption of voting and vote counting results from a physical violation of one or 

more areas of the system thought to be protected. Therefore, security 

procedures shall address physical threats and the corresponding means to 

defeat them.

Accept S- Doc 

Review

6.3.1 Polling Place Security: For polling place operations, vendors shall develop 

and provide detailed documentation of measures anticipate and counteract 

vandalism, civil disobedience, and similar occurrences. The measures shall.

a. Allow the immediate detection of tampering with vote casting devices and 

precinct ballot counters. 

Accept S- Doc 

Review

b. Control physical access to a telecommunications link if such a link is used Accept S- Doc 

Review

6.3.2 Central Count Location Security

a.

b.

c.

d.

Vendors shall develop and document in detailed measures to be taken in a 

central counting environment. These measures shall include physical and 

procedural controls related to the

Handling of ballot boxes

Preparing of ballots for counting

Counting operations and

Reporting data

Accept S- Doc 

Review

6.4 Software Security 

6.4.1 Software and Firmware Installation

The system shall meet the following requirements for installation of software, 

including hardware with embedded firmware.
EAC Certification # ESSUNITY3200REV1.

Page 38 of 51 iBeta Report Number: (V)2010-30Jun-001(D)

VSS 2002

VVSG 2005 

Certification Test Requirements: Test 

Results

Unity 3.2.0.0 

Revision 1

Comment ESSUNITY

3200

Comment

a. If software is resident in the system as firmware, the vendor shall require and 

state in the system documentation that every device is to be retested to validate 

each ROM prior to the start of elections operations.

Accept S- Doc 

Review

b. To prevent alteration of executable code, no software shall be permanently 

installed or resident in the voting system unless the system documentation 

states that the jurisdiction must provide a secure physical and procedural 

environment for the storage, handling, preparation, and transportation of the 

system hardware.

Accept S

c. The voting system bootstrap, monitor, and device-controller software may be 

resident permanently as firmware, provided that this firmware has been shown to 

be inaccessible to activation or control by any means other than by the 

authorized initiation and execution of the vote counting program, and its 

associated exception handlers.

Accept S

d. The election-specific programming may be installed and resident as firmware, 

provided that such firmware is installed on a component (such as a computer 

chip) other than the component on which the operating system resides.

Accept S

e. After initiation of election day testing, no source code or compilers or assemblers 

shall be resident or accessible. 

Accept S

6.4.2 Protection Against Malicious Software: Voting systems shall deploy 

protection against the many forms of threats to which they may be exposed such 

as file and macro viruses, worms, Trojan horses, and logic bombs

Vendors shall develop and document the procedures to be followed to ensure 

that such protection is maintained in a current status.

Accept S

6.5 Telecommunications and Data Transmission 

6.5.1 Access Controls

Voting systems that use telecommunications to communicate between system 

components and locations are subject to the same security requirements 

governing access to any other system hardware, software, and data function.

Accept S, T Telecommunications is disabled in 

Unity 3.2.0.0

6.5.2 Data Integrity

Voting systems that use electrical or optical transmission of data shall ensure the 

receipt of valid vote records is verified at the receiving station. This should 

include standard transmission error detection and correction methods such as 

checksums or message digest hashes. Verification of correct transmission shall 

occur at the voting system application level and ensure that the correct data is 

recorded on all relevant components consolidated within the polling place prior 

to the voter completing casting of his or her ballot.

Accept S, T No transmission within the polls 

prior to voter casting their ballot

6.5.3 Data Interception Prevention

Voting systems that use telecommunications to communicate between system

components and locations before the polling place is officially closed shall:

a. Implement an encryption standard currently documented and validated for use 

by an agency of the U.S. Federal Government and

Accept S, T Telecommunications is disabled in 

Unity 3.2.0.0

b. Provide a means to detect the presence of an intrusive process, such as an 

Intrusion Detection System.

Accept S, T Telecommunications is disabled in 

Unity 3.2.0.0

6.5.4 Protection Against External Threats

Voting systems that use public telecommunications networks shall implement 

protections against external threats to which commercial products used in the 

system may be susceptible.

Accept S, T Telecommunications is disabled in 

Unity 3.2.0.0

6.5.4.1 Identification of COTS Products
EAC Certification # ESSUNITY3200REV1.

Page 39 of 51 iBeta Report Number: (V)2010-30Jun-001(D)

VSS 2002

VVSG 2005 

Certification Test Requirements: Test 

Results

Unity 3.2.0.0 

Revision 1

Comment ESSUNITY

3200

Comment

a.

b.

c.

d.

Voting systems that use public telecommunications networks shall provide 

system documentation that clearly identifies all COTS hardware and software 

products and communications services used in the development and/or 

operation of the voting system, including 

operating systems, 

communications routers,

modem drivers and 

dial-up networking software.

Accept S, T Telecommunications is disabled in 

Unity 3.2.0.0

Such documentation shall identify the name, vendor, and version used for each

such component.

Accept S, T Telecommunications is disabled in 

Unity 3.2.0.0

6.5.4.2 Use of Protective Software

Voting systems that use public telecommunications networks shall use protective 

software at the receiving-end of all communications paths to:

Accept S, T Telecommunications is disabled in 

Unity 3.2.0.0

a. Detect the presence of a threat in a transmission Accept S, T Telecommunications is disabled in 

Unity 3.2.0.0

b. Remove the threat from infected files/data Accept S, T Telecommunications is disabled in 

Unity 3.2.0.0

c. Prevent against storage of the threat anywhere on the receiving device Accept S, T Telecommunications is disabled in 

Unity 3.2.0.0

d. Provide the capability to confirm that no threats are stored in system memory 

and in connected storage media

Accept S, T Telecommunications is disabled in 

Unity 3.2.0.0

e. Provide data to the system audit log indicating the detection of a threat and the 

processing performed

Accept S, T Telecommunications is disabled in 

Unity 3.2.0.0

Vendors shall use multiple forms of protective software as needed to provide 

capabilities for the full range of products used by the voting system.

Accept S, T Telecommunications is disabled in 

Unity 3.2.0.0

6.5.4.3 Monitoring and Responding to External Threats

Voting system that use public telecommunications networks may become 

vulnerable, by virtue of their system components, to external threats to the 

accuracy and integrity of vote recording, vote counting, and vote consolidation 

and reporting processes. Therefore, vendors of such systems shall document 

how they plan to monitor and respond to known threats to which their voting 

systems are vulnerable. This documentation shall provide a detailed description, 

including scheduling information, of the procedures the vendor will use to:

Accept S, T Telecommunications is disabled in 

Unity 3.2.0.0

a. Monitor threats, such as through the review of assessments, advisories, and 

alerts for COTS components issued by the Computer Emergency Response 

Team (CERT), for which a current listing can be found at http://www.cert.org, the 

National Infrastructure Protection Center (NIPC), and the Federal Computer 

Incident Response Capability (FedCIRC), for which additional information can be 

found at www.uscert.gov

Accept S, T Telecommunications is disabled in 

Unity 3.2.0.0

b. Evaluate the threats and, if any, proposed responses Accept S, T Telecommunications is disabled in 

Unity 3.2.0.0

c. Develop responsive updates to the system and/or corrective procedures Accept S, T Telecommunications is disabled in 

Unity 3.2.0.0

d. Submit the proposed response to the test labs and appropriate states for 

approval, identifying the exact changes and whether or not they are temporary or 

permanent

Accept S, T Telecommunications is disabled in 

Unity 3.2.0.0

e. After implementation of the proposed response is approved by the state, assist 

clients, either directly or through detailed written procedures, how to update their 

systems and/or to implement the corrective procedures within the timeframe 

established by the state

Accept S, T Telecommunications is disabled in 

Unity 3.2.0.0

f. Address threats emerging too late to correct the system by: Accept S, T Telecommunications is disabled in 

Unity 3.2.0.0
EAC Certification # ESSUNITY3200REV1.

Page 40 of 51 iBeta Report Number: (V)2010-30Jun-001(D)

VSS 2002

VVSG 2005 

Certification Test Requirements: Test 

Results

Unity 3.2.0.0 

Revision 1

Comment ESSUNITY

3200

Comment

1 Providing prompt, emergency notification to the accredited test labs and the 

affected states and user jurisdictions

Accept S, T Telecommunications is disabled in 

Unity 3.2.0.0

2 Assisting client jurisdictions directly or advising them through detailed written 

procedures to disable the public telecommunications mode of the system

Accept S, T Telecommunications is disabled in 

Unity 3.2.0.0

3 Modifying the system after the election to address the threat, submitting the 

modified system to an accredited test lab and the EAC or state certification 

authority for approval, and assisting client jurisdictions directly or advising them 

through detailed written procedures, to update their systems and/or to implement 

the corrective procedures after approval

Accept S, T Telecommunications is disabled in 

Unity 3.2.0.0

6.5.5 Shared Operating Environment: Ballot recording and vote counting can be 

performed in either a dedicated or non-dedicated environment. If ballot recording 

and vote counting operations are performed in an environment that is shared 

with other data processing functions, both hardware and software features shall 

be present to protect the integrity of vote counting and of vote data. Systems that 

use a shared operating environment shall:

a. Use security procedures and logging records to control access to system 

functions

Accept S Network disabled in Unity 3.2.0.0

b. Partition or compartmentalize voting system functions from other concurrent 

functions at least logically, and preferably physically as well

Accept S Network disabled in Unity 3.2.0.0

c. Control system access by means of passwords, and restrict account access to 

necessary functions only

Accept S Network disabled in Unity 3.2.0.0

d. Have capabilities in place to control the flow of information, precluding data 

leakage through shared system resources

Accept S Network disabled in Unity 3.2.0.0

6.5.6 Access to Incomplete Election Returns and Interactive Queries : If the 

voting system provides access to incomplete election returns and interactive 

inquiries before the completion of the official count, the system shall:

a. Be designed to provide external access to incomplete election returns (for 

equipment that operates in a central counting environment), only if that access 

for these purposes is authorized by the statutes and regulations of the using 

agency. This requirement applies as well to polling place equipment that 

contains a removable memory module or that may be removed in its entirety to a 

central place for the consolidation of polling place returns

Accept S No access to incomplete returns

b. Design voting system software and its security environment such that data 

accessible to interactive queries resides in an external file or database created 

and maintained by the elections software under the restrictions applying to any 

other output report:

Accept S No external access

1 The output file or database has no provision for write-access back to the system. Accept S No write back provision

2 Persons whose only authorized access is to the file or database are denied 

write-access, both to the file or database, and to the system.

Accept S No external access

6.6 Security for Transmission of Official Data Over Public Communications 

Networks

6.6.1 General Security Requirements for Systems Transmitting Data Over Public 

Networks

All systems that transmit data over public telecommunications networks shall:

a. Preserve the secrecy of voter ballot selections and prevent anyone from violating 

ballot privacy

Accept S, T Telecommunications is disabled in 

Unity 3.2.0.0

b. Employ digital signatures for all communications between the vote server and 

other devices that communicate with the server over the network

Accept S, T Telecommunications is disabled in 

Unity 3.2.0.0

c. Require that at least two authorized election officials activate any critical 

operation regarding the processing of ballots transmitted over a public 

communications network, i.e. the passwords or cryptographic keys of at least 

two employees are required to perform processing of vote

Accept S, T Telecommunications is disabled in 

Unity 3.2.0.0
EAC Certification # ESSUNITY3200REV1.

Page 41 of 51 iBeta Report Number: (V)2010-30Jun-001(D)

VSS 2002

VVSG 2005 

Certification Test Requirements: Test 

Results

Unity 3.2.0.0 

Revision 1

Comment ESSUNITY

3200

Comment

6.6.2 Voting Process Security for Casting Individual Ballots over a Public 

Telecommunications Network

Systems designed for transmission of telecommunications over public networks 

shall meet security standards that address the security risks attendant with the 

casting of ballots from polling places controlled by election officials using voting 

devices configured and installed by election officials and/or their vendor or 

contractor, and using in-person authentication of individual voters.

Accept S, T Telecommunications is disabled in 

Unity 3.2.0.0

6.6.2.1 Documentation of Mandatory Security Activities: Vendors of voting systems that 

cast individual ballots over a public telecommunications network shall provide 

detailed descriptions of:

a. All activities mandatory to ensuring effective voting system security to be 

performed in setting up the system for operation, including testing of security 

before an election

Accept S, T Telecommunications is disabled in 

Unity 3.2.0.0

b. All activities that should be prohibited during voting equipment setup and during 

the time-frame for voting operations, including both the hours when polls are 

open and when polls are closed

Accept S, T Telecommunications is disabled in 

Unity 3.2.0.0

6.6.2.2 Capabilities to Operate During Interruption of Telecommunications Capabilities

These systems shall provide the following capabilities to provide resistance to 

interruptions of telecommunications service that prevent voting devices at the 

polling place from communicating with external components via 

telecommunications:

a. Detect the occurrence of a telecommunications interruption at the polling place 

and switch to an alternative mode of operation that is not dependent on the 

connection between polling place voting devices and external system 

components

Accept S, T Telecommunications is disabled in 

Unity 3.2.0.0

b. Provide an alternate mode of operation that includes the functionality of a 

conventional electronic voting system without losing any single vote

Accept S, T Telecommunications is disabled in 

Unity 3.2.0.0

c. Create and preserve an audit trail of every vote cast during the period of 

interrupted communication and system operation in conventional electronic 

voting system mode

Accept S, T Telecommunications is disabled in 

Unity 3.2.0.0

d. Upon reestablishment of communications, transmit and process votes 

accumulated while operating in conventional electronic voting system mode with 

all security safeguards in effect

Accept S, T Telecommunications is disabled in 

Unity 3.2.0.0

e. Ensure that all safeguards related to voter identification and authentication are 

not affected by the procedures employed by the system to counteract potential 

interruptions of telecommunications capabilities

Accept S, T Telecommunications is disabled in 

Unity 3.2.0.0

7 Quality Assurance Requirements 

7.2 General Requirements : The voting system vendor is responsible for designing 

and implementing a quality assurance program to ensure that the design,

workmanship, and performance requirements of this standard are achieved in all 

delivered systems and components. At a minimum, this program shall:

a. Include procedures for specifying, procuring, inspecting, accepting, and 

controlling parts and raw materials of the requisite quality.

Accept F

b. Require the documentation of the hardware and software development process. Accept F

c. Identify and enforce all requirements for: Accept F

c. 1) In-process inspection and testing that the manufacturer deems necessary to 

ensure proper fabrication and assembly of hardware.

Accept F

c. 2) Installation and operation of software (including firmware). Accept F

d. Include the plans and procedures for post-production environmental screening 

and acceptance testing.

Accept F

e. Include a procedure for maintaining all data and records required to document 

and verify the quality inspections and tests.

Accept F

7.3 Components from Third Parties 
EAC Certification # ESSUNITY3200REV1.

Page 42 of 51 iBeta Report Number: (V)2010-30Jun-001(D)

VSS 2002

VVSG 2005 

Certification Test Requirements: Test 

Results

Unity 3.2.0.0 

Revision 1

Comment ESSUNITY

3200

Comment

A vendor 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 vendors follow 

documented quality assurance procedures that are at least as stringent as those 

used internally by the voting system vendor.

Accept F

7.4 Responsibility for Tests:: Manufacturer or vendor shall be responsible for:

a. Performing all quality assurance tests. Accept F

b. Acquiring and documenting test data. Accept F

c. 2002: Providing test reports for review by the ITA, and to the purchaser upon 

request.

Accept F

7.5 Parts and Materials Special Tests: In order to ensure that voting system parts 

and materials function properly, vendors 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.

Accept F

b. Design special tests, if needed, to evaluate the part or material under conditions 

accurately simulating the actual operating environment.

Accept F

c. Maintain the resulting test data as part of the quality assurance program 

documentation.

Accept F

7.6 Parts and Materials Special Tests

The vendor performs conformance inspections to ensure the overall quality of 

the voting system and components delivered to the ITA for testing and to the 

jurisdiction for implementation. To meet the conformance inspection 

requirements the vendor or manufacturer shall::

a. Inspect and test each voting system or component to verify that it meets all 

inspection and test requirements for the system.

Accept F

b. Deliver a record of tests or a certificate of satisfactory completion with each 

system or component.

Accept F

7.7 Documentation: Vendors are required to produce documentation to support the 

development and formal testing of voting systems. To meet documentation 

requirements, vendors shall provide complete product documentation with each 

voting systems or components, as described Volume II, Section 2 for the TDP. 

This documentation shall:

a.

b.

c

Be sufficient to serve the needs of the ITA, voters, election officials, and 

maintenance technicians;

Be prepared and published in accordance with standard industrial practice for 

information technology and electronic and mechanical equipment; and

Consist, at a minimum, of the following:

1) System overview;

2) System functionality description;

3) System hardware specification;

4) Software design and specifications;

5) System security specification;

6) System test and verification specification;

7) System operations procedures;

Accept F Letter of reuse; Appendix C for 

LogMonitor

8 Configuration Management

8.1 Scope

8.1.1 Configuration Management Requirements: Configuration management 

addresses a broad set of record keeping, audit, and reporting activities that 

contribute to full knowledge and control of a system and its components. These 

activities include:

▪ Identifying discrete system components. Accept F Letter of Reuse PCA Doc Review
EAC Certification # ESSUNITY3200REV1.

Page 43 of 51 iBeta Report Number: (V)2010-30Jun-001(D)

VSS 2002

VVSG 2005 

Certification Test Requirements: Test 

Results

Unity 3.2.0.0 

Revision 1

Comment ESSUNITY

3200

Comment

▪ Creating records of a formal baseline and later versions of components. Accept F Letter of Reuse PCA Doc Review

Inconsistencies in CM observed in 

testing were noted #143 & 160

▪ Controlling changes made to the system and its components. Accept F Letter of Reuse PCA Doc Review

Inconsistencies in CM observed in 

testing were noted #143 & 160

▪ Releasing new versions of the system to ITAs. Accept F Letter of Reuse PCA Doc Review

Inconsistencies in CM observed in 

testing were noted #143 & 160

▪ Releasing new versions of the system to customers. Accept F Letter of Reuse PCA Doc Review

▪ Auditing the system, including its documentation, against configuration

management records.

Accept F Letter of Reuse PCA Doc Review

▪ Controlling interfaces to other systems. Accept F Letter of Reuse PCA Doc Review

▪ Identifying tools used to build and maintain the system. Accept F Letter of Reuse PCA Doc Review

8.1.2 Organization of Configuration Management Standards

8.1.3 Application of Configuration Management Standards: 

Requirements for configuration management apply regardless of the specific 

technologies employed to all voting systems subject to the Standards. These 

system components include:

a. Software components. Accept F Letter of Reuse PCA Doc Review

b. Hardware components. Accept F Letter of Reuse PCA Doc Review

c. Communications components. Accept F Letter of Reuse PCA Doc Review

d. Documentation. Accept F Letter of Reuse PCA Doc Review

e. Identification and naming and conventions (including changes to these 

conventions) for software programs and data files.

Accept F Letter of Reuse PCA Doc Review

f. Development and testing artifacts such as test data and scripts. Accept F Letter of Reuse PCA Doc Review

g. File archiving and data repositories. Accept F Letter of Reuse PCA Doc Review

8.2 Configuration Management Policy: The vendor shall describe its policies for 

configuration management in the TDP. This description shall address the 

following elements

a. Scope and nature configuration management program activities. Accept F Letter of Reuse PCA Doc Review

b. Breadth of the application of the vendor‟s policies and practices to the voting 

system. (i.e. extent to which policies and practices apply to the total system and 

extent to which polices and practices of suppliers apply to particular 

components, subsystems, or other defined system elements.

Accept F Letter of Reuse PCA Doc Review

8.3 Configuration Identification

8.3.1 Structuring and Naming Configuration Items

The vendor shall describe the procedures and conventions used to:

a. Classify configuration items into categories and subcategories. Accept F Letter of Reuse PCA Doc Review

b. Uniquely number or otherwise identify configuration items. Accept F Letter of Reuse PCA Doc Review

c. Name configuration items. Accept F Letter of Reuse PCA Doc Review

8.3.2 Version Conventions

When a system component is used to identify higher-level system elements, a 

vendor shall describe the conventions used to:

a. Identify the specific versions of individual configuration items and sets of items 

that are used by the vendor to identify higher level system elements such as 

subsystems.

Accept F Letter of Reuse PCA Doc Review

b. Uniquely number or otherwise identify versions. Accept F Letter of Reuse PCA Doc Review

c. Name versions. Accept F Letter of Reuse PCA Doc Review
EAC Certification # ESSUNITY3200REV1.

Page 44 of 51 iBeta Report Number: (V)2010-30Jun-001(D)

VSS 2002

VVSG 2005 

Certification Test Requirements: Test 

Results

Unity 3.2.0.0 

Revision 1

Comment ESSUNITY

3200

Comment

8.4 Baseline, Promotion and Demotion Procedures: The vendor 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. Accept F Letter of Reuse PCA Doc Review

b. Promote subsequent instances of a component to baseline status as 

development progresses through to completion of the initial completed version 

released to the ITAs for qualification testing.

Accept F Letter of Reuse PCA Doc Review

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 vendor).

Accept F Letter of Reuse PCA Doc Review

8.5 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 vendor shall establish such 

procedures and related conventions, providing a complete description of those 

procedures used to:

a. Develop and maintain internally developed items. Accept F Letter of Reuse PCA Doc Review

b. Acquire and maintain third-party items. Accept F Letter of Reuse PCA Doc Review

c. Resolve internally identified defects for items regardless of their origin. Accept F Letter of Reuse PCA Doc Review

d. Resolve externally identified and reported defects (i.e., by customers and ITAs). Accept F Letter of Reuse PCA Doc Review

8.6 Release Process Procedures: The release process is the means by which the 

vendor installs, transfers, or migrates the system to the ITAs and, eventually, to 

its customers. The vendor shall establish such procedures and related 

conventions, providing a complete description of those used to:

a. Perform a first release of the system to: Accept F Letter of Reuse PCA Doc Review

b. Perform a subsequent maintenance or upgrade release of the system, or a 

particular components, to:

Accept F Letter of Reuse PCA Doc Review

c. Perform the initial delivery and installation of the system to a customer, including 

confirmation that the installed version of the system matches exactly the certified 

system version.

Accept F Letter of Reuse PCA Doc Review

d. Perform a subsequent maintenance or upgrade release of the system, or a 

particular component, to a customer, including confirmation that the installed 

version of the system matches exactly the qualified system version.

Accept F Letter of Reuse PCA Doc Review

8.7 Configuration Audits

8.7.1 Physical Configuration Audit: The PCA is conducted by the ITA to compare 

the voting system components submitted for qualification to the vendor‟s 

technical documentation. For the PCA, a vendor shall provide:

a. Identification of all items that are to be a part of the software release. Accept F Letter of Reuse PCA Doc Review

b. Specification of compiler (or choice of compilers) to be used to generate 

executable programs.

Accept F Letter of Reuse PCA Doc Review

c. Identification of all hardware that interfaces with the software. Accept F Letter of Reuse PCA Doc Review

d. Configuration baseline data for all hardware that is unique to the system. Accept F Letter of Reuse PCA Doc Review

e. Copies of all software documentation intended for distribution to users, including 

program listings, specifications, operations manual, voter manual, and 

maintenance manual.

Accept F Letter of Reuse PCA Doc Review

f. User acceptance test procedures and acceptance criteria. Accept F Letter of Reuse PCA Doc Review

g. Identification of any changes between the physical configuration of the system 

submitted for the PCA and that submitted for the FCA, with a certification that 

any differences do not degrade the functional characteristics.

Accept F Letter of Reuse PCA Doc Review

h. Complete descriptions of its procedures and related conventions used to support 

this audit by:

Accept F Letter of Reuse PCA Doc Review

h. 1) Establishing a configuration baseline of the software and hardware to be tested. Accept F Letter of Reuse PCA Doc Review
EAC Certification # ESSUNITY3200REV1.

Page 45 of 51 iBeta Report Number: (V)2010-30Jun-001(D)

VSS 2002

VVSG 2005 

Certification Test Requirements: Test 

Results

Unity 3.2.0.0 

Revision 1

Comment ESSUNITY

3200

Comment

h. 2) Confirming whether the system documentation matches the corresponding 

system components.

Accept F Letter of Reuse PCA Doc Review

8.7.2 Functional Configuration Audits

The FCA is conducted by the ITA to verify that the system performs all the 

functions described in the system documentation. The vendor shall:

a. Completely describe its procedures and related conventions used to support this 

audit for all system components.

Accept F Letter of Reuse PCA Doc Review

b. Provide the following information to support this audit: Accept F Letter of Reuse PCA Doc Review

b. 1) Copies of all procedures used for module or unit testing, integration testing, and 

system testing.

Accept F Letter of Reuse PCA Doc Review

b. 2) Copies of all test cases generated for each module and integration test, and 

sample ballot formats or other test cases used for system tests.

Accept F Letter of Reuse PCA Doc Review

b. 3) Records of all tests performed by the procedures listed above, including error 

corrections and retests.

Accept F Letter of Reuse PCA Doc Review

In addition to such audits performed by ITAs during the system qualification 

process, elements of this audit may also be performed by state election 

organizations during the system certification process, and individual jurisdictions 

during system acceptance testing.

Accept F Letter of Reuse PCA Doc Review

8.8 Configuration Management Resources: Often, configuration management 

activities are performed with the aid of automated tools. Assuring that such tools 

are available throughout the system life cycle, including if the vendor is acquired 

by or merged with another organization, is critical to effective configuration 

management. Vendors may choose the specific tools they use to perform the 

record keeping, audit, and reporting activities of the configuration management 

standards. The resources documentation standard provided below focus on 

assuring that procedures are in place to record information about the tools to 

help ensure that they, and the data they contain, can be transferred effectively 

and promptly to a third party should the need arise. Within this context, a vendor 

is required to develop and provide a complete description of the procedures and 

related practices for maintaining information about:

a. Specific tools used, current version, and operating environment specifications. Accept F Letter of Reuse PCA Doc Review
EAC Certification # ESSUNITY3200REV1.

Page 46 of 51 iBeta Report Number: (V)2010-30Jun-001(D)

Appendix B: PCA Source Code Review

The Unity 3.2.0.0 Rev. 1 source code is made up of two parts that required diverse handling based upon the rules 

of the EAC Certification Program.

The first part is source code that remained unchanged from the ESSUNITY3200 baseline and did not require any 

additional review or a new Trusted Build.

The second part is DS200 source code that was changed from the ESSUNITY3200 baseline. iBeta conducted a 

100% review of source code changes that were submitted by ES&S in their Unity 3.2.1.0 and the Unity 3.2.0.0 

Revision 1 test effort. The review was performed in Unity 3.2.1.0 and all results were reused for Unity 3.2.0.0 

Revision 1. These were reviewed to the VVSG 2005 and are identified in Section 5.1 PCA Source Code Review.

iBeta Unity 3.2.0.0 Revision 1 Source Code Review Results

The first table below contains the number of modules with discrepancies indentified in the DS200 firmware changes 

from the Unity 3.2.0.0 escrow. Some modules had more than one discrepancy. The table identifies the final code 

version reviewed and used in the Trusted Builds performed by iBeta. (See Appendix G: Trusted Build & Validation 

Tools Unity 3.2.0.0 Revision 1)

The second table lists the source code review requirements and the discrepancies. All discrepancies were 

comment related. These were reported to ES&S. ES&S fixed them and re-submitted them to iBeta. A subsequent 

review found all comments were appropriately updated. The discrepancies were closed

Product Source 

Code

Language Changes to Unity 

3.2.0.0 -

Unity 3.2.0.0 Rev. 1 

Release Version

Number of 

Modules with 

Discrepancies

DS200 DS200 C/C++ 1.3.10.0 1.4.3.0 11

The PCA Source Code Review was conducted against these VVSG 2005 requirements. Comment related requirements 

are highlight in green. A total of 11 modules contained discrepancies. One module contained discrepancies written against

two requirements.

VVSG VSS Requirement Definition C & C++

Vol. 1 Section 4.2.2-Integrity

v.1: 5.2.2 v.1: 4.2.2 Self-modifying code Self-modifying, dynamically loaded, or modification of 

compiled or interpreted code is prohibited

0

Vol. 1 Section 4.2.3- Modularity

v.1: 5.2.3.a v.1: 4.2.3.a Specific function Module performs a specific function 0

v.1: 5.2.3.b v.1: 4.2.3.b Module has unique name Uniquely and mnemonically named using names that 

differ by more than a single character

0

v.1: 5.2.3.b

5.2.7 (a, a.1-

a.6)

v.1: 4.2.3.b

4.2.7 (a, a.1-

a.6)

Module has header Header describes purpose, other units needed, inputs, 

outputs, files read or written, globals, revision records 

(for modules greater than 10 lines) Header comments 

shall provide the following information:

1) The purpose of the unit and how it works;

2) Other units called and the calling sequence

3) A description of input parameters and outputs

4) File references by name and method of access

5) Global variables used

6) Date of creation and a revision record

7

v.1: 5.2.3.c v.1: 4.2.3.c Required resources All required resources, such as data accessed by the 

module, should either be contained within the module 

or explicitly identified

0

v.1: 5.2.3.e v.1: 4.2.3.e Single Entry Point Module has a single entry point 0

v.1: 5.2.3.e v.1: 4.2.3.e Single Exit Point Module has a single exit point 0

v.1: 5.2.3.f v.1: 4.2.3.f Control structures Support the modular concept and apply to any 

language feature where program control passes from 

one activity to the next.

0

Vol. 1 Section 4.2.4-Control Constructs

v.1: 5.2.4.a v.1: 4.2.4.a Acceptable Constructs Acceptable constructs are Sequence, If-Then-Else, DoWhile, Do-Until, Case, and the General loop (including 

the special case for loop);

0

v.1: 5.2.4.b v.1: 4.2.4.b Vendor Defined Constructs with 

Justification

If the programming language used does not provide 

these control constructs, the vendor shall provide them 

(that is, comparable control structure logic). The 

constructs shall be used consistently throughout the 

code. No other constructs shall be used to control 

program logic and execution

0

v.1: 5.2.4.c v.1: 4.2.4.c Execution through Control 

Constructs

While some programming languages do not create 

programs as linear processes, stepping from an initial 

condition, through changes, to a conclusion, the 

0
EAC Certification # ESSUNITY3200REV1.

Page 47 of 51 iBeta Report Number: (V)2010-30Jun-001(D)

VVSG VSS Requirement Definition C & C++

program components nonetheless contain procedures 

(such as “methods” in object-oriented languages). Even 

in these programming languages, the procedures must 

execute through these control constructs.

v.1: 5.2.4.d v.1: 4.2.4.d Program re-direction Logic that evaluates received or stored data shall not 

re-direct program control

0

Vol. 1 Section 4.2.5-Naming Conventions

v.1: 5.2.5.a v1: 4.2.5.a Name Readability Names shall be selected so that their parts of speech 

represent their use.

4

v.1: 5.2.5.b

5.2.5.c

v.1: 4.2.5.b

4.2.5.c

Class, function and variable names Consistent names are used. Names shall be unique 

within an application and differ by more than a single 

character.

0

v.1: 5.2.5.d v.1: 4.2.5.d Keyword Keywords shall not be used as names of objects, 

functions, procedures, or variables

0

Vol. 1 Section 4.2.6-Coding Conventions

v.2: 5.4.2.a v.2: 5.4.2.a Uniform calling sequences Uses uniform calling sequences. 0

v.2: 5.4.2.a v.2: 5.4.2.a Parameters type and range validation All parameters shall either be validated for type and 

range on entry into each unit or the unit comments shall 

explicitly identify the types and ranges

0

v.2: 5.4.2.b v.2: 5.4.2.b Explicit return values The return is explicitly defined for functions and 

explicitly assigned

0

v.2: 5.4.2.c v.2: 5.4.2.c Macros Does not use macros that contain returns or pass 

control beyond the next statement 

0

v.2: 5.4.2.d v.2: 5.4.2.d Unbound arrays Provides controls to prevent writing beyond the array, 

string, or buffer boundaries

0

v.2: 5.4.2.e v.2: 5.4.2.e Pointers Provides controls that prevent pointers from being used 

to overwrite executable instructions or to access areas 

where vote counts or audit records are stored

0

v.2: 5.4.2.f v.2: 5.4.2.f Case statements Default choice explicitly defined 0

v.2: 5.4.2.g v.2: 5.4.2.g Vote counter overflowing Provides controls to prevent any vote counter from 

overflowing

0

v.2: 5.4.2.h v.2: 5.4.2.h Indentation Code is indented consistently and clearly 0

v.2: 5.4.2.j v.2: 5.4.2.j Code generator Generated code should be marked as such with 

comments defining the logic invoked

0

v.2: 5.4.2.k v.2: 5.4.2.k Line length No line of code exceeding 80 columns in width without 

justification

0

v.2: 5.4.2.l v.2: 5.4.2.l Executable statement One executable statement for each line of source code 0

v.2: 5.4.2.m v.2: 5.4.2.m Embedded executable statement The single embedded statement may be considered a 

part of the conditional expression. Any additional 

executable statements should be split out to the other 

lines.

0

v.2: 5.4.2.n v.2: 5.4.2.n Mixed-mode operations Avoids mixed-mode operations. Comment if mixedmode usage is necessary.0

v.2: 5.4.2.o v.2: 5.4.2.o Exit() message Upon exit() at any point, presents a message to the 

user indicating the reason for the exit ().

0

v.2: 5.4.2.p v.2: 5.4.2.p Format of messages Separate and consistent formats to distinguish between 

normal status and error or exception messages

0

v.2: 5.4.2.q v.2: 5.4.2.q References variables References variables by fewer than five levels of 

indirection (i.e. a.b.c.d or a[b].c->d) 

0

v.2: 5.4.2.r v.2: 5.4.2.r Levels of indented scope Functions with fewer than six levels of indented scope 0

v.2: 5.4.2.s v.2: 5.4.2.s Variable initialization Initializes every variable upon declaration where 

permitted.

0

Deleted in 

VVSG

v.2: 5.4.2.t Explicit Comparisons Explicit comparisons in all if() and while() conditions. 0

v.2: 5.4.2.u v.2: 5.4.2.u Constant Definitions All constants other than “0” and “1” defined or 

enumerated

0

v.2: 5.4.2.v v.2: 5.4.2.v Ternary Operator Only contains the minimum implementation of the “a = 

b ? c : d” syntax. Expansions such as “j=a?(b?c:d):e;” 

are prohibited. 

0

v.2: 5.4.2.w v.2: 5.4.2.w Assert() statement All assert() statements coded such that they are absent 

from a production compilation

0

Vol. 1 Section 4.2.7 -Comments

v.1: 5.2.7.b v.1: 4.2.7.b Variables All variables shall have comments at the point of 

declaration

0

v.1: 5.2.7.c v.1: 4.2.7.c In-Line Comments In-line comments shall be provided to facilitate 

interpretation of functional operations, tests, and 

branching

1

v.1: 5.2.7.d v.1: 4.2.7.d Assembly code Assembly code shall contain descriptive and 

informative comments 

0

v.1: 5.2.7.e v.1: 4.2.7.e Comments in uniform format All comments formatted in a uniform manner 0
EAC Certification # ESSUNITY3200REV1.

Page 48 of 51 iBeta Report Number: (V)2010-30Jun-001(D)

VVSG VSS Requirement Definition C & C++

Vol. 1 Section 6.4.2 -Protection Against Malicious Software

v1: 7.4.2 v.1: 6.4.2 Malicious Software Susceptibility to file or macro viruses, worms, Trojan 

horses, logic bombs, or hardcoded passwords

0

Appendix G: Trusted Build & Validation Tools Unity 3.2.0.0 

Revision 1

The ES&S DS200 v.1.4.3.0 changes submitted in Unity 3.2.0.0 Revision 1 have also been submitted to the Unity 

3.2.1.0 certification test effort. A single build was conducted for both test efforts and stored in the Unity 3.2.1.0 

project. At completion of the test effort duplicate copies will be maintained in the Unity 3.2.0.0 Revision 1 archive. 

Listed below are the Source Code Applications reviewed in the Unity 3.2.1.0 test effort by iBeta however; the items 

listed are will be the Final Trusted Builds and Witness of the ES&S Unity 3.2.0.0 Revision 1 voting system firmware. 

(NIST Handbook 150-22 4.2.3, 4.13.2, 4.13.4, 5.10.4 VSS vol. 1: 9.6.2.4)

IBeta uses a COTS hash program (Maresware) to obtain File Size, MD5 and SHA1 hashes during all witnessed and 

trusted builds. Both algorithms have been validated using the test data from the NIST NSRL website 

(http://www.nsrl.nist.gov/testdata/). This program is widely used in forensic analysis of systems and also used by 

some states to verify their voting software. The MD5 and SHA1 hashes are taken to be consistent with the currently 

distributed NSRL data files which contain the hash resulting from each of those two algorithms.

Witness of the Trusted Build DS200 v.1.4.3.0

Document Prior to the Build Witness:

Vendor Name ES&S

Vendor Consultant(s) (5.6) Dave Herrera

Witness Name (5.6) Sjakileti

Witness Title Trusted Builder

Vendor Build Document(s) used and version(s) Ds200Firmware_BECI_v1.4.3.0_2010.01.23.pdf

Equipment Used Dell Precision 670

iBeta COTS used to clean the build environment disk (name 

and version) (5.6.1.1)

Restored from the 3.2.0.0 DS200 TOS PostBuild 

(DS200TOS_PostBuild_05302009.GHO) as a Build 

environment for DS200 Firmware

iBeta COTS used to generate HASH file signatures (name 

and version)

Mares Hash Ver. 07.08.10.07.12

Construct the build environment (5.6.1.2)

Verify (by signature) that the build environment is isolated 

and controlled by iBeta

Sjakileti

Witness attests to verifying that the source code being built is 

the source code provided by iBeta

Sjakileti

Vendor CM Tool and version Concurrent Versions System (CVS) 1.11.22 

Build tool(s) and version(s) Linux From Scratch 6.25

Build Environment Operating System Linux operating system 6.25

3

rd Party Libraries and Version Please see in DS200TOS trustedBuild Doc 3rd

party Libraries and versions

3

rd Party Source Code (COTS) and Version N/A

3

rd Party DLLs, Drivers, etc. and Version(s) Please see in DS200TOS 3rd party DLLs, Drivers, 

etc and Versions

Additional file(s) loaded and version(s) BuildScripts(BuildFirmware1.sh, BuildFirmware2.sh, 

BuildFirmware3.sh, VersionNumbers.txt), PMB.hex 

(1.2.01, built 5/28/2009) coming from 

3.2.0.0_DS200AncillaryDevices ( trusted Build

fw.iic coming from 

3.2.1.0_DS200AncillaryDevices trusted Build )

Record the disk image software version being used Norton GHOST V:11.0

Record the filename of the build environment file signature 

(5.6.1.3) – 

Restored from previous build
EAC Certification # ESSUNITY3200REV1.

Page 49 of 51 iBeta Report Number: (V)2010-30Jun-001(D)

Record the filename of the build environment disk image – DS200TOS_PostBuild_05302009.GHO

Verify (by signature) the build environment file signature 

(5.6.1.3)

Sjakileti

Loading Source Code (5.6.2)

Record the file signature of the source code (5.6.2.1) see table of source code, above

Verify (by signature) that each file signature of the source 

code loaded matches as documented above (5.6.2.1)

Sjakileti

Method of Build Witness Trusted Build

Record the combined source code and pre-build 

environment file signature (5.6.2.2)

DS200FW_PreBuild_02122010.hashl

Record the combined source code and pre-build 

environment disk image (5.6.2.3)

DS200FW_PreBuild_02122010.GHO

Record the Final Build Version – Unique Identifier DS200 1.4.3.0

Certification Application Number (if applicable) ESS1002

Document during the Build Witness:

Date / Time Build Initiated 2/12/2010 8.00am

Compiler and Version GCC-4.0.3 (GNU Compiler Collection). This 

compiler is part of the LFS (Linux From Scratch) 

6.2-5 Live CD

Application Name DS200

Application Version Order Ds200 1.4.3.0

Obtain Names and Signatures of all persons present during 

build (record below)

Sjakileti & Dave Herrera

Issue(s) and Resolution(s) No Issues

Document at Completion of the Build Witness:

Record the disk image of the final build (5.7.3) DS200FW_PostBuild_02122010.GHO

Record file signature of the final build (5.6.3.1) DS200FW_PostBuild_02122010.hashl

Record the type of unalterable storage media being used for 

installation disk(s) (i.e., CD) – (5.6.3.2)

CF card on DS200 machine and NAS2 (located in the 

Unity 3.2.1.0 project folder)

Record each piece of media that is part of the installation 

disk (each must have a unique identifier) (5.6.3.2, 5.7.5)

Ds200 1.4.3.0 Trusted Build upgrade 02122010

Record the file signature of the installation disk(s). (5.6.3.3, 

5.7.5) (include in below archive)

DS200FW_TrustedBuild_Installs_02122010.hash.txt

Record the type of unalterable storage media being used for 

pre-build and post-build archive disk (i.e., CD) –

NAS2 (located in the Unity 3.2.1.0 project folder)

Record each piece of media that is part of the pre-build 

archive disk (each must have a unique identifier) (5.6.2.4, 

5.7.2, 5.7.3)

Same as above

Explanation of any significant differences observed No Issues

Witness of the Trusted Build DS200 Ancillary Devices

Document Prior to the Build 

Witness:

Vendor Name ES&S

Vendor Consultant(s) (5.6) Dave Herrera

Witness Name (5.6) Kevin Wilson, Alastair Mayer

Witness Title Trusted Builder

Vendor Build Document(s) used and 

version(s)

 

WinXPwithSP3-DellOptiplexGX520_INST_2009.03.31.pdf 

IAREmbeddedWorkbench3.40_INST_2009.04.20.pdf 
EAC Certification # ESSUNITY3200REV1.

Page 50 of 51 iBeta Report Number: (V)2010-30Jun-001(D)

KeiluVision3DevelopmentTools4.2007_INST_2009.04.20.pdf 

CypressEZ-USBReferenceDesignKit2.31_INST_2009.04.20.pdf 

DS200AncillaryDevices_BECI_3.2.1.0_2009.12.15.pdf 

Equipment Used DellOptipllexGX520

iBeta COTS used to clean the build 

environment disk (name and version) 

(5.6.1.1)

Active KillDisk for DOS V:4.1 Build 2380

iBeta COTS used to generate HASH 

file signatures (name and version)

Mares Hash Ver. 07.08.10.07.12

Construct the build environment (5.6.1.2)

Verify (by signature) that the build 

environment is isolated and controlled 

by iBeta

Kevin Wilson

Witness attests to verifying that the 

source code being built is the source 

code provided by iBeta

Kevin Wilson

Vendor CM Tool and version Concurrent Versions System (CVS) 1.11.22 Copyright (C) 2006 Free 

Software Foundation, Inc.

Build Environment Operating System Windows XP Professional Version 2002 Service Pack 3 

Build tool(s) and version(s) Keil μVision3 Development Tools

 Cypress CY4611 EZ-USB FX2 Reference Design Kit 

 IAR Embedded Workbench EW430

3

rd Party Libraries and Version As below

3

rd Party Source Code (COTS) and 

Version

As below

3

rd Party DLLs, Drivers, etc. and 

Version(s)

As below

Additional file(s) loaded and version(s) Build scripts(unzip.exe, TB-3_CreateExecutables.bat, TB2_LoadSourceCode.bat, TB-0_CheckInputMedium.bat, 

ESSSourceFileList.txt, ESSScriptsFileList.txt, BuildScripts.ini, TB-2_LSC2_ScannerBoard.bat, TB-2_LSC-1_PowerManagementBoard.bat, TB2_LSC-0.2_MakeDirectories.bat, TB-2_LSC0.1_SetEnvironmentVariables.bat, TB-3_CE0.01_SetEnvironmentVariables.bat, TB-3_CE1.01_PowerManagementMsp430.bat, TB-3_CE-1.02_ScannerC8051.bat, 

TB-0_CIM-0_SetEnvironmentVariables.bat)

Record the disk image software version 

being used

Notron GHOST V:11.0

Record the filename of the build 

environment file signature (5.6.1.3) – 

DS200Ancillary_PostCots_05282009.hash.txt

Record the filename of the build 

environment disk image –

DS200Ancillary_PostCots_05282009.GHO

Verify (by signature) the build 

environment file signature (5.6.1.3)

Kevin Wilson, Alastair Mayer

Loading Source Code (5.6.2)

Record the file signature of the source 

code (5.6.2.1)

see table of source code, above

Verify (by signature) that each file 

signature of the source code loaded 

matches as documented above 

(5.6.2.1)

Kevin Wilson, Alastair Mayer

Method of Build Witness Trusted Build

Record the combined source code and 

pre-build environment file signature 

(5.6.2.2)

DS200Ancillary_PreBuild_12292009.hash.txt

Record the combined source code and 

pre-build environment disk image 

(5.6.2.3)

DS200Ancillary_PreBuild_12292009.GHO

Record the Final Build Version – Scanner C8051 2.20.0.0
EAC Certification # ESSUNITY3200REV1.

Page 51 of 51 iBeta Report Number: (V)2010-30Jun-001(D)

Unique Identifier

Certification Application Number (if 

applicable)

ESS1002

Document during the Build Witness:

Date / Time Build Initiated 12/29/2009 8:45 am MST (but PC says 7:45)

Compiler and Version See Build tools and versions

Application Name DS200ancillary Devices (Scanner)

Application Version Order 2.20.0.0

Obtain Names and Signatures of all 

persons present during build (record 

below)

Kevin Wilson, Alastair Mayer

Dave Herrera

Issue(s) and Resolution(s) No Issues

Document at Completion of the Build 

Witness:

Record the disk image of the final build 

(5.7.3)

DS200Ancillary_PostBuild_12292009.hash.txt

Record file signature of the final build 

(5.6.3.1)

DS200Ancillary_PostBuild_12292009.GHO

Record the type of unalterable storage 

media being used for installation disk(s) 

(i.e., CD) – (5.6.3.2)

NAS2 (located in the Unity 3.2.1.0 project folder)

Record each piece of media that is part 

of the installation disk (each must have 

a unique identifier) (5.6.3.2, 5.7.5)

DS200Ancillary install files are (fw.iic) input to DS200 firmware build on 

NAS2

ESS Unity 3.2.1.0\Unity3.2.1.0_TrustedBuild\Unity 

3.2.1.0_DS200_TrustedBuild_2009Dec29\ds200_stage_Ancillary_12292009

Record the file signature of the 

installation disk(s). (5.6.3.3, 5.7.5) 

(include in below archive)

DS200Ancillary_Archive_12292009.hash.txt

Record the type of unalterable storage 

media being used for pre-build and 

post-build archive disk (i.e., CD) –

NAS2 (located in the Unity 3.2.1.0 project folder)

Record each piece of media that is part 

of the pre-build archive disk (each 

must have a unique identifier) (5.6.2.4, 

5.7.2, 5.7.3)

Same as above

Explanation of any significant 

differences observed

No differences

System Identification Tools

As identified in Section 5.8 and 5.9 of the US Election Assistance Commission Test and Certification Program Manual

delivery of the System Identification Tools to the EAC is the responsibility of ES&S. Review of the System Identification 

Tools is the responsibility of the EAC. No changes to the ESSUNITY3200 system identification tool were submitted to iBeta.