As broadcast infrastructures become increasingly software-defined, control functions that were once isolated inside proprietary routers are now exposed through standardized APIs. While this greatly improves interoperability, it also increases the importance of securing management interfaces against both malicious access and operational mistakes.

Modern IT networks are divided into two planes: the data plane and the control plane. Although these are often more of an abstraction than physical separation, the concept of the division helps enormously with security.

The data plane provides the actual transfer of packets across the network and may be thought of as the switch or router fabric. And the control plane provides the management and orchestration where user roles and access to storage and applications are set.

Separating Data From Control

Software Defined Networks (SDNs) often use this topology to facilitate manual routing and monitoring of a network. By separating the data and control plane, management systems have much more freedom for control. Although SDNs formalized this separation, the concept of distinct control and forwarding functions has existed in networking for many years.

Broadcasters have been working in this way since NTSC, PAL, and analog switchers were first introduced. An SDI router has a control and a data plane. The control plane is governed via a combination of selection and routing panels, and the data plane is provided by the X-Y matrix cards in the SDI router.

In the SDI analogy, security is provided during system installation and programming to stop certain routings taking place. For example, the VT operator will be unable to route bars and tone to an outgoing line, whereas the MCR operator will have this option, albeit heavily guarded!

NMOS uses a similar configuration with the APIs providing the control plane, and the network switches and cables providing the data plane. During registration, a camera connected to the network announces its presence to the registration and discovery system through a node API call. Alternatively, devices can request information from the registration and discovery server, which could be a list of the connected devices, or device labels.

Securing APIs

The APIs are the core of the NMOS system control plane and consequently must be protected from malicious actors. It’s also worth remembering that security isn’t just about hackers and bad people; it’s also about protection from mistakes. Even the most experienced technologist makes errors, and without adequate protection it would be all too easy for somebody to route bars and tone to the program output.

Through its document “BCP-003–01 Secure Communications in NMOS Systems”, Advanced Media Workflow Association (AMWA) provides a series of best practices designed to help keep systems secure. The key objectives are to maintain confidentiality, validate server identification, confirm messages have not been tampered with, and guarantee the message came from the validated server.

NMOS APIs use a RESTful architecture similar to that employed by many web services. Consequently, NMOS takes advantage of many of the web page type communications protocols as well as some of its security implementations through commands such as GET, POST, and DELETE.

HTTPS (HTTP Secure) is often associated with serving web pages as it reduces the risk of man-in-the-middle attacks. If only the HTTP protocol was used (without the Secure), an infiltrator masquerading as the Registration and Discovery server could intercept the messages between the broadcast devices and potentially take control of them.

Adding the HTTPS protocol reduces the risk of this happening as messages are encrypted using the TLS (Transport Layer Security) protocol (RFC 8446). The TLS protocol allows two devices, such as a camera and the Registration and Discovery server, to negotiate a protocol version, select an encryption algorithm, authenticate each other, and establish a shared secret key after which the two devices can freely exchange encrypted data between each other. Both parties can be certain no man-in-the-middle attack has taken place and that the messages haven’t been tampered with.

Authentication Certificates

The man-in-the-middle attack is thwarted by the concept of encrypted authentication certificates. An HTTP server, such as the Registration and Discovery server, will require the installation of an authentication certificate issued by a trusted Certification Authority (CA) like IdenTrust or Amazon Root. As part of their due diligence, the CA will confirm the certificate requester is who they say they are, then digitally sign the certificate using the CA’s private key.

When a browser or TLS client initiates a connection with an HTTP server, it requests the server’s digital certificate. The certificate contains information about the server and a digital signature generated by the CA. Using the CA’s public key, the client verifies the signature and confirms that the certificate is genuine and has not been altered. This process allows the browser or TLS client to verify that it is communicating with the expected server and not an intruder attempting a man-in-the-middle attack.

NMOS does allow for self-signed certificates to be used between clients and servers if a certificate cannot be provided by a CA. However, they do advise that this approach should be restricted to a small number of devices such as connecting a camera and control unit. The self-signing system does not scale well as certificate management becomes incredibly difficult and a significant overhead.

Although TLS confirms the server authenticity, practical systems also require end-users, such as a control panel, to have restricted access to APIs and limit the functionality of the API. This is achieved through user authorization using OAuth 2.0 access tokens.

Access Tokens

OAuth 2.0 (RFC 6749) requires a separate authentication server that can validate a user and assess their read and write access to the system. A VT control panel will have a subset of the available source and destination routing of the MCR control panel, and this restriction will be defined by the system administrator. This access and authentication information is embedded within the OAuth access token.

The authentication server issues the access token (a block of data) that the client uses when initiating a request with the NMOS servers. The access token contains information about the authenticated user or device and the permissions granted to it. When a request is received, the server validates the token and determines whether the requested operation is permitted.

The OAuth method provides additional security for API calls as it stops malicious users from gaining access to key components within the system and manages access for authenticated users. In this context, a user may well be a person, but also a device, such as a camera or control panel. OAuth negates the need for a physical device to enter credentials as the access token can be stored in the device itself and pre-authorized by the authorization server.

As well as providing interoperability between media devices for IP systems, NMOS also contains infrastructure and protocols to improve security and reduce the risk of costly operational errors.

Security In Practice

Although NMOS provides the mechanisms required to improve system security, their effectiveness ultimately depends on how they are implemented and managed. Many broadcast facilities operate within trusted production environments where physical access is tightly controlled and the network is isolated from the public Internet. Under these circumstances it can be tempting to regard security measures such as TLS certificates and OAuth authentication as unnecessary complexity. However, modern broadcast systems increasingly integrate with corporate IT infrastructure, cloud services, remote production workflows, and third-party management platforms, all of which increase the potential attack surface.

Security should be viewed not only as protection from hostile attackers, but also as a means of improving operational resilience. Restricting API access helps prevent accidental configuration changes, while authenticated communications provide confidence that devices are exchanging information with known systems. Equally important is the management of certificates and access tokens throughout their lifecycle. Certificates must be renewed before expiration, compromised credentials must be revoked, and user permissions should be reviewed regularly to ensure they remain appropriate.

By considering security planning during system design rather than as an afterthought, broadcasters can maintain the interoperability benefits of NMOS while reducing operational risk. As facilities continue to migrate towards software-defined and cloud-connected infrastructures, robust security practices will become an essential part of reliable day-to-day operations.