A Handbook for Elections Infrastructure Security

Critical activities and best practices in elections Infrastructure security.

Protect your elections infrastructure with this free best practices handbook and other resources from CIS and our elections partners.
Mitigating risk is, ultimately, about decisions and actions that establish trust in aspects of a system, leading to confidence in the outcome. Risk must be considered at every stage of a system – requirements, design, development, operation, and even for disposal or retirement (e.g., removal of sensitive information). Like many systems, for election systems this involves establishing trust in users, devices, software, and processes. Many systems are “composed,” or built up from a variety of commercial and purpose-built parts, devices, and software connected via processes and user actions. The results in security decisions about trust are made across many components and brought together at a system level. In other cases, key election system components or services functions are contracted out. This does not change the security responsibility for decision-makers, but forces them to think about how the desired security properties can be specified in contract language and service specifications, rather than implemented directly. This part of the handbook contains:
  1. A set of critical risk-mitigating activities from which all organizations can benefit,
  2. Recommendations for best practices in contracting for IT services, and
  3. A set of best practices in the form of recommendations and controls for network connected and indirectly connected devices, as well as for transmission of information.

Critical risk-mitigating activities


Election officials conduct many audits of all aspects of the election process (e.g., vote by mail processing, training, equipment delivery) and election systems (e.g., voter registration transactions, audit log data). However, the focus of this section is on auditing vote capture and tabulation in an election. Included in this is to validate that the aggregated results reflect the actual ballots cast. One auditing approach is to select a sample of the ballots and, applying a structured process, do a partial recount of the ballots. This controlled audit is intended to provide confidence that the voting results are accurate based on the results of that partial recount. Moreover, audits provide information to election officials that go beyond the requirements for audit and recounting results; audits are the “production time” opportunity for election officials to know that the systems they are using are working properly. The approach to auditing can vary based on a number of factors, including requirements that may be established within elections jurisdictions. Some auditing requirements call for a manual recount of a set percentage of ballots, others—including risk limiting audits described below—leverage statistical methods to determine the extent of the recount. Auditing requirements typically also have a trigger for a larger recount or full recount based on the outcome of the initial audit. Given the potential expense of auditing, it is critical to properly design audit procedures to reduce costs while achieving the goals of the audit.

Objective auditing in Linn County

In Iowa, Linn County Election Services hired a cybersecurity firm to conduct an audit of various aspects of the county’s elections infrastructure. The firm submitted recommendations, and the county decided which of those to prioritize for implementation. The goal in hiring a third-party vendor was to provide objective, professional advice and assistance. This helps ongoing security efforts and gives confidence to the public that Linn County is taking cybersecurity seriously in its elections.
Almost all states have provisions for a full recount of a contest should the result of that contest fall within the state required recount margin (for instance, many states require a recount for a statewide race if that race is within one half of one percent after certification). The initial audit size and recount triggers are critically important to a good audit. As important is the method by which the audited ballots are selected. Establishing proper methods for random selection of ballots can have a tremendous impact on the audit’s ability to confirm election results or show evidence of tampering. For election officials, the first step to a good audit is recognizing that records must be kept in order to make an audit possible. This means allocating resources to support an audit, along with procedures for efficiently executing the audit and making it sufficiently transparent for interested parties. While audits are not inherently digitally-based efforts, establishing an audit process, with resources, ballot selection methods, audit size rules, and recount triggers, is a critical aspect of mitigating risk across all aspects of elections.

A best practice: risk limiting audits

A possible weakness in some traditional auditing methods is that often either more ballots or fewer ballots are recounted than necessary to validate the results. This can either produce an audit that doesn’t fully validate the outcome of the election, or an audit that is more costly than necessary without increasing confidence in the results. More recently, the concept of risk limiting audits has been introduced as an approach to auditing election results that is both effective and efficient. In addition to those characteristics necessary in a traditional audit— resources, good ballot selection methods, and prior-determined rules—in a risk limiting audit the size of the audit and recount triggers are based on a “stopping rule” determined by the likelihood that the actual election outcome differs from the reported outcome. Put another way, additional ballots are recounted in the audit until there is a pre-determined statistical level of confidence that the reported result is correct. As an example, a very large margin of victory will typically result in a relatively small audit size, as a very large error would have to occur to change the outcome. A very close election, on the other hand, would require a larger audit.

In practice: risk limiting audits in Colorado

