Compact Table of Contents

Executive Summary

The Overseas Voting Initiative (OVI) is a collaborative effort formed via a cooperative agreement between The Council of State Governments (CSG) and the U.S. Department of Defense Federal Voting Assistance Program (FVAP). Its goal is to improve the voting process for those covered under the Uniformed and Overseas Citizens Absentee Voting Act (UOCAVA). To achieve this goal, the OVI works with state and local election officials to develop targeted and actionable improvements to the UOCAVA voting process.

Since 2013, the OVI has studied how election offices use non-voting election systems— election management systems ballot tracking software and voter registration databases among others — and online voter portals to facilitate and improve the UOCAVA voting process. This document is a culmination of that research. It provides recommendations and considerations for election officials when drafting a Request for Proposals (RFP) relating to the functionality, interoperability and security of systems that facilitate UOCAVA voting.

Recommendations related to the functionality of election systems:

  1. Identify the functionalities of existing systems that facilitate UOCAVA voting and include them as requirements in an RFP.
  2. Conduct process modeling to identify and determine the functionalities of existing systems that facilitate UOCAVA voting and include them as requirements in an RFP.
  3. Delineate specific ballot tracking capabilities as a system requirement in an RFP for any new system.
  4. Identify and specify the core functionalities of the desired system rather than its election-specific applications to allow technology vendors outside the election space to meet RFP requirements.
  5. Employ participatory procurement practices by convening a stakeholder advisory committee to help identify improvements to existing systems that can facilitate UOCAVA voting and include identified functionalities as system requirements in an RFP.

Recommendations related to the interoperability of election systems:

  1. Require any new system to implement the ESB data standard to collect UOCAVA data and require vendors to outline how their system will adhere to the standard. This includes explaining the system’s ability to produce reports that adhere to the standard.
  2. When applicable, the proposed system must be required to share UOCAVA-specific data with state databases in real time and in alignment with the ESB data standard.
  3. Require system vendors to implement existing CDFs, including those specific to UOCAVA voters, and describe how elements or attributes are used for a particular function.

Recommendations related to the security of election systems:

  1. Utilize existing recommendations, guidelines and checklists from federal agencies and security-focused organizations to ensure the RFP for any software-based system contains necessary and explicit cybersecurity requirements, especially related to functionalities that facilitate or enhance UOCAVA voting.
  2. Work with state or local IT departments to draft and receive feedback on security requirements outlined in an RFP, including specific security requirements and protocols for internet-connected systems that facilitate UOCAVA voting.
  3. Develop statewide security standards, guidelines and considerations for non-voting election systems and functionalities that facilitate UOCAVA voting.
  4. Develop evaluation criteria to determine whether a software-based system meets the cybersecurity requirements specified in the RFP.
  5. Utilize resources from state, federal and non-profit organizations and third-party assessments to augment local cybersecurity expertise in evaluating whether a software-based system meets the cybersecurity requirements outlined in the RFP.
  6. Require technology vendors to outline ongoing risk mitigation techniques and related procedures that they will use to ensure the system’s security.
  7. Jurisdictions that allow the return of UOCAVA ballots via email should include sandboxing capabilities as a security requirement.
  8. Require the system to accommodate the use of CAC digital signatures for election-related activities such as submitting an FPCA or returning a ballot electronically.
  9. Outline the types of security-related support needed from the technology vendor, including ongoing support for configuring and testing system functionalities that facilitate UOCAVA voting.
  10. Include language in the RFP requiring a vendor to implement security features or protocols outlined in the solicitation as part of ongoing support provided to the jurisdiction. This includes security requirements or protocols specific to functionalities that facilitate UOCAVA voting.
  11. Require technology vendors to outline their plans and timelines for conducting system maintenance to ensure these operations do not prevent a jurisdiction from meeting administrative deadlines, including those specific to UOCAVA voters.

Background

According to the U.S. Department of Defense Federal Voting Assistance Program’s (FVAP) most recent Overseas Citizen Population Analysis, about three-quarters of the 1.4 million active-duty military and nearly 3 million overseas citizens are eligible to vote absentee. These voters – referred to as UOCAVA voters – face unique challenges when attempting to vote from abroad due to their mobility; the time required to transmit ballots; and the patchwork of laws, rules and regulations throughout the U.S. that govern elections. As a result, UOCAVA voters are significantly less likely to vote than citizens living stateside.

Election officials often use technologies such as election management systems, voter registration databases, online voter portals and election night reporting systems to better serve voters. These technologies can also be used or designed to specifically facilitate UOCAVA voting. Some states develop these systems in-house; however, many utilize a public procurement process to purchase a system that meets their needs.

For many jurisdictions, the procurement process begins with the development of an RFP that outlines, among other things, the required functionalities and security features of their desired system. These requirements must align with applicable state and federal laws; however, election officials have discretion over core aspects of the system’s design and functioning. This allows state and local election officials to ensure that any new election system accounts for the unique needs of UOCAVA voters.

System Functionalities that Facilitate UOCAVA Voting

One of the most important steps in drafting an RFP for any new election system is identifying the necessary core functionalities of the system and clearly delineating these functionalities as system requirements in the RFP. Throughout this process, jurisdictions should consider the unique needs of UOCAVA voters and the functionalities that may be necessary to support them.

Identifying Functionalities that Facilitate UOCAVA Voting

Election systems, such as election management systems, voter portals, or voter registration databases, have core functionalities that facilitate or enhance the UOCAVA voting process. These functionalities can also be incorporated into technology solutions for voting adjacent processes such as ballot processing, ballot mailing, or election night reporting to provide UOCAVA voters with similar benefits. Jurisdictions should identify such functionalities prior to purchasing a new system and include them as requirements in an RFP for any new system.

