From ~2019 to 2024, CISA conducted technical and operational activities to evaluate certain US election systems, all upon request of system owners/operators, including software examination, penetration testing of SLTT (state, local, tribal, and territorial) networks, and incident response for election-system intrusions (p.1).
p.1Election Report (CISA)
Key Insights
AI-generated from the sourced claims — verify against the documents.
Structural constraints in the certification ecosystem limit vendors' ability to patch quickly; some certification regimes require that no patches be applied for months before an election, so systems are deployed with known, unpatched issues.
In multiple cases CISA assessors gained full network control within hours or days, showing many SLTT partners remain 'soft targets'.
Vendor threat models assume strong segmentation between election systems and enterprise IT, but 2019-2024 assessments showed election systems reachable from enterprise hosts via shared auth domains, legacy VLANs, or 'temporary' exceptions; poor firewall hygiene; co-location on general-purpose virtualization clusters; and unreliable 'airgap' assumptions.
The Critical Product Evaluation program created disincentives for transparent, industry-standard vulnerability disclosure; it was retired in 2024 based on stakeholder feedback.
In 2020, ImageCast X Ballot Marking Devices printed ballots encoding selections in a barcode voters could not verify, and a researcher showed hackers could change the barcode-encoded votes without physical machine access.
22 sourced claims
CISA notified the owner/operator in every case it identified a vulnerability in a product or network and encouraged mitigation (p.1).
p.1Structural constraints in the certification ecosystem limit vendors' ability to patch quickly; some certification regimes require that no patches be applied for months before an election, so systems are deployed with known, unpatched issues (p.1).
p.1SLTT election-office IT networks frequently lack cybersecurity hygiene; election infrastructure is often accessible from general enterprise networks, enabling lateral movement by adversaries who compromise email, workstations, or other IT assets (p.1).
p.1US election security is shaped by three factors: (1) software vulnerability management constrained by outdated certification regimes; (2) inconsistent vendor transparency on vulnerabilities and patch status; (3) cybersecurity immaturity of many SLTT networks (p.1).
p.1From 2019-2024 CISA partnered with Idaho National Laboratory (INL) on the Critical Product Evaluation program for direct technical assessments of election software, often before public release, upon vendor request (p.2).
p.2Assessment methods included static source-code review, binary fuzzing of parsers/media handling/data import modules, cryptographic implementation analysis (PRNG misuse, poor key handling), interface/authentication/authorization/API testing, supply-chain dependency reviews, and dynamic analysis in adversarial runtime environments (p.2).
p.2The Critical Product Evaluation program created disincentives for transparent, industry-standard vulnerability disclosure; it was retired in 2024 based on stakeholder feedback, with final reporting concluding in 2025 (p.3).
p.3Vulnerabilities found included input-validation bugs, insecure deserialization, insufficient logging, race conditions, insecure crypto primitives, and privilege-escalation paths; CISA did not independently validate whether production builds in SLTT environments incorporated all fixes (p.3).
p.3SLTT officials face update difficulties due to minimal IT budgets/staff, short deployment windows, and "lockdown" periods (sometimes mandated by state law) barring changes before election day; state laws may require only EAC (Election Assistance Commission)-certified software, delaying updates that postdate certification (p.3).
p.3Technical risks: vendors cannot ship fixes outside narrow certification cycles without jeopardizing eligibility; third-party components (OS, drivers, middleware, crypto libraries) cannot be patched at modern cadence; legacy OS baselines accumulate unpatched vulnerabilities; absence of secure auto-update prevents rapid zero-day response (p.3).
p.3CISA recommends national policymakers encourage harmonization of patch-management and certification rules (p.4).
p.4Across penetration tests and red-team engagements, CISA observed flat/minimally segmented networks, weak identity and access management (poor MFA, shared credentials, weak service-account hygiene), lack of endpoint hardening, legacy remote-access/file-transfer pathways, and insufficient traffic monitoring (p.4).
p.4In multiple cases CISA assessors gained full network control within hours or days, showing many SLTT partners remain "soft targets" (p.4).
p.4Most states have moved away from paperless electronic voting machines; in 2020, ImageCast X Ballot Marking Devices printed ballots encoding selections in a barcode voters could not verify, and a researcher showed hackers could change the barcode-encoded votes without physical machine access (p.4).
p.4Citation given: J. Alex Halderman, Security Analysis of Georgia's ImageCast X Ballot Marking Devices, expert report in Curling v. Raffensperger (Civil Action No. 1:17-CV-2989-AT, N.D. Ga.), with Drew Springall, July 1, 2021 (p.4).
p.4ODNI commissioned a forensic examination of Dominion Voting Systems devices used in Puerto Rico's 2024 election; CISA reviewed the report but did not have access to the devices and could not perform its own examination (p.4).
p.4Citation given: Dominion Voting Systems Democracy Suite Preliminary Vulnerability Assessment, Mojave Research for the ODNI, September 25, 2025 (p.4).
p.4Vendor threat models assume strong segmentation between election systems (voter-registration databases, e-pollbooks, election management/tabulation systems, central scanning) and enterprise IT, but 2019-2024 assessments showed election systems reachable from enterprise hosts via shared auth domains, legacy VLANs, or "temporary" exceptions; poor firewall hygiene; co-location on general-purpose virtualization clusters; and unreliable "airgap" assumptions (vendor support tunnels, remote-management tools) (p.5).
p.5CISA recommended mitigations: harmonize patch/certification rules; adhere to CISA Best Practices for Securing Election Systems; use human-readable paper ballots; conduct post-election manual audits of paper ballots before certification (p.5-6).
p.5Additional recommendations: encourage vendors to assign CVE numbers, notify customers if source code is leaked/stolen, report incidents to authorities, include a software bill of materials (SBOM); and ensure transparent documentation of all security incidents and remediation (p.6).
p.6Conclusion: US election-system security issues stem from complex interdependencies between vendors, certifiers, policymakers, and resource-constrained SLTT partners, not any single entity (p.6).
p.6Reporting at the time
External context — third-party coverage published around these events, linked for reference. Separate from the primary documents.
Page evidence
Election Report (CISA) · p.3

