We Need a Better Way to Verify Who Is in a Zoom Meeting | Community
Skip to main content
ExpertswhoJohn
Community Super Champion | Customer
Community Super Champion | Customer
September 14, 2026

We Need a Better Way to Verify Who Is in a Zoom Meeting

  • September 14, 2026
  • 2 replies
  • 39 views

After extensive research across the Zoom Apps SDK, Meeting SDK, Plugin SDK, REST API, and webhooks, I cannot find a reliable way for a host or authorised application to match a participant in a meeting or webinar to their verified identity.

Full disclosure: I have found one way to do this in my events, but it would not work for most people.

We can see a participant’s screen name, but that name can be changed and easily copied. We may receive meeting-specific participant identifiers, but these generally identify a connection or session—not necessarily the person’s Zoom account or the approved registrant we expected to attend.

There is an API that can request a participant’s email address, but this requires consent during the meeting and can feel intrusive. It also does not provide a dependable method of verifying someone before admitting them from the Waiting Room.

I completely understand why privacy is central to Zoom’s approach. Participants should not have personal information exposed to hosts, developers or other attendees without a clear and legitimate reason.

However, privacy and identity assurance should not be treated as opposites.

If I organise a private meeting or webinar with approved registrants, I should be able to confirm that the person joining is the approved person—or at least that they are signed into the Zoom account associated with the approved registration.

That does not mean displaying their email address. Zoom could provide a simple, privacy-preserving status such as:

* Identity verified
* Matches approved registration
* Signed in, but does not match the registration
* Guest or identity not verified

If additional consent is required, the participant could be shown a clear option:

> “This meeting requires Zoom to confirm that your signed-in account matches your approved registration. Your email address will not be shared with the host.”

The host and authorised applications would receive the verification result, not the participant’s private account information.

This matters because the current limitation holds back the development of safer and more useful in-meeting applications.

Applications cannot reliably connect an approved customer, member, student, patient, speaker or employee with the participant visible inside the meeting. This makes it harder to provide personalised experiences, apply permissions, manage access, record attendance or protect restricted conversations.

More importantly, this is a security issue.

In many meetings, knowing that participants are who they claim to be provides protection against:

* People using false or copied screen names

* Uninvited attendees using forwarded links

* People impersonating colleagues, speakers or customers

* Spammers repeatedly rejoining under different names

* Unauthorised access to private or sensitive discussions

A screen name is not an identity.

The Waiting Room is an excellent access-control tool, but the host still needs trustworthy information on which to base the admission decision. A list of editable names does not provide that assurance.

I therefore believe Zoom needs an optional **Verified Participant Identity** framework across Meetings and Webinars.

It should:

1. Be enabled by the host when scheduling an appropriate meeting.

2. Clearly notify participants that verification is required.

3. Match the signed-in Zoom account with the approved registration or invitation.

4. Return a simple verification result without unnecessarily exposing an email address.

5. Provide a stable, privacy-preserving identifier to authorised SDKs and applications.

6. Continue to support anonymous meetings when identity verification is not required.

7. Give organisations appropriate administrative controls and audit information.

This is more than a request for another SDK method. It requires a change in how we think about identity inside online meetings.

Anonymous and open meetings should remain available. However, hosts running private, professional or security-sensitive meetings should also have the option to know that the person they are admitting is the person they expected.

Almost everyone I have discussed this with agrees that an optional, transparent and privacy-preserving identity-verification system would be valuable.

I am surprised that I do not hear more requests for it.

So I am going to start lobbying for this until we find a workable solution—one that protects participant privacy while also giving hosts and developers the assurance necessary to build safer and more capable meeting experiences.

What do you think?

Would you enable verified participant identity for some of your meetings, provided participants were informed and their email address was not exposed?

All the best,

John Drinkwater
Lord Zoom

PS I have shred this on Linkedin to et real documented reactions

2 replies

newl
Education Ambassador
Education Ambassador
September 15, 2026

HI ​@ExpertswhoJohn ,