For example, a jurisdiction’s online voter portal may accommodate using a Common Access Card (CAC) to capture a military voter’s digital signature. This functionality can also be utilized in the ballot curing process, allowing voters who returned their ballot via mail to sign a verification affidavit if a signature mismatch occurs digitally. 

Recommendation 1: Jurisdictions should identify the functionalities of existing systems that facilitate UOCAVA voting and include them as requirements in an RFP for any new system.

Conducting Process Modeling

To determine what UOCAVA-specific functionalities should be included in system requirements, election jurisdictions can map out the UOCAVA voting process – for both administrators and voters – and identify which aspects of the system affect UOCAVA voters. Jurisdictions can then flag these aspects to ensure they are accounted for when developing system requirements.

The OVI has worked with several states to create a visual model of the voting process and the different systems that impact the tracking of UOCAVA voters. The OVI report on process modeling outlines this work and features diagrams of UOCAVA voting processes in five jurisdictions in Pennsylvania.

Process modeling exercises allow elections officials to identify system functionalities that benefit UOCAVA voters. These exercises can bring together various state and local officials to build consensus on administrative processes that, in turn, can help all parties better understand the voting process throughout their state and identify critical data flows and data points that a new election system should collect. For example, voter registration databases often support the maintenance and tracking of remote voters. Through process modeling, jurisdictions can better understand current data collection practices surrounding these voters and identify ways that a new system can expand data collection efforts to include additional details about UOCAVA voters.

Process modeling exercises can also reveal “pain points” in the voting process. For example, many ballots returned by UOCAVA voters need to be duplicated. Process modeling can help jurisdictions identify time-consuming aspects of the ballot duplication process and technology-aided solutions, such as using dedicated ballot marking devices, that can facilitate it. Jurisdictions can then include these solutions, or their core functionalities, as system requirements in an RFP.

Ballot duplication has become a popular topic in recent years due to the expansion of by-mail and absentee voting. The OVI has published several articles on the topic that provide a high-level overview of ballot duplication processes and technologies and recommendations for streamlining ballot duplication. 

Similarly, process modeling may reveal areas where there are synergies with systems that reach other types of voters. For example, a modeling exercise may help a jurisdiction better understand how technologies that are used for UOCAVA voters can be adapted to accommodate the needs of other voters, such as voters with disabilities. Identifying these synergies can help election officials better craft RFPs according to the needs of all voters, not just military and overseas citizens.

Recommendation 2: Jurisdictions should conduct process modeling to identify and determine the functionalities of existing systems that facilitate UOCAVA voting and include them as requirements in an RFP.

Incorporating Ballot Tracking Capabilities

When developing an RFP, jurisdictions should delineate specific ballot tracking capabilities as a required functionality of any new election system. With an increasing number of mail/absentee voters, more Americans rely upon ballot tracking capabilities to know their votes are counted. Ballot tracking keeps voters informed on where their ballot is by sending notifications via phone, email, or text about the status of their ballot – from when their ballot was printed and sent, to when their ballot was delivered and, finally, tabulated. For election officials, these capabilities promote transparency and help build voter trust in the security and integrity of elections.

Ballot tracking is also a particularly effective tool for improving the UOCAVA voting process. When returned via mail, a UOCAVA ballot must pass through multiple mailing systems prior to arriving at the intended election office. This results in longer mailing times for UOCAVA voters and greater uncertainty surrounding the status of their ballot. Ballot tracking capabilities can help eliminate some of this certainty and instill confidence in the success of their ballot.

Election offices nationwide have already delineated ballot tracking capabilities in RFPs for new election management systems. For example, the County of Los Angeles Department of Registrar-Recorder/County Clerk included several ballot tracking capabilities for vote by mail in its 2021 RFP for Election Management System Implementation and Services. The RFP required any proposed election management system to track inbound, outbound, replacement, and undeliverable vote-by-mail ballots and capture images of return envelopes, among other things. Appendix A includes additional RFPs for election management systems that state and local jurisdictions have issued.

Recommendation 3: Jurisdictions should delineate specific ballot tracking capabilities as a system requirement in an RFP for any new system.

Identifying Core Functionalities

A vendor outside of the election space may provide elements of an election system that facilitate or enhance UOCAVA voting. However, these vendors may be unable to submit a proposal if the RFP delineates requirements that only certain election technology vendors can meet. Election jurisdictions can open the door for technology vendors outside the election space to apply by identifying and specifying the desired core functionalities of any new system in an RFP rather than solely delineating their election-specific applications. In doing so, jurisdictions can foster innovation within the elections space and better meet the needs of their voters.

For example, voter registration databases have many core elements that could be considered aspects of a “customer relationship management” system. However, an RFP may require a technology vendor to detail how their product has previously been implemented in an election jurisdiction and evaluate applicants based on this description. As a result, technology vendors that are unable to detail election-specific implementations of their proposed system would fail to meet the RFP’s evaluation criteria.

Recommendation 4: An RFP for any new system should identify and specify the core functionalities of the desired system rather than its election-specific applications to allow technology vendors outside the election space to meet the requirements of the RFP.

Convening a Stakeholder Advisory Committee

Historically, basic regulatory compliance and cost have been the primary drivers in election system design and selection. As a result, election officials may be limited in selecting a voting system based on what is most affordable, what is available on the market or what is approved for use in their state. Systems may later be modified to account for the needs of UOCAVA voters, but only when an issue arises or when funds become available.

