The finance review is nearly over when a familiar executive joins late. The camera image looks ordinary. The voice sounds right. Then the executive asks the controller to approve an unusual transfer before the call ends.
A warning appears: this participant may be impersonating someone.
What should the room do next?
“Trust the warning” is too simple. Detection systems can be wrong. “Ignore it until security investigates” is worse because the consequential request is happening now. The useful response sits between those extremes: pause the transaction, verify through a channel the meeting did not supply, and resume only after the person, request, and authority all check out.
That response is becoming a real workplace requirement. Microsoft added two relevant Teams features to its October 2026 roadmap. One would let certified third-party providers analyze meeting audio and video for synthetic or manipulated media, then send detection signals into Teams. The other would surface risk indicators for potentially deceptive meeting organizers and participants. Both synthetic-media detection, roadmap item 573451 and meeting impersonation protection, roadmap item 573157 were listed as in development with November 2026 targets at the time of writing. Roadmap dates can move, and the first feature depends on third-party detection rather than Teams performing the analysis itself.
The important shift is not that software will settle identity. It is that more people will encounter a warning in the middle of a live conversation and need a humane, reliable way to respond.
A warning is a trigger, not a verdict
When a risk indicator appears, the room does not yet know what happened. The participant may be fraudulent. A legitimate guest may have used an unexpected account. A detection service may have misread poor audio, aggressive noise suppression, a virtual background, or another technical artifact.
Treat the warning as a trigger for a process. Do not turn the call into a public trial, and do not ask the flagged person to prove their innocence by improvising personal details on camera. That creates pressure, exposes more information, and still leaves the room judging evidence supplied inside the potentially compromised channel.
Microsoft’s current guidance for suspicious external calls follows the same basic logic: review the warning, avoid sharing sensitive information, and verify the caller through a trusted communication channel when necessary. The meeting version needs a little more structure because several people may be present and work may already be in motion.
Use a five-step pause-and-verify protocol.
1. Name the pause without naming a culprit
The host or decision owner should use a neutral phrase that the team has agreed in advance:
We have an identity signal that requires verification. We are pausing approvals and sensitive sharing while we check it through our normal channel.
That sentence does three useful things. It tells everyone what changed, stops consequential work, and avoids declaring that a participant is fake before anyone has verified the signal.
During the pause, stop screen sharing if confidential material is visible. Do not send files, reveal credentials, approve payments, change access, or repeat private information. Ordinary conversation can wait too. A short clean pause is easier to manage than a half-paused meeting where the sensitive request keeps advancing through chat.
2. Separate identity, request, and authority
Teams often compress three different questions into one: “Is this really Maya?” A secure response asks all three.
Identity: Is the participant the person they claim to be?
Request: Did that person actually make this specific request, with these exact terms?
Authority: Are they permitted to authorize it alone, through this process, at this time?
Each can fail independently. A real executive’s account may be compromised. A legitimate participant may repeat a request that was altered in transit. The right person may be asking for something that still requires a second approver or a ticket in a controlled system.
This is why successful facial or voice recognition should never become a substitute for approval controls. Identity is relevant evidence, not universal permission.
3. Verify outside the meeting’s path
Choose a verifier who is not the person being asked to take the sensitive action. That verifier should contact the claimed participant through a method already trusted by the organization: a known phone number in the company directory, an established internal account, or an in-person colleague.
Do not use a phone number, link, email address, or contact card newly posted in the meeting. If the meeting invitation, participant account, or chat is deceptive, information supplied there belongs to the same untrusted path.
The callback should be specific:
Are you currently in the supplier review, and did you ask Lina to release $18,400 to the new account ending in 4621 today?
Avoid vague checks such as “Is that you?” The verifier needs confirmation of both presence and request. They should not ask for passwords, one-time codes, or personal trivia. If the organization has a formal verification method, follow it. If not, a callback to a known number plus the normal approval workflow is stronger than an improvised challenge on the suspicious call.
NIST’s digital identity guidance offers a useful broader principle. For remote identity proofing, automated analysis should be augmented by human review because systems can produce both false positives and false negatives. It also recommends protected channels and, in some cases, unpredictable human-in-the-loop cues. A routine workplace meeting is not a formal identity-proofing session, but the lesson transfers: one detector should not be the entire decision process.
4. Record the outcome, not the drama
Leave a compact audit line in the meeting record or the organization’s incident system:
- when the pause began;
- which request or disclosure was stopped;
- who performed verification and through which established channel;
- whether identity, request, and authority were confirmed;
- what happened next.
Keep speculation out. “Possible deepfake of CFO” is a damaging conclusion if the alert was caused by a guest account or poor connection. “Identity signal appeared; payment approval paused; callback to directory number confirmed person but not request; escalated to security” is precise and useful.
The note should not reproduce passwords, authentication codes, bank details, or other sensitive material. The purpose is to preserve the decision trail, not build a second copy of the risk.
5. Resume deliberately, or end cleanly
If all three checks pass, the host should state that verification is complete and identify exactly what may resume. The original approval rules still apply.
If any check fails, or verification is unavailable, end the sensitive part of the meeting. Preserve the relevant invitation and platform records according to company policy, report the event through the established security route, and contact affected people through known channels. Do not keep the suspicious participant engaged while the team improvises an investigation in public.
A false positive also deserves a clean ending. Tell the room that the participant was verified, avoid jokes about their voice or appearance, and report the mistaken signal through the product or internal process if one exists. A security control that embarrasses legitimate colleagues will soon be bypassed.
Prepare before the red banner appears
The protocol works only if the team can execute it under pressure. Add four decisions to meeting policy before a warning arrives:
- Define protected actions, such as payments, credential sharing, access changes, release approvals, and disclosure of regulated data.
- Name a verification owner and backup for meetings where those actions can occur.
- Maintain trusted contact routes outside the meeting platform.
- Rehearse one five-minute scenario, including a false positive.
This is less about spotting visual glitches than protecting the point where conversation becomes consequence. Attackers benefit when urgency collapses identity, request, and authority into a single impression. Good teams pull them apart again.
Meeting copilots can help preserve that discipline when their role is clear. Caspi provides live recap, suggested questions, contextual chat, proactive flags from connected tools, post-call action items, and persistent meeting memory. Used with an organization’s security process, that shared record can keep the pause, verification owner, and final decision visible instead of leaving them buried in a tense moment.