FBI and CISA issued a warning on 16 October 2026 about cyber threats targeting election and campaign officials in the United States, including phishing messages that AI could make more convincing. The practical message is that polished writing, or even a familiar voice, is not enough to authorise sharing information or signing into an account. Sensitive requests need checking through a separate channel.
The warning comes ahead of the US midterm elections, but it does not announce a new breach of a voting system. Nor does it present evidence that election results have been changed. That distinction matters: stealing a campaign worker's account, exposing an internal document and compromising election infrastructure are different events, with different consequences and evidential requirements.
What the agencies warn could happen
According to the joint notice, malicious actors may use email and text phishing to obtain credentials and sensitive information. Election officials, candidates and political organisations are attractive because of their access to information and officeholders. The agencies also describe fake audio and visual content reinforcing impersonation, and recommend phishing-resistant multi-factor authentication and checking requests through another channel.
The document supplies no success rate comparing AI-written messages with conventional ones, and identifies no particular attack campaign underpinning such a comparison. The warning therefore cannot be turned into a figure for the damage caused, or a conclusion that every suspicious message was generated by a model. Protecting accounts remains sensible even when the sender's tools are unknown.
The publication uses SI, literally super intelligence, to describe generation and automation capabilities. The term is not accompanied by a demonstration that such a system exists or is involved in an incident. Understanding the risk requires no assumption of extraordinary capabilities: a credible-looking message asking someone to do something they would otherwise refuse is enough.
Why good writing is no longer an authenticity test
When assessing a message, spelling and tone are easy to focus on. They are convenient clues, but the important decision concerns something else: what am I being asked to do, who is authorised to request it, and does the route through which it arrived fit our procedure? Fluent prose answers none of those questions. A familiar sender name does not replace identity verification either.
For example, an urgent request to review a document may be ordinary work. If it requires signing in through a new link, it is better to open the service using the usual bookmark and look for the document there. If it is missing, check with the relevant person using a known number or channel. This is an example of recommended practice, not an attack identified in the notice.
The same principle applies when someone sounding like a colleague asks for a file. There is no need to decide in real time whether the voice was computer-generated. Pause the action and ask for confirmation through the agreed work channel. The decision then rests on a verifiable process rather than confidence inspired by a familiar voice or writing style.
Phishing-resistant authentication means more than another code
NIST's digital identity guidelines say codes entered manually by the user do not qualify as phishing-resistant authentication. The reason is that the code is not necessarily bound to the particular connection or intended service. WebAuthn, used by FIDO2, can instead bind authentication to the service name. The distinction lies in the mechanism, not the number of steps the user sees.
That suggests a useful question for administrators: which authentication method is actually enabled on sensitive accounts? A generic multi-factor authentication checkbox does not answer it. Ask the service provider which phishing-resistant options are available, which users have them enabled and what happens when an employee loses a device or requests account recovery.
Deploying strong authentication also needs human planning. A temporary worker must know how to sign in safely on the first day and whom to contact when something fails. An awkward or unclear official access route creates pressure to find a shortcut. Test enrolment and support procedures in advance, not just the standard login screen.
What a small team can change this week
A recommended first step is to define which requests must never be approved on the strength of a single message. Examples include changing permissions, transferring a contact list or resetting administrative access. Assign an identified approver and a known verification channel to each action. The rule should be short enough for a busy employee to remember under pressure.
Next, check whether reporting a suspicious message is straightforward. An address or reporting button helps only if someone handles submissions and responds. Explain what employees should do while waiting, such as avoiding another attachment or withholding details, without stopping all work or circulating the message to additional groups.
Also rehearse a brief scenario: an urgent request apparently from a manager, while the usual approver is unavailable. The exercise is not about catching an employee out. It should establish whether a safe alternative exists and whether the team knows it. A process that works only when everyone is available and confident will not cover the moment an unusual request arrives.
What to do if information has already been shared
If an employee entered a password or approved a suspicious request, the practical recommendation is to contact security or support immediately through the known channel and describe exactly what happened. Distinguish opening a message, downloading a file, entering a password and approving a login. These details help the responder decide what to investigate without asking the employee to diagnose the incident.
Keep the message and the time of the incident, and follow the response team's instructions on changing credentials and checking account activity. There is no need to keep talking to the sender to prove impersonation. Employees should understand that prompt reporting is better than waiting for certainty that damage occurred, and that making a mistake is no reason to conceal it.
For an Israeli organisation, the US warning is a reason to examine working procedures, not evidence that it has been attacked or faces the same targeted threat. The useful question is whether a credible-looking request can bypass the rules. If so, start with a small, measurable improvement: one sensitive request, one verification channel and a clearly responsible person who checks that the process works.