To ensure the needs of UOCAVA voters are considered at the outset of the procurement process and incorporated into a system’s design, jurisdictions can adopt participatory approaches to the procurement process. This includes convening a stakeholder advisory committee to help identify improvements to existing systems that can facilitate UOCAVA voting and including identified functionalities as system requirements in an RFP. Advisory members can include stakeholders from within the UOCAVA voting community, including UOCAVA voters, election officials from jurisdictions with significant UOCAVA voting populations, or voting assistance officers from local or nearby military installations. Jurisdictions can also include usability experts, and voters with disabilities to identify the overlapping needs of community members and inform the development of cost-effective functionalities that address these needs.

The county of Los Angeles is a good example of how participatory procurement processes can help election officials better meet the needs of their constituents, including UOCAVA voters. In 2009, the Los Angeles County Registrar-Recorder/County Clerk (RRCC) partnered with the Voting Technology Project to launch the Voting Systems Assessment Project. Through this project, the RRCC modernized the voting experience in Los Angeles County by implementing a new voting model and supporting systems. As part of these efforts, the county collected community input through a voter survey, voter focus groups, a poll worker survey, local election official focus groups and internal discussion groups. The feedback received from community members directly informed the design and development of the county’s new voting system, Voting Solutions for All People (VSAP). State and local jurisdictions can draw from the practices and principles employed by Los Angeles County to ensure any non-voting election system accounts for the unique needs of UOCAVA voters.

The Okaloosa County Supervisor of Elections, Paul Lux, also assembled a similar sounding board when the county procured new voting equipment in 2015. Following the submission of vendor proposals, Lux issued a public notice for a voting system advisory board meeting. The board consisted of IT professionals and representatives from both political parties, the NAACP, disability groups and the League of Women Voters. Board members were responsible for reviewing the RFP proposals received, testing proposed systems and providing feedback to the Supervisor. These efforts demonstrate that all jurisdictions, regardless of size or financial resources can engage in participatory procurement practices.

Recommendation 5: Jurisdictions can employ participatory procurement practices by convening a stakeholder advisory committee to help identify improvements to existing systems that can facilitate UOCAVA voting and include identified functionalities as system requirements in an RFP.

Interoperability Requirements

The ability of election systems to collect and analyze data about voters is critical to understanding and improving voter success. This is especially important for military and overseas citizens, who experience unique voting challenges while living abroad. Ensuring the interoperability of election systems – or the ability of systems to share data with one another using a common format – can improve the quality and usability of data collected about voters, thereby leading to significant improvements in the voting process for military and overseas citizens. Given the increasing role of technology in elections, system interoperability is not only a beneficial capability of these systems but a necessary one.

Implementing the EAVS Section B Data Standard

When purchasing any new election system, jurisdictions should consider its interoperability with existing systems and whether it adheres to standardized data formats. Often, election data is kept in different formats across state and local databases, meaning that the same data point, such as the date of return of an absentee ballot, is stored differently across databases. Without storing this data in a standardized format, election officials may have to use custom conversion tools or rekey information when transferring information across systems, which is time-consuming and error prone.

To promote system interoperability and facilitate the reporting and analysis of UOCAVA data, election jurisdictions should ensure that any new system adheres to existing standardized data formats that apply to UOCAVA voters. This includes the EAVS Section B (ESB) Data Standard, which captures transactional-level data about UOCAVA voters. This data includes:

  • when a voter requests a ballot;
  • when the application is processed;
  • to what country the ballot is sent and when;
  • why an application/ballot is rejected; and
  • whether a voter is military or overseas citizen.

Many of these data points are collected by a state or local jurisdiction’s voter registration database (VRDB) system throughout the voting process. As such, it is particularly important for any RFP for a VRDB to require a proposed system to adhere to the ESB data standard. In the RFP, jurisdictions can outline the UOCAVA-specific data fields and data types that the system will collect and require vendors to demonstrate adherence to the standard. Before developing an RFP, jurisdictions can use the ESB data standard documentation and process modeling exercises to determine which fields are collected by their VDRB.

For example, OVI conducted process modeling with five jurisdictions in Pennsylvania between September 2020 and April 2021. Process modeling sessions sought to examine the lifecycle of UOCAVA voting in each jurisdiction, beginning with the voter’s request for UOCAVA status and extending through the return of the ballot and determination of countability. During these sessions, election officials identified several UOCAVA-specific data points that were collected by their VRDB, including the date a voter requests a ballot, the type of ballot request, the voter’s mailing country and the date the voter’s ballot was transmitted, among others.

How can election jurisdictions benefit from adopting the ESB data standard?

The EAVS Section B (ESB) Data Standard captures transactional-level data about UOCAVA voters for Section B of the EAVS. Currently, states report this data in aggregate for the EAVS, meaning that only the totals of each transaction (e.g., the total number of registered UOCAVA voters, the total number of ballots sent to voters, etc.) are provided for each jurisdiction. Aggregate data can help election officials understand broad trends in the overall experience of UOCAVA voters but reveals little about individual voter experiences. 

By capturing transactional-level data about UOCAVA voters, the ESB data standard can help election jurisdictions better understand the underlying factors that lead to UOCAVA voting success or failure. For example, the ESB data standard can help jurisdictions better understand how UOCAVA voters interact with election offices and what barriers these voters face during the voting process. Given that the standard captures this information for each jurisdiction, these analyses can be made both within and across jurisdictions. Election officials could perform similar analyses for all absentee voters by expanding the ESB data standard to collect data about both UOCAVA and general absentee voters.

This article on Enhancing the EAVS with Administrative Data and the report Using Technology to Enhance Military & Overseas Voting Vol. 2 provide more details on the standard’s benefits.

