Understanding AES67 and Its Vulnerabilities

AES67 is an interoperability standard that enables high-quality digital audio transport over standard IP networks using RTP for payloads, SDP for stream discovery, and PTPv2 for synchronization. While it brings flexibility and scalability to broadcast, live production, and professional audio environments, its reliance on standard IP infrastructure introduces security risks absent in traditional point-to-point analog or digital wiring. By design, AES67 prioritizes low latency and interoperability, but it does not mandate encryption, authentication, or access control at the transport layer. This leaves networks exposed to several attack vectors:

  • Unencrypted RTP streams: Audio payloads flow in the clear. An attacker with network access can capture packets with tools like Wireshark, reconstruct audio, or inject malicious traffic.
  • Spoofed PTP messages: Precision Time Protocol messages lack authentication by default. A forged PTP announcement can desynchronize devices, causing glitches, phase errors, or denial of service.
  • Multicast flooding and snooping: AES67 commonly uses multicast. Without IGMP snooping and ACLs, any device on the same VLAN can join any multicast group, eavesdrop on streams, or flood the network with rogue traffic.
  • Unsecured management interfaces: Many AES67-enabled devices expose web, SNMP, or REST APIs with default credentials or HTTP instead of HTTPS, making them easy targets for configuration theft or control hijacking.
  • Lack of device identity: Without 802.1X or similar, any device plugged into a port can participate in the audio network. A compromised laptop can masquerade as an audio endpoint.

These vulnerabilities are not theoretical. Real-world incidents have included unauthorized access to broadcast consoles, PTP manipulation in live events, and ransomware that locked Dante controllers. Recognizing these risks is the first step toward building a layered defense.

Best Practices for Securing AES67 Networks

1. Network Segmentation and Microsegmentation

Segregation is the cornerstone of AES67 security. Place all audio endpoints, switches, and controllers on a dedicated VLAN or physically separate network. Use managed switches to configure access control lists (ACLs) that permit only essential protocols: RTP (UDP ports 5004–5005 typically), PTPv2 (UDP 319–320), IGMP (for multicast group management), and management traffic from designated workstations. Block all other traffic, including DHCP if not needed (use static IPs for critical devices). For larger facilities, further subdivide the audio VLAN into microsegments — for example, separate multicast groups for each studio or control room. This limits the blast radius if a device is compromised. When AES67 traffic must traverse untrusted networks (guest Wi‑Fi, internet, or campus LAN), use encrypted tunnels such as IPsec, WireGuard, or MACsec.

2. Strong Authentication at Every Layer

Authentication must be enforced for device management, network access, and, where possible, streams. On management interfaces, disable default passwords immediately and enforce complex credentials — at least 12 characters with mixed case, numbers, and symbols. Centralize authentication using RADIUS or LDAP for larger deployments. Consider multi-factor authentication (MFA) for critical consoles. At the network layer, implement 802.1X port-based access control: only authenticated devices (with certificates or credentials) can obtain an IP address and join the audio VLAN. For stream-level authentication, AES67 itself does not support it, but you can leverage companion protocols: NMOS IS-04/IS-05 (used in ST 2110 environments) can enforce authorization via HTTPS-based registries. Many AES67-compatible devices (e.g., Dante, RAVENNA) offer web-based authentication for stream subscription; ensure these are enabled and backed by a secure identity provider.

3. Encryption: Protecting Audio Payloads in Transit

Encryption is the most direct defense against eavesdropping and tampering. Several approaches work with AES67:

  • MACsec (IEEE 802.1AE): Operates at Layer 2, encrypting all Ethernet frames between two MACsec-capable switches or endpoints. It adds negligible latency (under a microsecond) and is transparent to AES67. Ideal for studio wiring within a facility.
  • IPsec: Encrypts IP packets between AES67 devices or subnets. Works well for point-to-point or site-to-site connections but requires careful configuration to avoid jitter. Use ESP in tunnel mode for remote sites.
  • Secure RTP (SRTP): Encrypts the RTP payload directly. Some manufacturers (e.g., Audinate in Dante Domain Manager) support SRTP. Requires key management — often via a central server or pre-shared keys.
  • Encrypted tunnels (TLS/DTLS): For remote AES67 transport or cloud-based control, use TLS for control paths and DTLS for media. Ensure endpoints support these protocols.

