Election security: protect voter data, operations and evidence.

The security objective is an election that can be explained and verified

An election depends on more than the equipment used to cast or count a ballot. Staff identities, email, voter records, suppliers, public websites, physical custody and the publication of results all create different security obligations. A failure in one area can disrupt another without proving that every area has been compromised.

This is a research analysis of election-enterprise security, reviewed on 5 October 2026. It is not a report of a newly discovered election breach. We use a documented UK incident and US technical guidance to develop an operational model for SOC teams, election administrators and suppliers. Recommendations and diagrams are SecOpsNomad’s analysis; they are not a certification of any election or a statement that US procedures apply in Japan.

The central question is: if an identity, service or supplier fails, can you keep authorized operations running and independently establish what changed? NIST’s final February 2024 Election Infrastructure Profile treats voting equipment and supporting information systems together and offers a voluntary risk-management approach, supplementing existing standards. NIST profile

1. Map the enterprise before choosing controls

Build an inventory around functions, owners and trust boundaries. Record which system is authoritative for each decision, who can change it, what logs survive its compromise and what fallback the responsible election authority has approved. The following is a reference model, not a diagram of a particular jurisdiction.

Figure 1. Original reference model. Connections and separation must be verified locally; these are not six universally isolated networks.

Surface	Failure to investigate	Evidence needed before drawing conclusions
Identity and staff email	Stolen sessions, unauthorized MFA recovery, malicious application grants or impersonation	Identity-provider, mailbox and application audit; verified staff interview; session containment results
Registration and voter data	Bulk extraction, unauthorized edits or loss of access	Authoritative record owner, transaction history, access logs and independently retained exports
Voting and counting	Unauthorized software, configuration, input or equipment changes	Approved configuration, equipment custody, test records and the jurisdiction’s authorized verification process
Websites and results publication	DDoS, DNS takeover, altered files or false instructions	DNS/registrar and CMS audit, edge/origin health, deployment history and comparison to authoritative records
Suppliers and administration	Misused remote access, update channels or shared administrator accounts	Supplier identity, session recording where available, approved job, software provenance and contractual escalation route
Physical evidence and continuity	Missing equipment, broken custody records, inaccessible facilities or unusable backups	Inventory, custody transfers, access records, recovery tests and authorized fallback arrangements

Campaign organizations are a separate trust domain. A campaign mailbox compromise can expose sensitive information and enable impersonation, but its relationship to election-administration systems must be demonstrated. Do not silently merge party IT, municipal IT and voting infrastructure in an incident dashboard.

2. A case study: the UK Electoral Commission breach

The Commission says its systems were first accessed in August 2021 and suspicious activity was identified in October 2022. Its email/file-sharing environment and copies of electoral registers were accessible. It states that the live registers maintained by local electoral registration officers were unaffected and that the incident did not change voting or participation. These are the Commission’s reported findings. Commission account

The ICO’s enforcement record describes initial access through unpatched vulnerabilities, access between 24 August 2021 and 27 October 2022, and approximately 40 million affected individuals. That is a personal-data exposure figure, not a count of altered ballots. ICO enforcement record

The NCSC subsequently attributed the Commission compromise to a China state-affiliated actor and assessed email/register exfiltration as highly likely. Its statement describes APT31 targeting parliamentarians as a separate activity; it does not identify APT31 as the Commission attacker. Attribution must retain that distinction and confidence language. NCSC statement

Our analysis: three controls deserve attention even when ballot systems are unaffected. First, exposed business systems can hold politically sensitive data. Second, copies and historical exports need owners, retention decisions and monitoring. Third, investigating only the voting platform misses compromises in the supporting enterprise. A patching dashboard should identify externally reachable assets and exceptions, while incident scoping should follow actual access paths into mail, files and downstream applications.

This case does not establish the security of another jurisdiction. It demonstrates why privacy impact, operational impact and outcome integrity must be assessed separately.

3. Threat paths and their implications for security posture

The scenarios below are analytical hypotheses for defensive planning. They are not claims that all these activities occurred in the UK incident.