When requiring a vendor to demonstrate how their system adheres to the ESB data standard, states can detail specific system features or functionalities that any new system should include to facilitate proper collection and reporting of UOCAVA data. States can consider the following best practices related to the design and functionality of an election system that collects UOCAVA data in alignment with the ESB data standard.

Any new system should:

  • Utilize structured selection fields, rather than open, free-form fields, to capture data related to a voter’s mailing country. Structured data fields, such as drop-down menus of options, limit what users can enter for the field to prevent data errors. For example, when recording the country for a UOCAVA voter’s mailing address, the field should provide a list of recognized country names according to the USPS or an international standard like ISO-3166.
  • Produce reports that adhere to the ESB data standard and contain data for all required fields. This information is provided in the ESB data standard documentation, which is available here.
  • Capture and store data iteratively rather than destructively, meaning that the system keeps a history of changes to the data or new transactions. Alternatively, the system can store new data as an additional entry or version and allow access to this data.
  • Utilize data validation requirements to capture data fields according to ESB naming conventions. For example,
    • For the field JurisdictionIdType, validation requirements should only accept identifiers that follow the Federal Information Processing Standard (FIPS) code for the election administration.
    • For the capture of date fields (i.e., RequestDate, BallotReceivedDate, BallotTransmissionDate, ElectionDate) validation requirements should only accept dates that conform to the ISO 8601 standard on dates. The format for these dates is YYYY-MM-DD with no timestamp.

Recommendation 1: An RFP for any new election system should require the proposed system to implement the ESB data standard to collect UOCAVA data and require vendors to outline how their system will adhere to the standard. This includes explaining the system’s ability to produce reports that adhere to the standard.

Sharing and Exchanging UOCAVA Data in Real-Time

To facilitate the interoperability of state and local election systems, jurisdictions can require any new system to share UOCAVA-specific data with state databases in real-time and in alignment with the ESB data standard. In doing so, jurisdictions can ensure that data about UOCAVA voters is stored in the same way across multiple election systems. This consistency can reduce the time and errors associated with manually keying or rekeying voter information when transferring non-standardized data across systems and facilitate state reporting of UOCAVA data for Section B of the EAVS.

Ensuring interoperability between election systems is particularly important in states where there is significant variation in the type of election system used at the local level. In these states, jurisdictions must follow certain state procurement policies and election laws when purchasing a non-voting election system. However, in many instances, local jurisdictions are not required to purchase the same system. As a result, the election system and the format in which data about UOCAVA voters is collected, stored and reported may vary by jurisdiction. Without having this data stored in a standardized format, election systems may be unable to exchange information in real-time and election officials may need to manually key or rekey information to adhere to their system’s standards.

Real-time exchange of UOCAVA data that aligns with the ESB data standard can also ease EAVS reporting requirements for state and local election officials. To varying degrees, many states rely on centralized voter registration databases and voter history databases to enable state officials to provide data for the EAVS. If a local election system does not report UOCAVA data to the state system in real-time, state officials may encounter missing data when completing the EAVS. Moreover, if data reported to the state doesn’t align with the ESB data standard, state officials may identify inconsistencies or errors in the data that may have occurred when the data was manually entered into the state system. The time and effort spent resolving these issues may be costly for states and localities. Requiring any new election system to share UOCAVA-specific data with state databases in real-time and in alignment with the ESB data standard can reduce the costs associated with gathering and reporting data for Section B of the EAVS.

Recommendation 2: When applicable, the RFP for any new election system should require the proposed system to share UOCAVA-specific data with state databases in real-time and in alignment with the ESB data standard.

Implementing Common Data Formats

Common data formats (CDFs) from the National Institute of Standards and Technology (NIST) are an additional tool that jurisdictions can use to enhance the interoperability of election systems and the analysis of UOCAVA data. NIST CDFs cover a wide variety of election system use cases; however, those relevant to UOCAVA data include registration via FPCA (Voter Records Interchange CDF) and support of electronic cast vote records (Cast Vote Records CDF).

CDFs have been developed for various voting system functions; therefore, their benefits extend beyond the collection and analysis of UOCAVA data. Storing data in a well-documented format, such as a CDF, eases public records reporting and helps ensure that new equipment and software can work with existing election technology investments, regardless of the manufacturer.

The Voluntary Voting System Guidelines (VVSG) 2.0 contains requirements for using CDFs for voting systems. However, these requirements do not extend to non-voting technologies such as voter registration databases or election management systems. More specifically, section 3.3-B of the VVSG 2.0 requires voting system manufacturers to provide publicly available documentation describing how the manufacturer has implemented a CDF specification for a particular device or function. This includes descriptions of how elements and attributes are used, constraints on data elements and extensions as well as any constraints

Jurisdictions can draw from this requirement and others specified in the VVSG 2.0 to develop similar CDF requirements for non-voting systems.

Recommendation 3: An RFP for any new election system should require system vendors to implement existing CDFs, including those specific to UOCAVA voters, and describe how elements or attributes are used for a particular function.

Security Requirements and Considerations

While security requirements and considerations should be an integral part of any election system RFP, it is particularly important to establish robust security requirements for systems that facilitate UOCAVA voting given their use of the internet to allow voters to gain election information, request ballots, receive ballots and in some cases transmit voted ballots. In doing so, election officials can enhance voter confidence in all stages of the voting process and ensure voters received reliable, high-quality service provision that improves ballot access.

Developing General Security Requirements Using Existing Resources

Many cybersecurity requirements apply to any software-based system. However, there are several resources that specifically address the security of election systems writ large. It is important to incorporate these security recommendations into any RFP for an election system, especially as they relate to functionalities that facilitate or enhance UOCAVA voting.