When deploying encryption, test thoroughly. Switches and endpoints must handle encryption without introducing packet loss or jitter. Measure round-trip latency before and after. For live production, keep total end‑to‑end latency under the required threshold (e.g., 1 ms for monitoring). Check vendor documentation for compatibility — not all AES67 devices support all encryption methods.

Common Cyber Threats to AES67 Networks

Understanding specific threats helps prioritize countermeasures:

  • Eavesdropping / Traffic Sniffing: An attacker with network access can capture RTP streams and replay or record audio. Mitigation: encryption (MACsec, SRTP) and strict VLAN ACLs.
  • Denial of Service (DoS): Flooding with PTP messages or multicast traffic can crash switches or desynchronize all endpoints. Mitigation: rate-limit PTP, enable IGMP filtering, and isolate control plane traffic.
  • Man-in-the-Middle (MitM): Attackers can intercept and modify PTP timing messages, causing audio misalignment, or alter SDP descriptions to redirect streams. Mitigation: 802.1X, mutual authentication, and encrypted tunnels.
  • Rogue Device Injection: A compromised or unauthorized device on the audio VLAN can send fake streams, join multicast groups, or issue malicious IGMP queries. Mitigation: port security (MAC address locking), NAC, and periodic scanning.
  • Ransomware / Malware: A management PC infected with ransomware can encrypt configuration files or lock audio devices. Mitigation: isolate management interfaces, use application whitelisting, and maintain offline backups.

In addition, insider threats — whether accidental or malicious — remain a concern. A disgruntled engineer with admin credentials could reroute streams or disable encryption. Implement RBAC and audit logs to detect unusual behavior.

Vendor-Specific Security Considerations

While AES67 is a standard, many vendors add their own security features. Here are key considerations for major ecosystems:

  • Dante (Audinate): Dante Domain Manager (DDM) adds authentication, role‑based access, and optional AES67 encryption via SRTP. Use DDM with LDAP/AD for centralized user management. Enable “secure mode” in the Dante Controller for encrypted subscriptions. Refer to Audinate’s security resources.
  • RAVENNA / ST 2110: RAVENNA devices often support HTTPS management, SNMPv3 authentication, and NMOS authorization. Enable NMOS IS-04/IS-05 with TLS for secure registration and connection management. Consider using IPsec or MACsec for media encryption.
  • Livewire (Telos Alliance): Livewire AES67 implementations typically use multicast. Telos recommends separate VLANs, 802.1X, and SNMPv3. Their Axia consoles support encrypted management dashboards.

Always review vendor security guides and firmware release notes. Subscribe to security advisories to stay informed of patches.

Additional Security Measures

Regular Firmware and Software Updates

Vendors frequently patch security vulnerabilities. Establish a routine to review and apply updates for AES67 devices, switches, and management software. Test in a staging environment first to avoid compatibility issues. Subscribe to mailing lists from manufacturers and organizations such as the AES Standards Committee for updates on the standard itself. Document firmware versions and maintain a changelog.

Network Monitoring and Anomaly Detection

Continuous monitoring detects suspicious activity early. Use tools that analyse PTP metrics (offset, delay, domain number), multicast group memberships, and traffic patterns. Set alerts for:

  • Unexpected RTP streams on unknown UDP ports
  • Sudden spikes in multicast traffic
  • IGMP joins/leaves outside normal operating hours
  • Multiple PTP grandmaster changes

