Hybrid Security Starts at the Boundary

Hybrid security
Hybrid Security Starts at the Boundary – By Martin Paskin and Petter Martin Jørgensen
Key takeaways
Key terms

Why does hybrid flexibility depend on portable trust?

Hybrid production gives broadcasters the freedom to place each workload where it makes the most operational sense. That freedom only works when trust can travel with the workflow. If moving a service from an on-premises platform to a private data center or public cloud means redesigning security from first principles, the architecture is not truly flexible.

The challenge with hybrid security begins with a fundamental change in visibility. In an SDI facility, engineers could often follow a signal through a physical chain. IP replaces that familiar path with many flows, routes, interfaces, and control relationships. ST 2110 increases the number of elements that must be managed, while remote hubs and cloud resources extend the production estate beyond one building. To be truly effective, security must be part of how every connection is created and operated, rather than exist as a separate layer around that environment.

What is a trust boundary, and why does it matter for live production?

That is why trust boundaries matter. SMPTE RP 2129 provides a framework for establishing boundaries between entities in an IP media system. Those boundaries define which traffic may cross from one domain to another and under what conditions. They limit the effect of an attack, a compromised device, or a simple configuration error before it can spread through the wider workflow.

This last point deserves more attention. Our experience at Appear proves that serious production incidents are still more likely to result from misconfiguration, a failed path, or an unexpected signal than from a sophisticated cyberattack. A secure hybrid design must therefore address resilience and robustness alongside access control. Trust means knowing that an unauthorised user cannot enter the system, but it also means knowing that the intended service will remain on air when a fibre fails or a network becomes bursty.

Illustrative example: a single misconfigured access control list on a contribution feed — not a cyberattack — takes a channel off air faster than most external threats ever could.

How do X Platform and VX enforce trust boundaries in hardware and software?

The implementation will differ between hardware and software, but the principle should remain consistent. On our X Platform, media traffic passes through FPGA-based processing, keeping the data plane separate from the Linux-based control environment. The platform can enforce media-edge trust boundaries, bitrate policing, access control lists, and protocol checks between network zones. If a port expects MPEG-TS or RTP, traffic that does not match that expectation should stop at the boundary.

Our new VX software platform applies the same security logic within software-defined environments. Physical and virtual interfaces can remain isolated, whether they represent control, internal media, external contribution, customer-specific connections, or VPNs. Workflows then create only the required links between those networks. Ports remain closed unless a service needs them, “allow lists” restrict who can connect, and internal checks verify that the request to open a port is legitimate.

Hardware and software, enforcing the same security logic

X Platform (hardware)

  • Data plane: FPGA-based processing, kept separate from the Linux-based control environment
  • Controls: media-edge trust boundaries, bitrate policing, access control lists, protocol checks between zones
  • Best suited to: mission-critical contribution where the data plane needs to stay physically isolated from control

VX (software)

  • Data plane: physical and virtual interfaces isolated by function — control, internal media, external contribution, customer connections, VPNs
  • Controls: ports closed by default, allow lists, legitimacy checks on every port request
  • Best suited to: software-defined environments that need flexible, workflow-level segregation

Is network segregation a substitute for a perimeter firewall?

This is not a substitute for an enterprise-grade perimeter firewall. Public cloud providers and specialist security vendors invest at a scale the broadcast industry cannot sensibly reproduce. Their controls protect the front door, and broadcast platforms still need to protect what happens inside between microservices, production zones, remote endpoints, and individual media workflows. The two layers have different jobs, and a sound hybrid architecture uses both.

Network segregation also makes policy portable. A VX software deployment can isolate separate MXL or NDI domains behind a cloud-based MCR, connecting each production area only to the services it needs. The same approach can separate contribution and distribution paths for different affiliates or customers. Broadcasters can use their chosen VPN technology because VX sees the resulting connection as another network interface, then applies workflow-level controls around it.

Illustrative example: a VX deployment separates each affiliate’s contribution and distribution paths into its own network domain, so a configuration change made for one customer cannot touch another’s traffic.

Does automated discovery remove the need for authorisation?

Automated discovery does not remove the need for authorization. NMOS, MXL, and emerging Dynamic Media Facility approaches make it easier to discover resources and connect applications across distributed environments. That convenience must operate within explicit trust domains. Discovery should reveal only what a service is authorized to see, and connection management should permit only approved flows to cross a boundary. Orchestration without authorization simply automates exposure.

How do resilience controls fit into a secure hybrid design?

Resilience controls belong in the same design. Combining SRT with coherent RTP and ST 2022-7 path protection can mitigate bursty public-network conditions by carrying redundant streams over separate interfaces. No network technology eliminates risk, but layered, standards-based measures can address different failure modes without forcing operators to manage a collection of disconnected security appliances.

The operational rule is simple: keep the architecture understandable. Every additional layer creates another configuration surface and can add latency. Build security into the workflow, separate control and media traffic, enforce boundaries by default, and monitor the full path so operators can see where a problem begins. When those controls behave consistently across X Platform and VX, workloads can move between hardware, private cloud, and public cloud without renegotiating trust each time.

Layers of hybrid security

Security layer What it protects Example controls
Perimeter firewall (cloud or security vendor) The external network boundary, the “front door” Enterprise-grade firewall, DDoS protection, cloud-native perimeter controls
Trust boundaries (SMPTE RP 2129) Traffic crossing between domains Access control lists, protocol checks, bitrate policing
Workflow-level segregation (VX) Connections between microservices, zones, and affiliates Closed ports by default, allow lists, port-request legitimacy checks
Resilience controls Service continuity under path failure or network stress SRT, coherent RTP, ST 2022-7 path protection

Hybrid security should not slow production down. Done properly, it provides the confidence to change where production runs while preserving the performance, visibility, and resilience expected from mission-critical live events. That is what turns hybrid infrastructure from a collection of environments into one operating model.

Common misconceptions about hybrid security

Myth: the biggest risk to live production is a sophisticated cyberattack.
Fact: Appear’s experience shows misconfiguration, a failed path, or an unexpected signal cause more production incidents than cyberattacks — resilience and robustness matter as much as access control.

Myth: a strong perimeter firewall is enough to secure a hybrid production environment.
Fact: perimeter firewalls protect the front door; broadcast platforms still need to protect what happens inside, between microservices, production zones, remote endpoints, and individual media workflows.

Myth: automated discovery protocols such as NMOS and MXL introduce risk by exposing resources.
Fact: discovery and authorisation are separate controls — discovery should reveal only what a service is authorised to see, so orchestration does not have to mean exposure.

Six rules of thumb for hybrid security

  1. Build hybrid security into the workflow itself, not as a separate layer wrapped around it.
  2. Define trust boundaries, such as those described in SMPTE RP 2129, before connecting domains, not after an incident.
  3. Design for resilience as well as access control; misconfiguration and path failures cause more incidents than attackers.
  4. Treat perimeter firewalls and workflow-level segregation as complementary layers, not substitutes for one another.
  5. Separate discovery from authorisation: let services find resources, but only cross a boundary with explicit approval.
  6. Keep the architecture understandable — every added layer is another configuration surface and a potential source of latency.
IBC 2026 · RAI Amsterdam
Meet Appear at IBC 2026

Stand 1.C61, 11–14 September. See the X Platform and VX in action, and talk through your contribution and transport plans with our engineers.