Several organizations have compiled guidelines and checklists that outline security recommendations for election systems, including:

Recommendation 1: Jurisdictions should use existing recommendations, guidelines and checklists from federal agencies and security-focused organizations to ensure the RFP for any software-based system contains necessary and explicit cybersecurity requirements, especially related to functionalities that facilitate or enhance UOCAVA voting.

In addition to existing recommendations, guidelines or checklists, jurisdictions can work with state or local IT departments to develop security requirements and protocols as well as interoperability standards for any new election system. State IT departments often do not have personnel dedicated to elections technologies; however, standard security protocols and risk mitigation strategies for information and technology systems can help jurisdictions establish baseline security requirements for election systems and software. IT departments can also help ensure that the security requirements outlined in an RFP are aligned with state regulations governing the security of technology systems.

Election jurisdictions should also request guidance from state or local IT departments regarding cybersecurity protocols for non-voting systems that use the internet to facilitate UOCAVA voting. Internet-connected systems such as election management systems introduce potential risks that can be mitigated by using proper technical, procedural and operational safeguards. IT departments can help jurisdictions identify and account for these safeguards in an RFP. For example, state IT personnel can help election administrators develop RFP requirements for incident response plans and schedules for software updates and patching operations.

Recommendation 2: Jurisdictions should work with state or local IT departments to draft and receive feedback on security requirements outlined in an RFP, including specific security requirements and protocols for internet-connected systems that facilitate UOCAVA voting.

In many states, voting systems must be tested and certified according to federal requirements, as laid out in the Voluntary Voting System Guidelines (VVSG). These requirements, however, do not apply to non-voting election systems. Some states may require systems to undergo additional certification according to state-specific standards, but as with the VVSG, they often do not apply to non-voting systems. Even when a state has such guidelines, they are often not specific to UOCAVA systems or functionalities. This leaves local election officials – often with limited security expertise – to determine when and how certain security standards may apply to non-voting systems.

In the absence of state-level guidance on security standards and protocols, local election officials can use recommendations, guidelines and checklists from federal agencies and security-focused organizations to ensure an RFP contains necessary and explicit cybersecurity requirements. While this may be an effective and necessary stopgap, it can lead to a patchwork of security requirements throughout the state. Moreover, without state-level guidelines to turn to, local election officials may lack the bargaining and enforcement power necessary to ensure that vendors comply with the security requirements outlined in an RFP.

To establish clear security standards and protocols for non-voting systems and facilitate vendor compliance with these requirements, state election officials can develop statewide security standards, guidelines and considerations for non-voting election systems and functionalities that facilitate UOCAVA voting. Jurisdictions can then incorporate these standards into any RFP for a new non-voting election system. When applicable, the Secretary of State or other relevant election authority can also use these criteria to approve or certify a system for use in the state.

States such as North Carolina have developed similar guidelines for IT systems generally, requiring vendors to submit a readiness assessment report as part of local procurement processes. North Carolina’s Vendor Readiness Assessment Report (VRAR) for state-hosted and non-state-hosted solutions can be accessed at https://it.nc.gov/documents/vendor-readiness-assessment-report.

Recommendation 3: State election officials can develop statewide security standards, guidelines and considerations for non-voting election systems and functionalities that facilitate UOCAVA voting.

North Carolina

States such as North Carolina require voting systems to comply with state-specific certification requirements in addition to federal standards. These requirements often no do apply to non-voting election systems; however, states may require technologies that facilitate ballot duplication to comply with voting system security standards. When drafting security requirements for ballot duplication technologies, election officials should consult with their state election authority to determine whether state voting system certification requirements apply to these solutions.

Evaluating System Alignment with Security Requirements

An RFP for any new election system should outline necessary cybersecurity requirements and delineate explicit criteria for evaluating whether a system meets these requirements. Developing clear evaluation criteria can help election jurisdictions better understand whether the cybersecurity requirements outlined in the RFP do, in fact, align with the system’s security needs. This is especially true for systems that utilize the internet to facilitate UOCAVA voting, given the additional protocols and risk mitigation techniques that a vendor must undertake to ensure the system is secure.

Recommendation 4: Jurisdictions should consider developing evaluation criteria to determine whether a software-based system meets the cybersecurity requirements specified in the RFP.

For smaller election jurisdictions or those without dedicated IT or cybersecurity staff, it can be difficult to determine whether a vendor meets the cybersecurity requirements delineated in an RFP. For example, an RFP may require certain encryption standards, but the election jurisdiction may not have the internal expertise to determine whether the respondent does, in fact, meet those standards.

To augment local cybersecurity expertise, election jurisdictions can use existing resources from state, federal and non-profit organizations that are designed to help jurisdictions assess the security of an election system during the procurement process. One available resource for election officials is the CIS Guide for Ensuring Security in Election Technology Procurements, which contains a section explaining what constitutes a “good” response to certain security requirements. For example, to ensure that a new election system meets necessary cybersecurity requirements, CIS recommends that jurisdictions require vendors to outline their processes for identifying and mitigating cybersecurity risks. CIS considers a “good” response to be one that identifies and describes “specific types of risks and the specific actions that were taken to mitigate them. These descriptions should be of a moderate to highly technical nature, referring to specific types of threats or attack vectors, specific port configurations, or the like. The proposer should be able to reference past experience and document their repeatable processes.” The Belfer Center’s State and Local Election Security Playbook also has a section on vendor selection and management (See page 49 of the playbook).

