.png)
.png)
In February 2024, a finance employee wired $25 million after a video call with what appeared to be their CFO. It was a deepfake. That same year, organized groups disrupted dozens of California city council meetings, forcing several cities to reconsider how they run public sessions on Zoom.
These incidents point to a blind spot in many security programs: the meeting itself is an attack surface.
Zoom is where social engineering happens in real time. Meeting links behave like long-lived access tokens. External participants interact directly with your employees, often outside the controls you rely on elsewhere. And critically, Zoom records all of this activity – in a structured way – if you’re actually collecting it.
Some teams overlook Zoom when expanding telemetry coverage, even though it effectively operates as a new collaboration perimeter where identity, access, and data movement converge.
But if your organization lives in Zoom – internal meetings, customer calls, webinars, with external guests joining constantly – there’s a detailed record of who joined, how they connected, where they came from, and what changed during the session, sitting in Zoom’s APIs. Those are security-relevant questions, whether you’re asking them today or not.
Treating Zoom as "just a video app" overlooks that it is a collaboration surface with direct implications for identity, access control, data exposure, and governance.
Where Zoom extends your coverage
Some of what Zoom captures – IP addresses, device info, geo signals – overlaps with what your IdP, CASB, or MDM already provides.
But Zoom also reaches where those tools don't. Your EDR has no agent on the contractor's BYOD laptop. Your MDM never onboarded the external consultant's phone. Your firewall doesn't see the network they're joining from. The moment they connect to your meeting, Zoom captures their IP, device type, client version, and participation pattern.
Note: Fields like ip_address, device, and location require the Dashboard/Metrics API, which is only available on Business+ plans.
This matters for organizations with uneven coverage: teams with relaxed device policies, business units that haven't fully rolled out endpoint agents, or external participants who never authenticate to your IdP. Zoom becomes a visibility layer into exactly the population your other tools miss.
How to pull the data
The Zoom web portal (especially the Dashboard and Reports sections) is a good place to start exploring what's available and how Zoom organizes things. The Dashboard shows overall usage and in-meeting data, which is useful for getting oriented.
But for security pipelines, you want programmatic access:
That's enough on the plumbing. Let's talk about what you actually get.
Zoom isn't one log source
Think of Zoom as a cluster of related-but-distinct log sources. The security-relevant ones:
This matters because each category needs a different detection model—and because the richest participant data (IP, device, location) requires Business+ for the Dashboard API.
What's actually useful for security
Identity & external exposure
Zoom gives you collaboration-native identity context: users, roles (host/co-host/attendee), and meeting participation history. Between the Meeting and Dashboard APIs, you can build a clear picture of internal-only versus externally-mixed collaboration – who regularly invites guests, and into what kinds of sessions.
Key fields for external detection (from Report API):
The use case is straightforward: external presence is often the earliest sign of unintentional exposure in collaboration systems. A competitor's employee joining recurring engineering syncs via personal email, or an unknown external in sensitive project meetings—these patterns are invisible to your IdP but visible in Zoom.
Detection pattern:
SELECT meeting_id, user_email, COUNT(*) as occurrences
FROM zoom_participants
WHERE user_email NOT LIKE '%@yourcompany.com'
AND meeting_topic LIKE '%engineering%'
GROUP BY meeting_id, user_email
HAVING occurrences > 3
Device/OS + client versions
Zoom's activity and meeting telemetry includes platform, device type, and client version. Even before you're building detections, this helps you describe your collaboration endpoint landscape: which teams are mostly desktop versus mobile, how quickly upgrades get adopted, whether you have pockets of outdated clients that need attention.
Key fields from Dashboard API (Business+ required):
The security angle: risky access patterns are easier to spot when you can consistently describe the client environment. This is especially valuable for BYOD populations and external participants where you have no MDM or EDR visibility—Zoom becomes your only window into what devices are touching your meetings.
Network + geo + QoS
This is where Zoom gets unexpectedly useful for remote work visibility. Historical QoS and meeting analytics (via Dashboard/Metrics APIs) give you participant-level quality signals. QSS is an add-on that streams near real-time participant QoS.
Key fields for location analysis (from Dashboard API):
You don't get "magic location truth," but you do get a structured way to reason about connection quality patterns by team or region, the difference between normal variance and consistent outliers, and the raw ingredients for location-trust logic down the line. When an account that normally joins from corporate IP suddenly appears from an unexpected geo during a sensitive meeting, that's a signal worth investigating—especially if the user was supposedly "in the office" that day. We'll dig into this more in part 2.
Collaboration graph
Zoom meeting history is essentially a lightweight org graph: who talks to whom, how often, and with what mix of internal versus external participants.
If you've tried answering "which teams are most exposed to external collaboration risk" using only org charts, you already know why this is valuable.
You can build this from the Meeting and Dashboard APIs, with webhooks as event triggers if you want completeness without heavy polling.
Admin & configuration trail
Operation logs are boring until you need them. Zoom's operation logs API tracks admin and user activity – adding users, changing account settings, deleting recordings, that kind of thing.
Response fields:
Example operation log entry:
{
"action": "Delete",
"category_type": "Recording",
"operation_detail": "Delete Recording meeting_id:123456789",
"operator": "admin@company.com",
"time": "2024-02-15T14:30:00Z"
}
For security teams, this is your collaboration governance ledger. Exactly the timeline you want when you're doing incident reviews or building compliance narratives.
Meeting links as credentials
A meeting link is a persistent access token. Unlike passwords, they're shared via email, chat, and calendar; recurring meeting links rarely rotate; Personal Meeting IDs (PMIs) are essentially permanent; and they grant access to real-time, synchronous sessions.
Detection indicators (requires Dashboard API for IP/device fields):
The real problem is fragmentation
Most friction with Zoom telemetry isn't about missing signal. It's about how distributed the signal is: meetings, participants, QoS, audit trails, and lifecycle events live in different API endpoints and usually need to be joined together.
Data model for unified view:
zoom_meetings (from /report/users/{id}/meetings)
├── meeting_id, host_id, topic, start_time, duration, type
│
├── zoom_participants_basic (from /report/meetings/{id}/participants) [Pro+]
│ └── user_email, user_name, join_time, leave_time, duration
│
├── zoom_participants_detailed (from /metrics/meetings/{id}/participants) [Business+]
│ └── ip_address, location, device, pc_name, share_desktop, share_application
│
├── zoom_recordings (from /users/{id}/recordings) [Pro+]
│ └── recording_id, file_type, file_size, download_url, status
│
└── zoom_operation_logs (from /report/operationlogs) [Pro+]
└── operator, action, category_type, operation_detail, time
A staged rollout makes sense here: start with the stable audit layers (sign-ins, operation logs), then expand into meeting/participant/QoS richness once you're ready to normalize the data.
Practical detection scenarios
Here are detection patterns that tie Zoom data to security outcomes:
Detection 1: Meeting-time session hijack
User is in an active Zoom meeting, but a parallel session performs sensitive actions elsewhere.
WHEN user.zoom.meeting.status = "in_meeting"
AND user.idp.session.new_activity IN [admin_action, sensitive_data_access]
AND user.idp.session.ip != user.zoom.participant.ip_address
THEN ALERT "Possible session hijack: parallel session from different IP during meeting"
Detection 2: External meeting followed by data access
Sensitive data access shortly after meeting with external participants.
WHEN zoom.meeting.ended
AND zoom.participants.external_count > 0
AND dlp.file_access.user = zoom.meeting.host_id
AND dlp.file_access.time < zoom.meeting.end_time + 30min
THEN ALERT "Sensitive data access within 30 min of external meeting"
Detection 3: Recording accessed by non-participant
WHEN zoom.recording.accessed (via operation_logs where category_type='Recording' AND action='Download')
AND zoom.recording.accessor NOT IN zoom.meeting.participants
THEN ALERT "Recording accessed by non-participant"
Detection 4: Silent presence pattern
User joins many meetings but never actively participates—potential passive intelligence gathering.
-- Requires Dashboard API (Business+) for share_desktop, share_application fields
SELECT user_id, COUNT(*) as meetings,
SUM(CASE WHEN share_desktop = true OR share_application = true THEN 1 ELSE 0 END) as active_meetings
FROM zoom_participants_detailed
WHERE join_time > NOW() - INTERVAL 30 DAY
GROUP BY user_id
HAVING meetings > 20 AND active_meetings = 0
Webhook events for real-time detection
For real-time alerting, configure webhooks for these security-relevant events (see Meetings Webhooks for full event reference):
Webhook payload example (meeting.participant_joined):
{
"event": "meeting.participant_joined",
"event_ts": 1234567890,
"payload": {
"account_id": "account_id",
"object": {
"id": "meeting_id",
"uuid": "meeting_uuid",
"host_id": "host_user_id",
"topic": "Weekly Sync",
"type": 2,
"participant": {
"user_id": "participant_user_id",
"user_name": "Display Name",
"email": "user@external.com",
"join_time": "2024-02-15T14:30:00Z",
"participant_uuid": "participant_uuid"
}
}
}
}
Note: Some webhook payloads may have missing fields depending on meeting settings and participant authentication status. For example, email may be null for unauthenticated guests.
What's next
The practical takeaway: Zoom isn’t just “meeting records” – it’s identity, device, network, collaboration, and governance telemetry.
- Part 2 dives into a concrete use case: using Zoom as corroborating evidence for account takeover verification
- Part 3 shows how we map meetings, participants, and QoS into a normalized schema so you can query and correlate Zoom alongside the rest of your security data using standard patterns.