Recently, the state of Colorado established a legal requirement that all elections be subjected to a risk limiting audit. The Colorado Secretary of State defines the “risk limits” for each election. The risk limits (i.e., the acceptable probability that the election results might not be correct based on the statistical analysis process implemented within the risk limiting audit) will guide the process of selecting the size and distribution of the sample to be subjected to the initial audit, and in turn successive audits if they are required to achieve the risk limit confidence. The trend of leveraging risk limiting audits continues to gain steam, and election organizations should consider Colorado as a use case from which they can learn. The References section of this handbook provides additional information on Colorado’s approach.
In a risk limiting audit, the size of the audit is determined by the results of the audit itself. That is, the closer the audited results are to the actual outcome, the sooner the audit ends. This is termed the statistical confidence in an election’s results. As soon as a previously-determined confidence threshold is met, the audit can stop. As in all audits, units—precincts, machines, batches of paper records—should be selected using random sampling methods. In a risk-limiting audit, the sample size will depend on the margin of victory and other factors; these other factors may include the number of ballots in each precinct and the overall number of ballots in the contests. In general, smaller margins of victory and fewer total votes cast require auditing a larger percentage of the ballots cast. These methods are well-documented and replicable through sources such as ElectionAudits.org.

Incident response planning

Despite the best efforts of election officials and their technical staff, there is some likelihood that there will be an incident at some point during an election cycle. This is the nature of cybersecurity; the true measure of success is often the resiliency of an organization in the face of these incidents. Incidents can be minor, having no real potential for impacting the election results or public perception of the elections process, or they could be major incidents requiring prompt action to ensure the actual or perceived integrity of the election results. An incident could be a direct attack on some portion of the election system, or it could be a potential threat that might affect confidence in the system (e.g., a reported major flaw in a foundational COTS component of many election systems). Experience shows that successful incident response depends almost entirely on planning and preparation—the work done before any incident occurs. Good technical and process controls will minimize the attack surface and also help to enable timely analysis of the incident. Identifying key decisionmakers and their roles ahead of time allows for effective response. Planning and preparing begins with creating a plan for diagnosing and recovering from incidents and exercising this plan. To properly develop and exercise these plans, efforts must include a wide variety of stakeholders— ideally all stakeholders that would be involved in response to and recovery from the incident itself. All stakeholders, including seemingly sovereign ones such as federal, state, and local officials, must collaborate in incident response and recovery; they must also collaborate in preparing for those incidents. As the threats change, so must plans. Officials must update documentation regularly and include specific plans for addressing modern cybersecurity risks, such as those presented throughout Part 2.

In practice: recovery ready in Cook County and California

In Illinois, since 2007, the Cook County Clerk’s office has worked with an independent data analysis firm, Data Defenders, LLC, which has implemented its Applied Computer Forensics process, called Election System Auditing (ESA)™, as part of an overall election integrity management plan. For each election, the forensics process takes three “snapshots” of the election equipment: one prior to pre-election logic and accuracy testing (Pre-LAT), one immediately after Pre-LAT, and a final one after the election has finished and the equipment is returned from the polling places and early voting sites. These snapshots capture all of the information that makes up the software and firmware. Snapshots are encrypted and hashed so that any tampering with the snapshot will be immediately detectable. The three snapshots’ hash values are compared with each to see if the software has been altered at any stage of the election process. A reference copy of all software and firmware used by the voting system is obtained by the County Clerk from a third party source such as NIST or from a certified Voting Systems Testing Laboratory. The forensic analysis compares the before and after images listed above to the reference copy and reports on any discrepancies. The reporting identifies any altered or deleted files, programs, scripts, or other operating components. In the case of a discrepancy, the analysis can recover the information and identify the precise lines of code that were added, altered or deleted. Not all jurisdictions take this approach. In California, for example, the state requires that a master image be created and that image be reinstalled prior to every election. The master images are created using the trusted build files that are provided to the jurisdiction by the EAC or State of California. The trusted build is the file that is built from the source code that was reviewed and certified. The decision of how often to create master images are a case-by-case decision, but the broader point remains: the ability to restore from a backup is critical to graceful recovery, and the ability to compare a system to a known good state is critical for identifying problems.
Incident response generally follows a lifecycle of: prepare; detect and analyze; contain, eradicate, and recover; and manage post-incident. Again, it begins with documenting and exercising, but in recovery this includes specific information about the systems and processes that may be impacted, such as knowing the hardware and software comprising specific systems, as well as things such as hashes of critical files—a way to validate whether a file has been tampered with from its last known good state. In preparing for incident recovery, one of the most critical mitigation strategies is to ensure proper backups that are secured separately from the affected systems and networks in advance of a potential incident. The process of actually recovering starts with understanding the incident. As part of that analysis, decision-makers need to understand the impact of the incident so they can prioritize resources appropriately. Recovery is about getting back to a viable state—in some cases, the priority isn’t to directly fix the problem, but rather to work around it to get to the desired outcome without the affected system. This is nothing new in the elections context: when a vote capture device breaks, it may be desirable to fix it, but it may be better at the moment to move to paper ballots so votes can be cast efficiently. The same logic may apply in a cybersecurity context across the elections ecosystem; the most important reaction is often to return to an operational state, even if it’s not the optimal state. Recovery, then, is about getting to the best possible outcome in light of the current circumstances. With proper planning and exercising, officials can avoid the impact of an incident that could prevent successfully executing an election, even when seemingly all has gone wrong. Attacks such as those that would be directed at an election come with a motivation to impact the election in some way. Nothing serves as a greater disincentive to an attacker than knowing that their target will recover quickly and completely. And little serves to build trust with the public like a plan to achieve an accurate result even if an attack is successful. Just as with other aspects of cybersecurity, by taking the time to prepare before an incident occurs, election officials can actually turn away attackers before they arrive.