Jurisdictions can also use third-party assessments to provide additional insight into the security posture of the proposed system and help jurisdictions identify whether the system meets the cybersecurity requirements contained in the RFP. For example, the CIS Rapid Architecture-Based Election Verification Program (RABET-V) analyzes non-voting election systems, such as those used to facilitate UOCAVA voting. This includes electronic ballot delivery systems and voter registration databases, among others. RABET-V aims to “provide assurances of security and reliability sufficient for stakeholders to have confidence in their use in election administration.” The U.S. Election Assistance Commission has also created a similar certification program for non-voting election systems called the Election Supporting Technology Evaluation Program (ESTEP). In March 2025, North Carolina became the first state to adopt the ESTEP program’s federal electronic pollbook requirements.

Recommendation 5: Jurisdictions should use existing resources from state, federal and non-profit organizations and third-party assessments to augment local cybersecurity expertise in evaluating whether a software-based system meets the cybersecurity requirements outlined in the RFP.

Mitigating Risks Associated with Internet-Connected Election Systems

Election officials often use the internet to facilitate UOCAVA voting by permitting these voters to request ballots online and, when authorized by state law, accepting voted ballots electronically. Thirty-one states have also authorized some form of electronic ballot return for those voting outside the polling place, whether that be via email, fax or an online portal. The OVI report titled Access to and Usage of Faxing by Military and Overseas Voters provides additional insight into the history and use of faxes by UOCAVA voters.

States, however, do not have total authority over the use of the internet in elections. In some instances, federal law requires election officials to use the internet to facilitate voting. For example, the Military and Overseas Voter Empowerment Act (MOVE Act) of 2009 requires all jurisdictions to be able to transmit blank ballots to UOCAVA voters electronically. Therefore, the use of the internet in specific circumstances is inevitable.

As a result, state and local election officials should take steps to ensure that the proper safeguards are in place to mitigate any potential risks associated with using the internet to facilitate UOCAVA voting. This can, in part, be achieved by requiring vendors to outline certain risk mitigation techniques and related procedures in an RFP. These techniques include ongoing technical, procedural and operational safeguards to help secure internet-connected systems. By requiring vendors to provide this information upfront, jurisdictions can better understand and evaluate the proposed system’s overall security posture before contracting with a vendor.

For example, online portals allowing for blank ballot delivery and electronic return for UOCAVA voters may be susceptible to an attack that could result in a loss of ballot secrecy. However, vendors can mitigate this risk by conducting regular scans for vulnerabilities and misconfigurations within the system’s infrastructure. By requiring vendors to outline such techniques in an RFP, jurisdictions can ensure that the proper safeguards are in place to protect the portal from any potential risks.

Election jurisdictions can read about additional potential risks and risk mitigation strategies for similar systems in The Turnout’s paper on UOCAVA Electronic Ballot Transmission: Recommendations to Mitigate Security Risks. 

Recommendation 6: An RFP for any internet-connected system should require technology vendors to outline ongoing risk mitigation techniques and related procedures that they will undertake to ensure the system’s security.

Using Sandboxing Techniques for Emailed Ballots

When authorized by state statute, email is the most popular method of electronic ballot return used by UOCAVA voters. Jurisdictions can mitigate the potential security risks associated with receiving emailed ballots by including sandboxing capabilities as a security requirement in an RFP.

Sandboxing” is a cybersecurity term that describes an isolated network environment that allows materials to be received and reviewed without exposing the rest of the network to potentially malicious material. States such as South Carolina and New Jersey have already sought to mitigate the potential risks of using an internet-connected system to transmit and return ballots by implementing sandboxing techniques.

The OVI article How the Adoption of Secure Email Accounts and Sandboxing Techniques Strengthen the Electronic Ballot Return Process for South Carolina’s Military and Overseas Voters details the state’s adoption of these techniques to receive ballots from UOCAVA voters. South Carolina’s success with sandboxing centers around creating secure email addresses for all election officials. These email addresses were set up by the State Election Commission and State Data Center on .gov domains and allowed election officials to access a more secure environment where electronic ballot attachments could be opened securely to identify potential malware or viruses without harming the host device or network. Additional information on the security benefits of .gov domains can be accessed here.

The New Jersey Division of Elections also used sandboxing techniques as part of their “Go Bag” program that created a mobile elections office with many of the supplies needed to continue business operations in the case of a disaster, crisis, or emergency. These “Go Bags” served as a stand-alone workstation, containing a dedicated Chromebook with a sandboxing environment for retrieving and processing UOCAVA ballots returned electronically. More information about New Jersey’s use of “Go Bags” and sandboxing techniques is provided in the OVI article Sandboxes and “Go Bags”: How New Jersey Election Officials Prepare for Crises.

Recommendation 7: Jurisdictions that allow the return of UOCAVA ballots via email should include sandboxing capabilities as a security requirement in an RFP for any new system.

Using Common Access Cards for Digital Signatures

Election jurisdictions can enhance the security of internet transmissions to and from UOCAVA voters by ensuring that any new system can accommodate the use of a U.S. Department of Defense (DOD) Common Access Card (CAC) to capture a digital signature for election-related activities. A DOD CAC is an identification card that is issued to eligible individuals who have completed an extensive background investigation, consisting of a federal background check and a favorable FBI fingerprint check. The card is used to verify the cardholder’s identity through multiple means, including multi-factor authentication.

A CAC has many uses; however, in the context of elections, it allows UOCAVA voters to securely provide a digital signature on election-related materials such as the Federal Post Card Application. This effectively eliminates the need for a voter to provide a wet, or handwritten, signature on documents returned electronically, which often poses an obstacle for UOCAVA voters stationed abroad who lack access to a printer or scanner. In doing so, CAC digital signatures significantly reduce the time needed to request and return documents electronically. These benefits, however, are limited to military voters given that military spouses or overseas citizens are not eligible to be issued a CAC.

