What NDI Access Manager Actually Covers

A certified NDI camera hits the switch and shows up in Studio Monitor. Nobody configured a password. Nobody enrolled it. It joined the Public group and started advertising on mDNS because that is what the certification checklist requires.

IT says the site already has NDI security. They mean Access Manager groups, or a Discovery Server, or they heard Bridge is encrypted.

Those are real NDI controls. They cover who can see a source in the NDI list. They do not cover who talked to that address on the rest of the LAN.

Default NDI is discoverable on purpose

NDI Certified gear is supposed to just work. Default DHCP. Default mDNS. Default Public group. The interoperability page is explicit: the Public group "should be enabled by default," and any receiver on the same network in Public should find the source.[4]

Vizrt's TriCaster best-practices guide says the same thing from the other direction. Every NDI device starts in Public send and receive. Delete the grouping information and it falls back to Public.[11]

That is the product. Plug in, see sources. It is also why "we run NDI" is not an access-control statement.

What Access Manager actually does

NDI's own Access Manager page does not use the word security. It says the tool gives you "control over the visibility and discoverability of NDI sources" through send and receive groups.[1]

A source that sends into group Studio-A is listed only for receivers that put Studio-A in their receive list.[1][2] Names have to match. Matching is not case-sensitive. The string lives in ndi-config.v1.json, which Access Manager writes and every NDI app on that machine reads at launch.[1][2]

Vizrt is blunt about the mechanism: Access Manager does not populate a list of groups to join. You type the name. "This provides a method to hide sources from other devices on the NDI network, and only by knowing the group name can you gain access."[11]

A group name is a shared string. It is not a login, a certificate, or a per-user role. Anyone who can set the same string on another box sees the source. StreamGeeks still titles that workflow "for security" and talks about "group credentials."[10] The NDI page never does. It says visibility.

Use the groups. Hide Studio A from Studio B. That is a real operations win. It is not authentication.

Discovery Server is a registry, not a lock

mDNS is the default discovery path, and it has been since NDI 1.0.[11] Vizrt notes the dual-home problem in plain language: on a machine with more than one NIC, mDNS "can open NDI signals to networks where you might not want it to be available."[11]

Discovery Server is the grown-up version: a central unicast registry with less multicast chatter, and it works when cloud networks block multicast. NDI will even tell you that separate servers can serve "workflows or security needs."[3] The control they describe is which registry a device is pointed at.

Senders configured for Discovery Server stop advertising on mDNS. Finders still use both mDNS and the server for machines that were never pointed at it.[3] Spinning a Discovery Server up does not put a fence around every NDI talker on the VLAN. It puts a fence around the ones you remembered to configure.

NDI 6.3 added sender monitoring in the Discovery app, so you can see who is registered and watch the NDI plane in one place.[8] That is the right tool for a missing source. It is AV operations. It is not a picture of the rest of the LAN.

Encryption lives on Bridge, and on HDCP hardware

When NDI encrypts, it says so.

NDI Bridge is the WAN tool. Host and Join share an encryption key so the path across the public internet is not raw NDI.[5] The export classification is the tell. The NDI SDK is EAR99. NDI Tools sit in a different bucket "because Bridge and Remote both use encryption."[6] The LAN SDK is not in that sentence.

HDCP in NDI 6.3 is copy protection between two compatible hardware boxes so an HDMI source does not blank. Studio Monitor cannot view those streams. That is HDCP, not an access list for the AV VLAN.[7]

Promwad, writing in May 2026, puts the LAN default in one line: many NDI streams still go without encryption or authentication, and an open-source client that can see the source can subscribe.[9] NDI's Access Manager and Groups pages never contradict that. They never mention a login.

Even when Bridge encrypts the WAN hop, the LAN side is still NDI. A switch still sees who talked to whom.

NDI monitors NDI

The Discovery app, Studio Monitor, and Access Manager all watch the NDI plane: sources, groups, registrations, stream health. That is the job they were built for.

A guest address appearing as a peer of an encoder is not a group change. A codec opening RDP or hitting the public internet is not a Discovery Server event. A second DHCP server is not an Access Manager setting. A laptop that is not an NDI device, sitting on the AV VLAN, does not show up in Studio Monitor at all.

The VLAN isolation post covered the drawing-versus-traffic version of this. The Dante post covered membership and media encryption that still do not watch the rest of the LAN. NDI Access Manager is the same split, one protocol over. Visibility is solved in the NDI plane. Lateral movement, unexpected egress, and "this box should never talk to that one" live on the switch.

Flow data is the other half

NetFlow, IPFIX, and sFlow already describe who talked to whom, on which ports, and how much moved. You do not need the media. You do not need an agent on the camera. You need the exporter the switch or firewall is already running.

That is enough to see a non-NDI peer on an AV address, a new talker that never joined a group, internet egress from a codec, or a discovery storm after a change window. Access Manager will not raise those, because they are not NDI events. Keep Access Manager for the NDI list. Use flow data for the rest.

What to do this week

Pick one live NDI site. Not the lab.

What is still in Public, and was that on purpose?
Who knows the group names, and who can write ndi-config.v1.json?
Dual-homed boxes: is mDNS still advertising onto the wrong NIC?
Export flows for a few days. Compare NDI peers to everything else those same addresses talked to.

If the Studio Monitor list and the flow map agree, you have a baseline. If they do not, you have the conversation before the incident.

FAQ

Is this a knock on Access Manager or Discovery Server? No. Use groups. Point the fleet at a Discovery Server. Turn on Bridge encryption for the WAN hop. Those are the right NDI controls. This post is about the job they do not claim.

Does Access Manager encrypt NDI on the LAN? No. It hides sources behind a group name. Encryption shows up on Bridge, and on HDCP hardware pairs. The LAN SDK is classified EAR99. NDI Tools are not, because Bridge and Remote use encryption.[1][6]

We already have a Discovery Server. Why add anything? Discovery Server tells you which NDI devices registered with that server. It does not tell you what those same IPs did on the rest of the network, or what non-NDI boxes on the AV VLAN did at all.

Will flow monitoring decrypt or inspect NDI media? No. AVoIP Guard takes NetFlow, IPFIX, and sFlow metadata from the switch or firewall. No agents on the endpoints. No look at the payload. Encrypted or not, the metadata is the same job.

Is this the same argument as the Dante post? Same split: protocol plane versus the LAN. Different claim. Dante Director actually does membership, roles, and AES-256. NDI Access Manager does visibility. People still call both "security."

Sources