Contracting for systems or services

Many organizations use contractors or vendors to provide election system components and services to support elections processes or elections system operations. Election officials should assess the contracted supply chain in addition to support provided internally. In instances where there is contract support, officials should carefully analyze requirements for security and clearly define them in the contract. The government organization that is doing the contracting has the responsibility to assess the security risks for the component or service based on an evaluation of potential threats and security weaknesses or vulnerabilities as well as the probability of occurrence and resulting consequences. Security considerations should be an important consideration in the process of evaluating and selecting a contractor. If the elections staff is contracting for services that are managed by a contractor or vendor, such as hosting of elections-related software or operations of elections systems, the contract should require that the company providing managed services also provide documentation of their cybersecurity processes and controls, including security metrics that are being collected and monitored. Contractor controls can then be compared to the controls listed in this handbook. The contract should include a definition of services to be delivered (called a service level agreement or SLA) that includes security controls identified in this handbook. Moreover, a best practice would be that the contractor is subjected to regular independent audits of security controls, with results available to the government organization. Elections officials may wish to have their own security audits. The contract will need to provide for this and the elections officials will need to set aside funds for the audits. For elections system components that are subject to elections system certification requirements, evidence of certification is required. Ideally, there should also be a provision for the contractor to provide security updates to the component over its lifecycle to ensure that vulnerabilities that are discovered are corrected and the component is recertified. For system components or services that are not subject to certification, security requirements will need to align with the particular capabilities or services provided in the contract. Many of the best practices listed in this handbook may be appropriate to include as contract requirements. In general, the contract should require that the contractor provide a security plan as one of the initial contract deliverables. The security plan should describe how the contractor will meet the security obligations of the contract and specify the security practices and procedures that will be used. Of particular importance in specifying security requirements for contractors will be to address how elections-sensitive information (e.g., ballot layout, voter personal information, vote results) is protected during the execution of the contract and how information records are destroyed. Additionally, contracts should address the obligations of contracted system operators and public sector clients in regards to identity theft liability, control of and access to public and private data under open records laws, and incident response plans and processes. Where possible, contracts also should specify that vendors transmit network, system, and application logs to the client’s security information and event management tools if the client requests. This would allow election officials and their staffs to review and monitor activity instead of being solely reliant on the vendor’s capacity for monitoring. Guidelines for ensuring security of contracted support has been described in the publication ISO/IEC 27002. Specifically, section 15 of the standard describes security issues that should be addressed in dealing with suppliers. The Appendix to this handbook contains a reproduction of this section. Contracting and technical personnel are encouraged to use this or a similar resource to help identify and assess potential risks as well as responsibilities that will need to be addressed in contract documents and in managing suppliers.

Security best practices

These recommendations are derived from extensive experience understanding the types of vulnerabilities found and attacks experienced across a very wide variety of enterprises, and then translating that into specific and positive steps to mitigate those vulnerabilities and threats. Those recommendations are tailored based on the system and “mission” issues that are unique to elections systems, and the confidence expected for successful outcomes. The process used also examined the various guidelines and specifications used in this sector in order to maintain consistency and minimize overlap. All of the recommended practices are grouped by class of connectedness (i.e., network connected, indirectly connected, transmission), which was identified as the key factor in assessing security risk. In addition, recommended practices that specifically deal with transmission (electronically or manually) are grouped as a collection for ease of reference.

Network Connected