More information about how CACs can be used to help accommodate UOCAVA voters can be found in the OVI report Recommendations from the CSG Overseas Voting Initiative Technology Working Group and Using Technology to Enhance Military and Overseas Voting Vol 1. 

Recommendation 8: In an RFP for any new election system, jurisdictions should require the system to accommodate the use of CAC digital signatures for election-related activities such as submitting an FPCA or returning a ballot electronically.

Ongoing Security Procedures

As with any other IT solution, security vulnerabilities can emerge anytime in an election system’s lifecycle. Remedying and protecting a system against these vulnerabilities requires vendors to act quickly and effectively. To do so, technology vendors should conduct ongoing security procedures, including frequent evaluation of the system’s physical and virtual security environments. Jurisdictions can ensure these procedures are in place by outlining the types of ongoing security-related support needed from the vendor in an RFP for any new system. For instance, jurisdictions can require a technology vendor to identify and describe the specific risks they will be monitoring and the ongoing procedures they will follow to mitigate these risks. This can include technical descriptions of each threat and explicit configuration and testing procedures for system functionalities that facilitate UOCAVA voting.

Recommendation 9: An RFP for any new election system should outline the types of security-related support needed from the technology vendor, including ongoing support for configuring and testing system functions that facilitate UOCAVA voting.

When procuring a new election system, election officials often face time constraints that can limit the length and scope of the bidding window and the contract negotiation process. These limitations may require election officials to contract with a vendor whose system does not meet all the functional or security requirements contained in the RFP.

For example, a state or local jurisdiction may need a new electronic ballot delivery system that is fully operational before an upcoming election and the 45-day UOCAVA ballot transmission deadline. Election officials may initiate the procurement process months before this deadline, but the contract must still be finalized in time to test and load ballot styles into the system, among other things. While submitted proposals may account for all the functional requirements, they may not meet all the RFP’s security requirements. Without sufficient time to extend the bidding window or engage in contract negotiations, the jurisdiction may be forced to procure a system that does not adhere to all security requirements delineated in the RFP.

In these circumstances, jurisdictions should not have to forgo security requirements to comply with statutorily mandated deadlines. To help prevent this, states can include language in an RFP requiring a vendor to implement the security features or protocols outlined in the solicitation as part of ongoing support provided to the jurisdiction. This can include any security requirements or protocols that were unaddressed in the vendor’s proposal, including those specific to functionalities that facilitate UOCAVA voting. Jurisdictions can also earmark contract funds for these purposes. An example of language that can be used in an RFP is provided below.

Section X. Scope of Services

X.x. Modifications and Upgrades 

X.x.x. The Contractor shall provide at no additional charge to the [jurisdiction] for the life of the maintenance contract:

  1. All software modifications and upgrades that are necessary to comply with changes to local, State, and Federal election laws or Voluntary Voting System Guidelines issued by the United States Election Assistance Commission;
  2. All hardware and software modifications necessary to correct defects in the system; and
  3. All hardware and software modifications necessary to comply with the system security requirements contained in this solicitation under [relevant section, sub-section].

Recommendation 10: States can include language in an RFP requiring a vendor to implement security features or protocols outlined in the solicitation as part of ongoing support provided to the jurisdiction. This includes security requirements or protocols specific to functionalities that facilitate UOCAVA voting.

Conducting System Maintenance Operations

In addition to security monitoring, ongoing maintenance and patching operations are central to a technology vendor’s ongoing relationship with an election jurisdiction. Patching keeps system software up to date and remedies any identified security vulnerabilities in the system. While applying system patches and conducting software updates, the system’s functionality may be limited. As such, an RFP for any new election system should require vendors to outline their plans and timelines for conducting system maintenance to ensure these operations do not impede a jurisdiction’s ability to meet administrative deadlines.

A vendor’s maintenance plans and timelines must take UOCAVA-specific deadlines into account. Given the difficulties faced by military and overseas citizens when attempting to vote, the Uniformed and Overseas Citizens Absentee Voting Act, as amended by the MOVE Act, requires absentee ballots be sent to UOCAVA voters at least 45 days before a federal election. This requirement applies only to UOCAVA voters. Failing to meet this deadline may impede a UOCAVA voter’s ability to return their ballot in time for it to be counted and included in the final tally. Jurisdictions should ensure that system maintenance and patching operations do not interfere with this deadline.

Recommendation 11: An RFP for any new election system should require technology vendors to outline their plans and timelines for conducting system maintenance to ensure these operations do not prevent a jurisdiction from meeting administrative deadlines, including those specific to UOCAVA voters.

Conclusion

The Overseas Voting Initiative has studied various technologies that election offices use to ease the voting process for UOCAVA voters and other absentee voters. This document is a culmination of that research, providing several recommendations for drafting an RFP related to the functionality, security and interoperability of systems that facilitate UOCAVA voting.

Drafting and issuing an RFP for election technology is a laborious effort. Technical specifications, cybersecurity requirements, state legislation, procurement laws and product offerings constantly change. Moreover, no two states are the same in how they administer elections. Even though procurement policies and jurisdictional needs vary, states can learn from and adapt the practices of one another to better serve voters in their state. This document does not specify the state or federal regulations with which an election system must comply. Rather, it seeks to facilitate sharing of best practices across jurisdictions to inform the development of RFPs that enhance the UOCAVA voting process.

Appendix A: RFPs for State and Local Election Systems