Threat path	Posture question	Useful detection and control evidence
Targeted phishing or help-desk impersonation	Can one convincing message or recovery call obtain privileged access?	Phishing-resistant MFA where supported; independently verified recovery; email, sign-in and MFA-change correlation
Stolen session or app consent	Can an attacker retain access after a password reset?	Token/session response, app-grant review and resource-specific session termination; verify access actually stops
Exposed server or unmanaged appliance	Is patch status tied to exposure, owner and compensating controls?	Asset discovery, vendor advisories, approved change records, server telemetry and post-remediation checks
Supplier or insider misuse	Can one operator change a sensitive asset without independent review?	Named temporary access, separate approval, limited reach, immutable audit copies and emergency-access review
Ransomware or destructive activity	Can a business-network incident disable required election services or evidence?	Tested separation, endpoint coverage where supported, isolated backups and recovery dependencies
DDoS or publication-system compromise	Can people obtain authentic information during an outage?	Edge/origin telemetry, protected registrar/CMS access, independent content comparison and tested alternate channels
Fabricated audio, video or documents	Can an unverified instruction trigger a real operational change?	Known contact routes, a second approver, preservation of the original artifact and comparison with authoritative records

Prioritize shared administration. A public website and a records system can be on different networks yet still depend on the same administrator, recovery mailbox, remote-management service or backup credentials. Document these shared dependencies before treating segmentation as effective.

Treat election-specific equipment differently from ordinary office PCs. Do not install agents, run active scans or change configuration on certified or operational equipment without the owner’s approval and applicable testing/change procedures. Use the monitoring methods the environment actually supports.

4. Availability, data exposure and outcome integrity need different proof

The FBI/CISA’s July 2024 DDoS advisory distinguishes disruption of public information services from compromise of voting integrity. It discusses voter information, online services and unofficial reporting becoming unavailable. Its conclusions are scoped to the described US election context; they do not rule out a separate intrusion occurring at the same time. FBI/CISA advisory

For a website outage, establish whether traffic volume, an origin failure, DNS changes or unauthorized publishing caused the symptom. Preserve control-plane logs while restoring availability. A working homepage proves reachability; it does not establish the authenticity of every published file or the absence of stolen credentials.

For suspected manipulation, compare public material with an independently controlled authoritative source. Record versions, timestamps, approvals and custody. A hash is useful only if the expected hash comes from a trusted, protected reference; comparing two attacker-controlled copies proves little.

The EAC explains that US election-night figures are unofficial and that subsequent canvassing and certification have distinct roles. Do not label ordinary updates to preliminary totals as tampering. Conversely, an unexplained change still needs investigation against the expected publication process. EAC results guidance

Physical evidence matters. EAC guidance connects custody records to authentication of election results and post-election audits. Its audit material describes statistical risk-limiting audits as a specific method, not a synonym for checking server logs. The permitted audit method, records, authority and timing are jurisdiction-dependent. Custody guidance, audit reference

Do not collect voters’ selections in SOC logs or link an individual’s identity to a secret ballot for troubleshooting. Keep investigation data minimized and access-controlled. Technical telemetry supports an investigation; it does not replace election-law procedures or independent outcome verification.

5. AI changes verification work, not the need for evidence

CISA’s January 2024 generative-AI assessment described amplification of existing risks, including synthetic media and social engineering. It was an assessment for the 2024 cycle, not a measurement of attacks in 2026. CISA assessment

Our operational recommendation is to make sensitive instructions verifiable regardless of how authentic they sound. Require a known callback route and separate approval for access recovery, publication changes and supplier interventions. Preserve the original message, URL, delivery time and sender context. A screenshot can show what someone saw, but usually cannot establish provenance alone.

Do not make an AI-detector score the authority for declaring content authentic or fabricated. Communications staff should state what has been verified, where the official information is available and when the next update will appear. Avoid amplifying an unsupported claim merely to deny it. This is incident communication for everyone, not political persuasion.

If an LLM assists analysis, use an approved isolated workflow: redact sensitive data, treat submitted content as hostile, give the model no administrative credentials or publishing authority, and require human evidence review. Do not upload voter files or incident evidence to public AI services.

6. Which teams should act?

