As audio networks are increasingly integrated into critical infrastructure—ranging from broadcast studios and live event venues to corporate AV systems and public address networks—securing AES67 audio networks against cyber threats becomes an absolute necessity. AES67 is an Audio Engineering Society standard that defines a method for high-performance audio-over-IP interoperability, allowing devices from different manufacturers to exchange uncompressed, low-latency audio streams over standard Ethernet networks. However, like any IP-based system, AES67 inherits the same attack surface as the underlying network infrastructure. Cyber threats such as eavesdropping, man-in-the-middle (MITM) attacks, denial-of-service (DoS) assaults, and unauthorized device manipulation can compromise audio integrity, cause service outages, or even lead to broader network breaches. Implementing robust security best practices is vital to protect these networks from unauthorized access, data breaches, and operational disruptions.

This article provides a detailed guide to securing AES67 networks, covering the risks, essential configurations, and advanced protective measures. By following these recommendations, organizations can ensure reliable, high-quality audio transmission while minimizing exposure to cyber threats.

Understanding AES67 Security Risks

AES67 networks are not inherently secure. The standard itself focuses on interoperability and transport, leaving security largely to the network layer and system administrators. As a result, AES67 installations face several specific vulnerabilities:

  • Eavesdropping: Audio streams transmitted over IP without encryption can be intercepted by anyone with access to the network. Tools like Wireshark can capture RTP (Real-time Transport Protocol) packets, revealing sensitive audio content.
  • Man-in-the-Middle (MITM) Attacks: Attackers can position themselves between two communicating devices, intercepting, altering, or injecting audio packets. This can lead to data corruption, stream hijacking, or injection of malicious content.
  • Denial-of-Service (DoS): Flooding the network with excessive traffic can overwhelm switches, routers, or endpoint devices, causing audio dropouts, latency spikes, or complete loss of service. For live broadcast or emergency announcements, this can have severe consequences.
  • Unauthorized Device Access: Many AES67 devices rely on default credentials or simple authentication mechanisms. An attacker able to access the control interface can reconfigure streams, disable outputs, or exfiltrate audio data.
  • Network Propagation: Because AES64 traffic often shares infrastructure with other IP services, a compromised audio device can become a gateway to attack other systems on the same network, such as building management, IT servers, or corporate databases.

These risks are compounded by the fact that many AES67 deployments prioritize low latency and jitter performance over security. Endpoints may not support encryption, and the network may be configured with flat broadcast domains that allow any device to communicate with any other. Therefore, a layered security approach is essential.

Best Practices for Securing AES67 Networks

The following best practices address the most critical aspects of AES67 security, from network design to device management and ongoing monitoring. These recommendations align with general IP network security principles while addressing the unique demands of real-time audio transport.

1. Use Network Segmentation

Separating AES67 audio traffic from other network traffic is one of the most effective ways to reduce the attack surface. This can be done using Virtual Local Area Networks (VLANs) or dedicated physical networks (air-gapped).

  • VLAN Segmentation: Create a dedicated VLAN for audio traffic and configure switches to isolate it from data, voice, or management VLANs. Use 802.1Q trunking to carry the VLAN between switches. This prevents unauthorized devices in other VLANs from directly sending or receiving audio streams.
  • Subnet Isolation: Assign a unique IP subnet to the audio VLAN and configure access control lists (ACLs) at the router or Layer 3 switch to block any traffic not explicitly required. For example, only allow the specific UDP port ranges used by AES67 (typically the SAP announce port 9875 and RTP dynamic ports).
  • Physical Isolation: In high-security environments, consider physically separate switches and cabling for audio networks. This eliminates any chance of bridging between networks, though it increases hardware costs.
  • Multicast Management: AES67 often uses IGMP snooping to manage multicast streams. Enable IGMP snooping on all switches to prevent multicast traffic from flooding into non-audio VLANs, and restrict IGMP reports to authorized devices only.

Segmentation not only limits exposure but also simplifies security monitoring by reducing the volume of traffic that needs to be inspected.

2. Implement Strong Authentication and Access Controls