This appendix contains links to election system RFPs issued by state and local election offices between 2016-2025. It is not exhaustive but is the culmination of web-based research spanning state and local government websites and the U.S. Election Assistance Commission online repository of RFPs. Additional contributions were provided by OVI Working Group members and other stakeholders. The examples contained in this appendix are intended to serve as resources for states when drafting an RFP for any new election system. They have not been assessed as to whether they conform to the recommendations outlined in this document.

If your state or local jurisdiction has issued an RFP for an election system that is not listed below, please contact elections@csg.org. OVI staff will update this table with the RFP and other relevant information provided.

StateType of RequestJurisdictionYear Link to RFP
AlabamaElectronic Poll Book System or SystemsStatewide2017Link
Computerized Statewide Voter Registration and Election Management SystemStatewide2017Link
Electronic Blank Ballot Delivery & Electronic Voted Ballot Return System for the 2018 Regular Election CycleStatewide2018Link
Computerized Statewide Voter Registration and Election Management SystemStatewide2019Link
Electronic Blank Ballot Delivery & Electronic Voted Ballot Return System for the 2020 Regular Election CycleStatewide2019Link
Electronic Vote Counting SystemStatewide2019Link
Electronic Poll Book System or Systems for Four (4) YearsStatewide2019Link
Voter Registration and Election Management SystemStatewide2020Link
Electronic Blank Ballot Delivery & Electronic Voted Ballot Return SystemStatewide2021Link
AlaskaStatewide Voting and Ballot Tabulation SystemStatewide2019Link
ArizonaAccess Voter Information Database (AVID)Statewide2017Link
Elections Tabulation SystemMaricopa County2019Link
CaliforniaVoting SystemCity and County of San Francisco2018Link
Modern Voting SystemCounty of Marin2018Link
Voting SystemOrange County2019Link
Election Voting System, and Associated Licensing, Service and MaintenanceHumboldt County2019Link
Election Management Implementation and ServicesCounty of Los Angeles2021Link
DelawareElections System SolutionStatewide2018Link
GeorgiaNew Voting SystemStatewide2018Link
Statewide Voting SystemStatewide2019Link
IdahoElectronic Poll BooksAda County2019
Voter Registration and Election Management System SolutionStatewide2024Link
IllinoisVoting SystemCity of Chicago2017Link
Voter Registration and Poll Book Software and Vendor SupportChampaign County2019Link
Voter Registration and Election Management SystemMcHenry County2019Link
Election And Voting EquipmentUnion County2019Link
Ballot on Demand SystemDuPage County2021
Link
Voter Registration and Election Management SoftwareMacoupin County2023Link
Voter RegistrationChampaign County2024Link
and Pollbook Software and Vendor
Support
Election Equipment and ServicesCounty of La Salle2023Link
Election VotingRock Island County2024Link
Equipment, Voter Registration Software and Election Management Software and Components
IowaVoting Equipment, Software and ServicesWoodbury County2018Link
Voter Registration and Election Management SolutionStatewide2022Link
KansasElection Management SoftwareSedgwick County2020Link
KentuckyBallot Scanner, Tabulator and Voting SystemKenton County2020Link
LouisianaAcquisition of New Voting SystemStatewide2021Link
MaineCentral Voter Registration and Election Management SystemStatewide2021Link
MassachusettsElectronic Vote Tabulation MachinesTown of Wilmington2021Link
Electronic Voting EquipmentTown of Bourne2024Link
New Voting Equipment, Software, and TrainingCity of Springfield 2024Link
MississippiTurnkey Election System including Precinct Scanners, Ballot-Marking Devices, Accessories, Software, Testing, Rental Services and Training Neshoba County2019Link
Electronic Poll BooksHancock County2020Link
Turnkey Election SystemItawamba County2022Link
MissouriElectronic Poll Books and Election Management System St. Louis County2016Link
Voting Software and Technical HardwareFranklin County2019Link
Voting SystemsCounty of Boone2019Link
Elections Management SoftwareSt. Charles County2021Link
New JerseyVoting Systems and Related Services and AccessoriesStatewide2020Link
Electronic Poll books, Related Hardware, Software, Licensing and Maintenance SupportOcean County2021Link
General Election Secure Ballot Delivery SystemStatewide2023Link
Voting Machine Equipment, Software Licensing, Consumables, and Related ServicesOcean County2023Link
New MexicoBallot on Demand System and Ancillary EquipmentStatewide2023Link
OhioVoting Systems Statewide2017Link
PennsylvaniaVoting Equipment, Software and ServicesAllegheny County2019Link
Voting SystemsLuzerne County2019Link
Electronic Poll BooksLuzerne County2023Link
Rhode IslandCentralized Voter Registration SystemStatewide2019Link
South CarolinaVoter Registration System MaintenanceStatewide2018Link
TennesseeReplacement of Voter Registration and Election Management SystemShelby County2017Link
Voting Equipment and/or ProgramBlount County2019Link
Voting System and EquipmentWhite County2019Link
Voting Machine and Election Management System ReplacementShelby County2020Link
TexasVoting System Software and ServicesCounty of El Paso2016Link
STAR-Vote - New Voting SystemTravis County2016Link
Voting Tabulation SystemCounty of Rockwell2017Link
Election Voting System and ServicesCollin County2018Link
Elections EquipmentTarrant County2020
Voter Registration SoftwareGregg County2023Link
UtahElectronic Poll BooksStatewide2018Link
Election Management SystemStatewide2019Link
WashingtonTabulation Software SystemBenton County2017Link
Risk Limiting Audit Software and SupportStatewide2023Link
Election Results Reporting SystemStatewide2025Link
WisconsinElection Management System (Hardware and Software)Outgamie County2017Link