For smaller installations, Wireshark can capture AES67 traffic on a mirrored port — but restrict access to captures due to privacy concerns. In larger environments, deploy a security information and event management (SIEM) system to correlate logs from switches, firewalls, and audio controllers. Integrate with an identity management system to map events to users.

Access Controls and Role-Based Permissions

Use role-based access control (RBAC) on all management interfaces. Define distinct roles: operators (can start/stop streams), engineers (can modify routing and security settings), and administrators (full access). Integrate with Active Directory or LDAP for centralized user management. Avoid shared accounts; each user should have a unique login. Enable audit logging for all configuration changes, and review logs weekly. For physical access, lock network closets, use tamper-evident seals on switch ports, and disable unused ports.

Physical Security

Protect physical access points: lock server rooms and network closets, secure patch panels, and use port-level disablement for unused switch ports. In studios or on stages where equipment is accessible to performers or crew, consider using 802.1X with certificate-based authentication to prevent unauthorized devices from plugging in. Surveillance cameras in critical areas can act as a deterrent.

Implementing a Zero Trust Architecture for Audio Networks

Zero Trust — “never trust, always verify” — is increasingly applied to operational technology (OT) networks. For AES67, a Zero Trust approach involves:

  • Treating every device as untrusted until authenticated and authorized (e.g., via 802.1X certificate or machine credentials).
  • Micro-segmenting subnets within the audio VLAN so that a compromised console cannot reach devices in another studio.
  • Requiring mutual authentication for all inter-device communication: control plane (e.g., HTTPS with client certificates) and, where possible, media plane (IPsec or MACsec with pre-shared keys validated against a central authority).
  • Applying least-privilege access: a network interface that only sends multicast should not be able to receive or send unicast management traffic.
  • Continuous monitoring and behavioral analytics: a microphone that suddenly communicates with an external IP should trigger an alert and automatic isolation.

Zero Trust is complex in live production due to strict latency and reliability requirements. Start with the most critical segments (e.g., on‑air studios) and expand gradually. Use automation tools (Ansible, Puppet) to enforce configuration and audit compliance.

Developing an Incident Response Plan for AES67

Even the strongest defenses can be breached. An incident response plan tailored to audio networks helps minimize downtime and data loss. Key steps:

  • Identification: Define indicators of compromise specific to AES67 — e.g., unexplained audio dropouts on multiple channels, stream hijacking (audio replaced with noise), abnormal IGMP join patterns, or sudden PTP instability.
  • Containment: Predefined runbooks: isolate the affected VLAN by disabling switch ports, block rogue multicast groups via IGMP filtering, change passwords immediately, and revert to a backup configuration. Have a “break glass” procedure to fall back to a physically separate backup audio path if needed.
  • Eradication: Remove malicious devices from the network. Reimage compromised management workstations. Apply security patches. Verify that no backdoors remain (check for new user accounts, unknown services).
  • Recovery: Restore device configurations from known‑good backups (store offline). Test synchronization and audio quality with a multi‑channel test signal before returning to service. Document the full restore process.
  • Lessons Learned: Hold a post‑incident review. Update security controls, revise the response plan, and train staff. Share anonymized findings with industry peers (e.g., via the AES Technical Committee on Network Audio).

Conduct tabletop exercises annually. Consider resources like CISA’s insider threat mitigation guide for organizational best practices.

Conclusion

Securing AES67 audio networks demands a multi‑layered strategy that addresses the unique characteristics of real-time media transport. By segmenting your network, enforcing strong authentication, deploying encryption where feasible, maintaining up‑to‑date firmware, and practicing continuous monitoring, you can drastically reduce the risk of cyber threats and unauthorized access. As the industry moves toward broader IP‑based production — often combining AES67 with ST 2110, Dante, and other standards — security must be integrated from day one, not retrofitted after an incident. Implement these best practices to protect your audio infrastructure, ensure reliable transmission, and keep your content safe from interception or manipulation.