The question needs a threat model
When I assess a system’s security, I start with the threats it needs to withstand and the evidence available to evaluate its defenses. I take the same approach to Brazil’s electronic voting machines. A responsible answer must explain what is being protected, from whom, and under what conditions.
The integrity of votes and results, the secrecy of each person’s choice, and the continuity of voting all need protection. We also need ways to verify how the process works. These are distinct goals: a system can remain available while still having a confidentiality weakness. Checking only whether a machine turns on or produces a result leaves part of the problem unexamined.
The scope of the analysis must also be clear. Voting machines, preparation systems, file transmission, and result aggregation perform different functions. A problem at one stage needs investigation based on its potential impact, without automatically assuming that every other stage has been compromised.
Understand safeguards by what they verify
According to Brazil’s Superior Electoral Court, the TSE, voting machines operate in isolation from networks, without internet, Wi-Fi, or Bluetooth connections. This reduces the attack surface for direct remote access to the machine. (TSE — architecture and safeguards)
That is a meaningful safeguard. A security assessment also needs to consider physical access, machine preparation, software components, credentials, and the people authorized to operate the process. The absence of a network connection does not, by itself, resolve all these questions.
The TSE also describes software compilation, the generation of cryptographic hashes, and system signing at its software sealing ceremony, with oversight bodies participating. These records support subsequent integrity and authenticity checks. (TSE — digital signatures and software sealing)
A valid signature helps verify a file’s origin and integrity. That property must be distinguished from the correctness of its logic: an authorized program can still contain a bug. Code review, testing, operational controls, and oversight therefore need to work together.
Tests have demonstrated vulnerabilities
Aranha and colleagues documented arbitrary code execution and compromised security properties in the 2017 Public Security Test, or TPS, environment. Their research was published in 2019. This was a historical demonstration under controlled conditions, not evidence of exploitation in an actual election. (Aranha and colleagues — research on TPS 2017)
The TSE reported fixes and retesting in May 2018. Its account says Aranha’s group made no progress when repeating the previous attacks; it also records differences between the researchers’ proposed solution and the approach adopted to protect the keys. (TSE — confirmation testing and fixes for TPS 2017)
In the final TPS 2025 report, signed in June 2026, the evaluation committee distinguishes a flaw identified in supporting systems, which was not successfully exploited, from the fixes that were verified. It also recommends improving the test environments. (TSE — Evaluation Committee’s final report)
These findings need to be read with their date, version, and scope in mind. An old finding does not establish that the current version retains the same flaw. A validated fix does not establish that every possible attack has been eliminated either. Technical work means identifying the problem, assessing its impact, fixing it, and producing fresh evidence.
Every audit has a scope
The Boletim de Urna, or voting machine results bulletin, reports polling-station totals, allowing comparison with the results published by the TSE. This helps check result aggregation; the bulletin is not an individual receipt for each voter’s choice. (TSE — Boletim de Urna)
The Integrity Test compares test votes previously recorded on paper with the results from selected machines. It assesses their operation using a sample and defined conditions. (TSE — Integrity Test)
Rivest and Wack proposed software independence: an undetected software error or change should not be able to cause an undetectable change in an election’s outcome. It is a design and verifiability criterion, not evidence of fraud. (Rivest and Wack — software independence, 2006)
My view is that each mechanism needs to be assessed against the question it can answer. Checking files, comparing totals, and observing a sample’s behavior produce different kinds of evidence. A serious assessment must explain how they complement one another and which hypotheses still require other checks.
Vulnerability, exploitation, and fraud are different conclusions
An attack hypothesis describes something that could happen under certain conditions. A demonstrated vulnerability establishes a concrete weakness. Reproduced exploitation shows that this weakness enabled improper behavior in the scenario tested. Each step adds evidence, but we still need to establish whether the same scenario occurred outside the test.
Concluding that election fraud occurred requires specific evidence of manipulation in the actual process, with verifiable provenance, context, and an assessment of its impact. A flaw alone does not establish who used it, when it happened, or which votes were affected. A video without context or a suspicion does not fill those gaps either.
The same rigor applies in both directions. Finding a vulnerability calls for investigation and a fix. Not finding a flaw in a particular test strengthens the assessment within that scope, but does not make the system infallible. The language used to communicate the result must respect that limit.
Trust requires evidence and room for questions
Questioning a system’s security is part of cybersecurity work. Those questions become useful when they identify a threat, present a method, and allow others to examine the results. Accessible documentation, oversight, and independent research help build that trust.
That is the approach I consider necessary when discussing Brazil’s voting machines: recognize existing safeguards, examine documented vulnerabilities, and demand clarity about the limits of verification. Security needs support from evidence that people can discuss and improve upon.
A vulnerability can be serious without constituting evidence of fraud. A safeguard can matter without providing an absolute guarantee. Understanding that distinction improves technical debate and the quality of decisions.