Team	Priority action	Evidence of readiness
Election authority / incident lead	Define operational decisions, permitted fallbacks and restoration authority	Named decision makers, delegation and exercised escalation routes
IAM and service desk	Protect privileged identities and independently verify recovery	MFA coverage, emergency-account checks and tested session revocation
Email Security	Trace lures, mailbox delegation and unauthorized forwarding	Message IDs, recipient scope, preserved originals and verified removal
SOC / SIEM	Join identity, endpoint, network and application events	Synchronized time, known retention, collection-health alerts and scoped investigation access
EDR / DFIR	Assess supported hosts; preserve evidence before destructive changes	Process timeline, isolation results, collection record and trusted recovery image
Network / IT Operations	Protect availability and separate administration	DDoS runbook, tested fallback connectivity, DNS ownership and restore results
Application and supplier owners	Verify sensitive changes and restrict support access	Approval record, asset/version baseline, session history and contractual contacts
Legal / Privacy	Assess affected data, preservation and applicable reporting duties	Jurisdiction-specific assessment; no assumption that one country's deadline applies everywhere
Communications / accessibility staff	Maintain verified, usable public instructions	Alternate channel, approved wording, accessible formats and regular factual updates

For a suspected stolen identity, follow the account-compromise playbook. Use the phishing and ransomware guides when the evidence supports those workstreams. Parallel investigations should share one incident timeline and decision log.

7. Hunting examples: scoped triage, not election-fraud detection

There is no campaign-specific IOC set in this analysis. We have not invented IPs, domains or hashes. The following read-only examples investigate activity in your own authorized environment; they cannot establish whether votes were changed.

Both KQL examples target Microsoft Sentinel / Azure Monitor Log Analytics, not Defender XDR Advanced Hunting. Enable the required Entra diagnostic exports, confirm retention and workspace read permissions, replace placeholders with exact reviewed identifiers and inspect query cost before expanding scope. Use smaller windows on busy systems. A 500-row output limit does not limit the amount of data scanned; split the time window if it fills. Preserve complete relevant records separately.

A. Review one election-support identity's interactive sign-ins

Requires SigninLogs. Returns successes and failures for one user in the last 24 hours, including application and device context. In this table, ResultType of 0 indicates success. Compare records with approved activity; travel, VPNs and new devices can be legitimate. Non-interactive token use, workload identities and application-local sessions require separate sources. A quiet result is not evidence of safety. Microsoft schema

Download: election-identity-review.kql

// Microsoft Sentinel / Log Analytics. Read-only; not live-tested.
let TargetUserId = "REPLACE_WITH_ENTRA_USER_OBJECT_ID";
SigninLogs
| where TimeGenerated between (ago(24h) .. now())
| where UserId =~ TargetUserId
| project TimeGenerated, CreatedDateTime, UserId, UserPrincipalName,
    IPAddress, AppDisplayName, ResultType, ConditionalAccessStatus, DeviceDetail
| order by TimeGenerated asc
| take 500

B. Review directory changes initiated by or targeting one identity

Requires AuditLogs and its InitiatedBy, TargetResources, Id, OperationName, Result and time fields. The query retains full actor and target objects for review and deduplicates expanded targets by event ID. Inspect the operation and result against approved changes; onboarding and scheduled administration are common benign explanations. This does not cover mailbox rules, all SaaS administration or changes made by unrelated application identities. Microsoft schema

Download: election-directory-review.kql

// Microsoft Sentinel / Log Analytics. Read-only; not live-tested.
// Return events initiated by the user OR naming the user as a target.
let TargetUserId = "REPLACE_WITH_ENTRA_USER_OBJECT_ID";
AuditLogs
| where TimeGenerated between (ago(24h) .. now())
| extend ActorId = tostring(InitiatedBy.user.id),
    Targets = iff(coalesce(array_length(TargetResources), 0) == 0, dynamic([{}]), TargetResources)
| mv-expand Target = Targets
| extend TargetId = tostring(Target.id)
| where ActorId =~ TargetUserId or TargetId =~ TargetUserId
| summarize arg_max(TimeGenerated, *) by Id
| project TimeGenerated, Id, OperationName, Result, InitiatedBy,
    TargetResources, CorrelationId
| order by TimeGenerated asc
| take 500

C. Review changes to one public-information application in Splunk

This is a custom application-audit template, not a built-in Splunk detection or vendor sourcetype. Map _time, app_id, actor_id, action, object_id, result, src, change_id and event_id from your CMS/deployment/registrar logs. Normalize action to publish, update, delete or permission_change before using the filter. Missing mappings can silently miss events. Restrict the index, sourcetype and application; require authorized search access and retained audit data. The expected output is a review queue, including legitimate releases and failed operations. Compare it to independently approved changes and the original record. Splunk filtering semantics