All network devices that participate in AES67—including switches, routers, audio endpoints, and control software—must have robust authentication mechanisms.

  • Password Policies: Replace default passwords with strong, unique passwords for every device. Use a password manager to track them. Enforce complexity requirements (minimum length, mix of characters).
  • Multi-Factor Authentication (MFA): For web-based management interfaces or SSH access, enable MFA where available. This adds a second layer of protection even if credentials are compromised.
  • Role-Based Access Control (RBAC): Assign different privilege levels to users. Operators might only need read-only access to stream status, while administrators require full configuration privileges.
  • 802.1X Network Access Control: Implement 802.1X port-based authentication for the audio VLAN. Only devices with valid certificates or credentials can gain network access. This prevents rogue devices from connecting to the network and sending audio streams.
  • Disable Unused Services: Turn off any unnecessary network services on audio endpoints (e.g., Telnet, HTTP, SNMP read/write). Use HTTPS for web interfaces and SSH for remote CLI access.

These measures ensure that only authorized personnel and devices can interact with the audio network, reducing the risk of manipulation or eavesdropping.

3. Encrypt Data Transmission

AES67 itself does not mandate encryption; its primary goal is low-latency interoperability, and many hardware implementations lack cryptographic capabilities. However, you can still protect the confidentiality of audio streams through network-level encryption.

  • VPN Tunnels: Use IPsec or WireGuard VPNs between sites or between the control network and the audio network. This encrypts all traffic, including AES64 streams, as it traverses untrusted links. For local suburban networks, consider a site-to-site VPN between switch stacks.
  • MACsec (IEEE 802.1AE): If your switches and endpoints support it, enable MACsec to encrypt all data on the Ethernet link. This works at Layer 2, so it does not affect IP routing and adds minimal latency. MACsec can protect AES67 traffic within a single LAN or VLAN.
  • Secure RTP (SRTP): Some AES67 implementations support SRTP, which encrypts the RTP payload. This is an emerging feature; check with your device’s firmware documentation. If available, use SRTP instead of tunneling for better granularity and lower overhead.
  • Avoid Plaintext Protocols: When using control protocols like SAP (Session Announcement Protocol) for stream discovery, be aware that these announce stream metadata (IP, port, codec) in clear text. Consider moving to a secure discovery method, such as using the NMOS IS-04/IS-05 registration and connection management, which can run over HTTPS.

Encryption adds overhead, so test latency and jitter to ensure they remain within tolerable ranges (typically <1 ms for AES67). For most local networks, MACsec or VPNs introduce acceptable overhead.

4. Keep Firmware and Software Updated

Software vulnerabilities in network switches, audio endpoints, and management software are a common attack vector. Vendors release patches to fix security flaws, improve stability, and sometimes add encryption support.

  • Schedule Regular Updates: Establish a review cycle for firmware updates, testing them first in a staging environment before rolling out to production. Prioritize critical security patches.
  • Enable Automatic Updates (where safe): Some managed switches and audio nodes support automatic firmware updates. Use this cautiously—ensure you have a rollback plan in case an update breaks compatibility or performance.
  • Maintain an Inventory: Keep a record of all devices, their current firmware versions, and the vendor support status. Set alerts for end-of-life notifications to plan hardware refreshes.
  • Patch Network Infrastructure: Don’t forget the underlying network gear. Switches, routers, and firewalls also need regular updates. Outdated switch firmware can introduce vulnerabilities that directly affect audio traffic isolation.

A well-maintained firmware baseline closes known vulnerabilities and often includes performance improvements for audio streaming.

Additional Security Measures

Beyond the four core practices above, an effective security strategy includes proactive monitoring, firewalling, logging, and staff training. These measures help detect and respond to incidents quickly while reducing human error.

Monitor Network Traffic for Unusual Activity

Implement an intrusion detection system (IDS) capable of analyzing AES67 traffic patterns. While deep packet inspection of RTP streams may be challenging due to latency requirements, you can monitor for anomalies:

  • Bandwidth Spikes: Unexpected increases in multicast traffic could indicate a DoS attack or a rogue stream. Set threshold alerts on switch ports.
  • Unusual Source/Destination IPs: Use network flow analysis (NetFlow, sFlow, IPFIX) to identify devices that are not part of the authorized audio VLAN sending or receiving multicast addresses.
  • Failed Authentication Attempts: Review logs for excessive failed login attempts on managed switches or audio endpoints. This may indicate a brute-force attempt.
  • IGMP Anomalies: Monitor IGMP membership reports and queries. A sudden increase in joins to a specific multicast group could indicate a man-in-the-middle or stream hijacking.