Page OCR text
ELECTION REPORT While vendors generally viewed the program as valuable, the model created disincentives for transparent, industry standard vulnerability disclosure. Vendors benefited from private remediation prior to market release, but the downstream ecosystem—SLTT administrators, risk managers, and external researchers—did not receive clear vulnerability histories or patch transparency. The program was therefore retired in 2024 based on stakeholder feedback, and final reporting concluded in 2025. CISA’s analysis of the Critical Product Evaluation reports confirms that election software, like any complex system, contains a spectrum of vulnerabilities, including input validation bugs, insecure deserialization, insufficient logging, race conditions leading to unpredictable results, insecure crypto primitives, and privilege escalation paths. Many vulnerabilities were remediated quickly by vendors before release. However, CISA did not independently validate whether production builds deployed in SLTT environments incorporated all fixes. Constraints on Security Updates SLTT election officials face difficulties in applying security updates to election software in a timely manner. Most SLTT officials have minimal IT budgets and cybersecurity staff. In addition to resource constraints, some election systems are only deployed for limited periods of time in the immediate period surrounding an election. Others are deployed for longer periods but are “locked down” to prevent any changes during the months or weeks leading up to election day. In some cases, these lockdown periods are mandated by state law. Those state laws may also require that SLTT entities only deploy election software that has been certified by the Election Assistance Commission (EAC), which may also delay the application of security updates if an update postdates EAC certification. These jurisdictional differences present a fragmented certification ecosystem to election software vendors. The following technical risks predictably arise from this complex environment: e Vendors often cannot ship security fixes outside narrow certification cycles without jeopardizing eligibility for upcoming elections. e Third-party components embedded in election systems (operating systems [OS], device drivers, middleware, cryptographic libraries) cannot be patched at normal modern software cadence. e Legacy OS baselines and unsupported runtime components accumulate unpatched vulnerabilities. e The absence of secure auto-update mechanisms prevents rapid response to zero-day threats. In practice, these constraints produce environments where known, documented vulnerabilities persist for months or years on production election systems, increasing exposure to opportunistic and targeted threats. The election vendors’ reluctance to publicly disclose vulnerabilities in certified products further limits SLTT operators’ ability to make informed risk decisions, perform compensating control analysis, or adjust architectural segmentation. 3 Px t v cisa.gov Wa central@cisa.dhs.gov X @CISAgov | @CISACyber ‘in) £) @cisagov As of July 13, 2026