Download: election-publication-review.spl

index="REPLACE_WITH_AUDIT_INDEX" sourcetype="REPLACE_WITH_AUDIT_SOURCETYPE" earliest=-24h latest=now
| where app_id="REPLACE_WITH_EXACT_APP_ID"
| where action IN ("publish", "update", "delete", "permission_change")
| sort 500 + _time
| table _time app_id actor_id action object_id result src change_id event_id

Execution status: documentation/schema review only, 5 October 2026. None of these queries has been executed in a live tenant. English and Japanese code blocks and downloads are identical.

8. Respond according to the evidence you have

Figure 2. Original decision map. Multiple branches can be active. Unknowns remain assigned investigation tasks.

Decision	If yes	If no or unknown
Is a required public service unavailable?	Activate the approved availability plan; assess origin, DNS and provider status; publish verified alternate instructions	Check user reports and monitoring coverage; do not treat one successful probe as universal availability
Is there credible unauthorized identity or admin activity?	Contain the implicated access, preserve logs and verify revocation at each relevant application	Investigate session, device and telemetry gaps; retain a named owner and review time
Is a record, configuration, published result or evidence item unexplained?	Preserve versions and custody; involve the authoritative owner and election lead; follow approved reconciliation procedures	Document exactly what was compared and which evidence is unavailable; do not infer complete integrity from no alert
Is a public instruction or media artifact disputed?	Verify through a known channel, retain the original and issue a factual correction through the designated authority	Continue authentication checks without presenting the claim as established fact

Restore only after verifying the entry path is addressed, unauthorized access is removed, required data/configuration is reconciled and the responsible authority accepts remaining uncertainty. Use trusted administration and tested backups; separate service restoration from the later decision that the incident is closed. Record who authorized each step and the evidence that supported it.

9. A practical readiness plan, including Japan

This planning sequence is our recommendation, not a statutory timetable. Adjust it to the election calendar and available change windows.

• Before the high-risk period: map the six surfaces and shared administrators; verify exposure and patch exceptions; remove obsolete access; test logging and protected backup restoration; agree supplier contacts and evidence access.
• Before the operational change freeze: rehearse a combined mailbox compromise and website outage. Verify alternate communications, accessibility, emergency approval and the authority to use each fallback. Freeze should not mean ignoring an urgent security issue: define an accountable exception process.
• During operations: monitor critical service health, unauthorized changes, data access and collection gaps. Staff the escalation route. Keep a single timeline, regularly verify the trusted publication channel and preserve records under the applicable retention rules.
• After operations: reconcile outstanding exceptions and evidence, review restoration decisions, revoke temporary access and assign corrective actions with deadlines. Do not delete records merely because an event or contract ended.

For Japanese organizations, map these functions to the actual election administration, municipal IT, contractors and other responsible bodies. Do not assume the presence of US-style e-pollbooks, ballot scanners or risk-limiting audits. Identify the local system of record, governing procedures and reporting routes before adopting a control. Paper-based processes still require protection of their supporting IT and physical records; the actual dependencies must be inventoried.

Japan’s NCO publishes a general security-awareness handbook; it is a supporting reference for staff education, not an election-equipment certification or a substitute for the responsible authority’s procedures. NCO handbook

Measure readiness through evidence: privileged accounts with tested recovery, exposed assets with accountable remediation, log sources with verified continuity, restoration tests that meet an owner-approved time objective, and sensitive changes linked to independent approval. Set targets locally; no universal percentage proves an election secure.

Limits, sources and revision history

This analysis uses public reports and guidance, not access to an election network, voting equipment or confidential evidence. It cannot estimate the probability of an attack in a particular jurisdiction, attribute an unobserved incident, or certify an outcome. The UK findings and the US advisories retain their dates and scope. The threat matrix, diagrams, team assignments, queries and readiness sequence are original analytical recommendations.

Primary sources are linked next to the claims they support. Product schemas and guidance were checked on 5 October 2026. No real voter data, credentials or incident telemetry is included. Review local architecture, law, product behavior and evidence availability before operational use.

5 October 2026 — First publication. English and Japanese editions, original security-boundary and response diagrams, and three matching query downloads.