I appreciate my privacy and your post got me thinking about how Zoom might provide users better privacy while enhancing security in the process. 

I’ve have been looking into the issue you have raised and done a bit of research (AI & Google-Fu) as well as having a few conversations with colleagues who work in the Identity Management space.

Just to be clear, I have a good deal of experience in Enterprise Systems design but I’m not much a Software Engineer or Architect so I’m doing my best to outline this solution.

I think Zoom meeting/webinar hosts face a security gap in that they cannot verify if a participant in the Waiting Room is the approved registrant without exposing the user’s personally identifiable information (PII), such as their email address and relying on editable screen names allows for spoofing, unauthorized access, and impersonation.

One way for this issue to be addressed would be to see if Zoom could implement a Claims-Based Authorization Architecture (CBAA) using Pairwise Pseudonymous Identifiers (PPIDs).

Using a CBAA security model puts Zoom in the role of an intermediary Identity Provider (IdP). Instead of passing a user's raw email to the host, Zoom would verify the user on the back-end and pass a cryptographically signed "claim" (a simple pass/fail status) to the host. This would guarantee zero-trust access control for the host while strictly enforcing data minimization for the user.

 

First Step: Registration and PPID Generation
When a user registers for an event, Zoom creates a unique, encrypted identifier (PPID) that links the user to that specific host. The host never sees the user's underlying account data.

 ┌──────────────┐     1. Registers for event      ┌─────────────────────────┐
│ ├────────────────────────────────►│ │
│ Participant │ │ Zoom Backend │
│ │◄────────────────────────────────┤ │
└──────────────┘ 2. Authenticates Account └────────────┬────────────┘

│ 3. Generates unique PPID
│ (e.g., "usr_8f7d9a")

┌─────────────────────────┐
│ │
│ Host's Event Database │
│ (Stores PPID only) │
│ │
└─────────────────────────┘

 

Second Step: The Privacy-Preserving Join Flow

When the participant joins the meeting, Zoom checks their identity in the background, asks the user for consent, and sends an authorization claim to the Waiting Room.

 ┌──────────────┐
│ Participant │
└──────┬───────┘

│ 1. Clicks "Join Meeting"

┌──────────────┐ 2. Prompts Consent ┌─────────────────────────┐
│ Zoom Backend ├──────────────────────────────────►│ "Verify identity without│
│ (Identity │ │ sharing email?" [YES] │
│ Provider) │◄──────────────────────────────────┤ │
└──────┬───────┘ 3. User grants consent └─────────────────────────┘

│ 4. Generates Signed Claim
│ (Status: MATCHES_REGISTRATION)

┌──────────────┐ 5. Host sees verification ┌─────────────────────────┐
│ Waiting Room │ status (Green Check) │ │
│ / Host SDK ├──────────────────────────────────►│ Meeting Host │
└──────────────┘ │ │
└─────────────────────────┘

This architecture fundamentally shifts what data is transmitted to the host and authorized third-party applications.

 

Third Step: How to make this Work.

Unfortunately, this is where I come up short; maybe if someone with more software engineering/architecture knowledge sees this concept, they could validate whether or not this would be good means to solve the issue you original raised. 

 

Thanks for taking the time to outline this issue, who knows.. maybe if enough folks see this it will gain some traction.

 

Sincerely,

Lars Newlander
Campus Zoom Administrator
California State University - Fresno 

ExpertswhoJohn
Community Super Champion | Customer
Community Super Champion | Customer
September 16, 2026

HI ​@newl ,

Thanks for your contribution.
Zoom currently is too secure. It gives developers an ID for every attendee, we can then perofrm some actions, like organsing breakout rooms, but does not tie that back to the real person in the meeting/webinar/event. We only have the scren name.

 

All the best

 

John Drinkwater

Zoom Community Super Champion

I am not a Zoom Employee

https://www.linkedin.com/in/johndrinkwaterlordzoom/

https://www.youtube.com/@boomwithlordzoom