Consider deploying a dedicated security appliance or using a software-based IDS like Suricata configured to inspect the audio VLAN. For very sensitive installations, a network tap can provide passive monitoring without latency impact.

Implement Network Firewalls

Firewalls are essential for restricting traffic to and from the audio network. Use the following rules:

  • Whitelist Only Required Protocols: For an AES67 network, allow only UDP ports used by RTP and SAP (typically dynamic high ports, often in the range of 5004-5008 for RTP, and 9875 for SAP). Block all other inbound/outbound traffic between the audio VLAN and other VLANs.
  • Stateful Inspection: Deploy a firewall that can perform stateful inspection of UDP traffic? A good enterprise firewall can track UDP sessions and prevent spoofed packets.
  • Rate Limiting: Apply traffic policing to prevent DoS floods. Set a maximum bandwidth per port or per multicast group that matches the expected audio load.
  • Segmentation Firewalls: Use a next-generation firewall (NGFW) between the audio VLAN and the corporate network. This allows you to apply application-level controls, such as ensuring that only approved audio control software (e.g., Dante Controller, AES67 management tools) can talk to the devices.

Firewalls must be carefully tuned to avoid introducing latency. If possible, use hardware firewalls with hardware acceleration for low-latency rules.

Maintain Comprehensive Logs for Audit and Troubleshooting

Logging provides visibility into network events and is critical for forensic analysis after an incident. Ensure that:

  • Syslog is Configured: All switches, routers, and audio endpoints send logs to a centralized syslog server (e.g., usingrsyslog, Splunk, or ELK stack). Logs should include authentication attempts, configuration changes, interface status changes, and IGMP events.
  • Log Retention: Retain logs for at least 90 days, or longer if compliance requirements dictate (e.g., for broadcasters regulated by the FCC).
  • Log Integrity: Use secure transmission (TLS) for syslog and consider signing logs to prevent tampering.
  • Alerting: Set up alerts for critical log events (e.g., repeated failed logins, unauthorized access attempts, interface resets). Use a SIEM solution to correlate events across the audio network and other IT infrastructures.

Logs also help troubleshoot network issues: if audio drops occur, reviewing logs can reveal packet loss, STP changes, or MAC address flapping.

Educate Staff on Cybersecurity Best Practices and Potential Threats

Human error remains one of the most significant risk factors. Training should be ongoing and tailored to different roles:

  • Audio Engineers: Teach them to recognize phishing emails that might target administrative credentials. They should know not to plug personal laptops into the audio VLAN, and to report any unusual device behavior or network issues.
  • IT and Network Administrators: Ensure they understand the latency and jitter constraints of AES67 so security measures (like encryption, packet inspection) are implemented without degrading performance. Provide training on switch security features (802.1X, ACLs, MACsec).
  • General Staff: Conduct annual security awareness training covering password hygiene, physical security of equipment racks, and the importance of reporting lost or stolen devices.
  • Incident Response Drills: Practice responding to a simulated DoS attack or unauthorized access on the audio network. This helps build muscle memory and identifies gaps in the response plan.

An educated workforce is a strong defense against social engineering attacks that could lead to network compromise.

Conclusion

Securing AES67 audio networks requires a proactive, layered approach that blends technical controls with vigilant monitoring and skilled personnel. By implementing network segmentation, strong authentication, data encryption, and consistent firmware updates, organizations can dramatically reduce their exposure to cyber threats. Additional measures such as traffic monitoring, firewalls, comprehensive logging, and staff education further strengthen the security posture. While no system is completely invulnerable, these best practices help ensure that critical audio streams remain reliable, confidential, and available—even in the face of an increasingly hostile threat landscape.

As the industry moves toward more IP-based workflows, security must be baked into the design from the start, not added as an afterthought. The AES67 standard itself is a powerful enabler, but it's the network security architecture and operational discipline that ultimately protect your audio assets. For deeper insight, refer to IETF RTP guidelines and consider reviewing NIST’s cybersecurity framework for a structured approach. Stay informed about new vulnerabilities and adapt your defenses accordingly—because in the world of live audio, silence is not always golden.