Election Technology Insider Threats: 6 Controls to Test
Election Technology Insider Threats: 6 Controls to Test
An online election can be damaged by someone outside the system, but so can an authorized person. The defense is not suspicion; it is a pre-set process that limits sensitive access and leaves a credible record if questions arise.
This six-control review helps election administrators test insider-risk safeguards before ballots open. It covers employees, temporary workers, contractors, and vendor personnel while keeping the boundary between voter identity and ballot choice intact.
Look Beyond the Obvious Cyberattack
Insider risk begins with authorized access or useful system knowledge. It can be deliberate, such as a person trying to alter a file or export sensitive data. More often, it is ordinary error: a rushed administrator shares a login, a contractor keeps access after a project ends, or a support worker opens a record outside the job.
That distinction matters in an online election. The same person should not upload a voter list, revise a ballot, clear an exception, and certify results without review. Combined, these legitimate actions can leave an election file unable to answer a later question.
In October 2026, a joint CISA, FBI, DHS I&A, and EAC advisory described unintentional, intentional, collusive, and third-party insider threats to election systems. The guidance is written for U.S. election infrastructure, not as a new rule for private member elections. Its operating principles still translate well: least-privilege access, documented procedures, dual control for sensitive work, and records that make unusual activity reviewable.
The Six-Control Pre-Launch Review
Run this review after your ballot and voter file are nearly final, then save it with the election record. It should be specific enough to expose a weak handoff and short enough that people will use it.
- Name every privileged user. List everyone who can enter the election workspace, including administrators, support personnel, implementation specialists, and vendor staff. Each person needs an individual account; shared accounts leave an avoidable evidence gap.
- Limit access to the task. A voter-data steward may correct an approved eligibility record, but does not also need ballot-editing or result-certification rights. Match each role to its narrowest useful permission set.
- Require an independent check for material actions. Use two named people for a live-ballot change, voter-file replacement, deadline extension, result export, or administrator-permission change. One executes the approved task; the other verifies the source and outcome.
- Control vendor and contractor sessions. Give external personnel separate, time-limited accounts. If remote support is necessary during voting, define the allowed action, approving contact, support window, and log that records the session.
- Test offboarding before the election opens. Disable a test account and confirm that access ends across the platform, related storage, and connected data tools. Do not wait for a real departure to find an active credential.
- Review the evidence, not just the settings. Confirm that you can retrieve approval records, administrator activity, support exceptions, and configuration changes without exposing ballot selections. A reasonable reviewer should be able to follow what happened after close.
These controls build on the role design used in a disciplined election operations plan. They also make a useful procurement question: can the platform show how access was granted, used, changed, and removed?
Give Vendor Access Its Own Set of Rules
A vendor is not automatically a risk, and a contract does not remove the need for oversight. The October advisory recommends holding vendors and contractors to the same security standards as employees, restricting them to the data and systems required for the service, and using separate accounts. That is a sensible baseline for a managed online election.
| Access situation | Control to test | Evidence to keep |
|---|---|---|
| Implementation support | Named account, defined setup scope, and approval for configuration changes | Role map, request, approval, and activity log |
| Live-election support | Time-limited access with a known escalation contact and documented session purpose | Support ticket, access window, and resolution note |
| Result or data export | Second-person review before release and a clear recipient list | Export record, reviewer name, and delivery confirmation |
| Contract end or staff change | Prompt account removal and confirmation that no shared credentials remain | Offboarding checklist and access-revocation record |
Ask the vendor to explain the controls in plain language before the election calendar becomes tight. A capable online voting platform keeps operational support separate from authority to make outcome-sensitive changes, with exceptions recorded.
Detect and Respond Without Breaking Ballot Secrecy
Detection is a reason to watch the right records, not collect more information than the election needs. Look for unexpected privilege changes, repeated failed administrator sign-ins, unusual exports, access outside the agreed support window, or a configuration action without its matching approval. A late-night login may be expected during a planned launch; it should still be easy to explain.
When something looks wrong, preserve the facts before making a broad change. Record the time, account, affected component, access logs, and related ticket or approval. Restrict the account if necessary, involve the authority named in your election plan, and use counsel or incident-response resources when the situation calls for them. Do not search ballot choices to diagnose a system issue.
Practice one scenario before voting begins. For example, walk through a contractor account that appears after its support window has ended. Who verifies the account status? Who can suspend it? Who tells the election owner? CISA's insider-threat guidance frames this work as a cycle to define, detect, assess, and manage risk. A short rehearsal exposes vague responsibilities before they become a live-election problem.
Frequently Asked Questions
What counts as an insider threat in an online election?
An insider is a person with authorized access or useful system knowledge, including employees, volunteers, contractors, and vendor personnel. The risk can be intentional or accidental; the plan should limit its effect and support a fair review.
Do small elections need a two-person rule?
Not every task needs two people. Reserve independent review for actions that could affect eligibility, ballot content, voting time, administrator permissions, results, or sensitive exports. Two named people can review high-risk work without building a large compliance process.
Can a vendor support an election without broad administrator access?
Yes. Support can be structured around a defined request, scoped permissions, a temporary access window, and an activity record. Before launch, ask which actions require access, who authorizes them, and how the session will appear in the election file.
How do we investigate suspicious activity without revealing votes?
Begin with account, configuration, access, and support records rather than ballot selections. Establish who accessed a component, when, and what administrative action occurred. Maintain the separation between voter identity and ballot choice throughout the review.
The Bottom Line
Insider-risk controls are not built on distrust. They are practical guardrails that let election teams make legitimate corrections, use outside support, and answer hard questions without relying on memory. Name the people with access, narrow their permissions, require a second check for meaningful actions, and preserve the record.
If you are setting up an online election and want to test vendor access, approval paths, and audit evidence before the ballot goes live, talk with Votem's election team. A short controls review now is easier than reconstructing a sensitive decision after voting has begun.