The FCC's new rule is a good first step. It's still only a step.
The FCC finally started the conversation on broadcast security with its rules for Emergency Alert System gear and studio-to-transmitter links, and that deserves real credit. But here's the hard part: stations are pouring thousands into firewalls, password resets and staff hours — and still coming up short. The on-air hijackings that made the news, the fake alert tones and the obscene audio, exploited gaps these baseline rules don't cover.
Change every password the rule asks for and you've handled maybe 30% of what actually leaves a broadcast network open to attack. Done on its own, it's mostly security theater: costly, time-consuming, and not moving the needle on the real-world threat. This page is the other 70%.
Broadcast gear isn't office IT. It's a Linux box that never gets patched.
Your transmitters, your RDS encoders, your EAS boxes — most of them are, underneath, a Linux server in a box. They run their own embedded copies of SSH, a web server, cron and a database. And they're built with one priority above all others: stay on the air. So patches arrive only when the manufacturer ships them — sometimes months or years behind — and plenty of boxes in the field never get updated at all.
Meanwhile the flaws are easy to find. Reference notes and CVEs are published openly, and a simple scan reads the exact software version a box is running right off its banner. Once the version is known, the public exploit details often follow within days. That's a device that can be compromised within a week or two of hitting the market.
Which raises the question the whole rest of this comes back to: why would any of this hardware ever be made reachable from the public internet in the first place?
Changing the password doesn't help when the door was never locked by one.
This is the core of what the rule misses. In most of the broadcast hacks that actually happened, nobody needed a password. Three patterns show why.
Published flaws in the web interface
BW Broadcast's TX-series FM transmitters carry a critical published vulnerability, CVE-2025-28233 — an attacker can pull session identifiers straight out of the device's own log files and hijack the session, no password required. Resetting the admin password does nothing about it.
Default credentials under the hood
A lot of embedded-Linux broadcast gear ships with a factory root password documented right in the manual. Change the web-interface password all you want; if the underlying root login is still the published default and the box is on the open internet, it gets scanned, logged into, and quietly turned into someone else's tool — a mail relay, a node in a DDoS botnet, whatever they need.
Audio that was never authenticated
Most IP codecs carry the actual audio over plain, unauthenticated RTP or UDP. (Comrex is a notable exception — it puts a password layer on its own protocol even without CrossLock.) When the codec sits on an open port, an attacker doesn't need credentials at all: they knock the stream down with a quick flood and seize the connection the instant it reconnects.
You can change every password on the FCC's list and still be wide open. A firewall only enforces the rules it's given — and the lock on the handle doesn't matter if the door is propped open.
Push vs pull: which way does your audio flow?
Almost every exposed studio-to-transmitter link comes down to a single decision — and most people never knew it was a decision. The firewall sits at the transmitter site, between your gear and the public internet. Watch what each choice does to it.
Same studio, same transmitter, same firewall. The only difference is which end reaches out first — and that's the difference between a hole a stranger can walk through and a wall that was never opened.
What actually closes the gap.
None of this requires being a security specialist. It requires four habits.
Never push. Always pull.
Have the transmitter reach out and pull the stream from a known, trusted source at the studio — never the studio pushing in to a listening port at the transmitter. This one choice removes the open door. (The diagram above walks through exactly why.)
Lock the firewall to specific addresses
For both RDS and audio ports, allow only your studio's static IP to connect — or route the traffic through a properly managed VPN or SSL tunnel. Budget for a firewall that can actually do source-IP restrictions; the cheap ones often can't, and that's not where to save money.
Keep everything behind NAT
Broadcast gear can reach out for what it needs, but nothing should be directly reachable from the public web. No port forwards, no open SNMP, no exposed listening ports. If the box isn't publicly addressable, the password on it becomes almost irrelevant.
Don't assume a VPN is the fix
A cheap or unpatched VPN is its own problem. Windows' built-in PPTP has a critical remote-code-execution flaw (CVE-2022-24504) that turns the tunnel into a wider backdoor the day it's breached, and wrapping jittery UDP audio inside a VPN often hurts reliability — forward error correction and the rest end up fighting the tunnel. Strict IP restrictions don't depend on constant patching to stay safe.
Get the boxes off the public internet and the passwords stop being the thing that matters. A good majority of recent broadcast hacks didn't turn on a weak password anyway — they turned on an open port.
Check every box on the rule — and you can still be compromised.
The new rules and the password resets are a genuine, welcome first step. They're just not a cure, because they don't touch the thing that actually gets stations hacked: gear sitting reachable on the public internet. Two things fix that.
Know what's exposed. That's what AirScan is for. It looks at your station from the outside, the same way a scanner does, and hands you the list in plain English — here's what's reachable, here's what it is, here's how to close it. Free, read-only, safe to run during a live show.
And keep the data off the open internet in the first place. It's why we built Broadcast Network Monitor as a closed system, and why AirCodec carries a station's audio, RDS and HD data to the transmitter site over a 256-bit-encrypted transport instead of across the open web.