Network connected components work directly with other devices or systems to achieve their objectives. These connections provide many benefits (e.g., remote diagnostics and management, simple data transfer, rapid updating), but also introduce additional risks that must be taken into consideration when managing the lifecycle of the device. Most network connected devices will provide a remote means to accessing and managing the devices, which means organizations must take extra efforts to protect access to those capabilities. Network connected devices do not necessarily have to be connected to the internet.

Indirectly Connected

Indirectly connected components are not persistently interconnected with other devices. They do, however, have to exchange information in order to complete their objectives in the election process. While these devices do not carry the same risks associated with being connected to a network or the internet, connecting these components to other devices, either through the use of removable media or direct wired connects, can introduce threats. Mitigating these risks requires a particular set of controls and recommendations when managing the device.


In addition to the level of network connectedness, recommendations to address the broader risk of transmission of information across systems are listed separately. These can provide different and sometimes unexpected avenues of attack. These can also involve information transmitted to or from supporting systems that are easy to overlook in terms of security criticality (e.g., the printing of pollbooks, scheduling systems).

Structure of the best practices

Each best practice includes the following information:
  • Asset Class (Device, Process, Software, User) — the portion of the overall system to which the practice applies.
  • Priority (High, Medium, Low) — from a security perspective (in this handbook, only High and Medium practices have been included).
  • Applicable CIS Controls — a cross-reference to the most applicable of the CIS Controls (which can provide a deeper description of this type of practice, and pointers to other information).
We also provide information intended to help decision-makers calibrate the potential challenges of implementation. However, these should be treated as rough guidelines for a “typical” situation – not a rule that can be applied to every election system.
  • Potential User Resistance (Yes/No) — Would implementation of the practice be expected to cause resistance or complaints by users and operators of the system? If so, extra care might be needed for rollout or training; and care should be taken so that implementation doesn’t encourage the use of risky “work-arounds.”
  • Upfront Cost (High, Medium, Low) — Does this practice typically require the purchase of new technology, or other significant capital expenditure (High)? Items can be listed as Low when no separate purchase is needed, often because the recommendation can be implemented using existing technology, into the basic configuration of the purchased system, or through operator action.
  • Operational Cost (High, Medium, Low) — What are the expected post-purchase costs of this practice? Are there high costs associated with things like supplies (e.g., media, special licensing)?

Summary of connectedness in elections infrastructure components

Part 2 describes the components of a generalized elections system. The end of each subsection classified the different approaches to implementing each component based on the extent to which the component is connected to networks. These connectedness classifications are summarized in Table 1 and form the basis of the best practices. Depending on specific implementation, some of these classifications may vary. However, unless compelling information suggests otherwise, components should be protected at the level indicated. From Part 2, election officials and others should be able to step through each component to determine the manner (or manners) in which it is implemented in a given election jurisdiction. Once the approach is known, the connectedness classification, summarized here, maps to specific sets of best practices found in the remainder of Part 3. As noted in Part 2, the components below are a subset that, in our view, reflect the highest risk targets. For digital components not listed below, the analysis methods described in Part 2 can be applied to determine the appropriate correctness class and the associated best practices applicable to that component. Practitioners can implement these best practices in any order, but we recommend beginning with the high priority best practices.

Summary of connectedness for elections infrastructure components

Component Type within component Connect Class
Voter registration Master systems and databases Network connected
1 Online Network connected
2 Paper-based Not connected
Transmission of a registration via email of fax Transmission-based
Pollbooks e-Pollbook, connects via a wired or wireless network Network connected
e-Pollbook, connects via a physical media connection or removable media Indirectly connected
Transmission of data for printing via a network connection, website portal, or email Transmission-based
Transmission of data for printing via a wired media connection or removable media Transmission-based
EMS 1 Unless definitively known to have no network capabilities Network connected
2 If known definitively to have no network capabilities Indirectly connected
Vote Capture Vote capture device transmits data for any reason—or if the functionality is enabled regardless of whether it is used Network connected
1 Voter marked and hand counted paper balloting Not connected
2 Voter marked paper balloting with scanning Indirectly connected
3 Electronic voting with paper ballot output Indirectly connected
4 Electronic voting with paper record Indirectly connected
5 Electronic voting with no paper record Indirectly connected
6 Electronic receipt and delivery of ballots conducted remotely Transmission-based
Vote tabulation 1 Connects via a wired or wireless connection Network connected
2 All others Indirectly connected
Election night reporting 1 If receiving tabulated votes via a wired or wireless connection Network connected
2 If receiving tabulated votes via a wired media connection or removable media Indirectly connected
Election night publishing 1 All
Best PracticesArrow

Information Hub : Elections Resources