Station Compliance›Field Notes
EAS Security
The rule is short enough to quote in full, and three details in it catch stations out — the no-reuse clause, the dictionary-word clause, and the escape hatch for equipment that physically cannot comply.
By Mark Shannon ·
Most coverage of the new EAS security rule reduces the password requirement to "use strong passwords," which is both true and useless. The rule is more specific than that, and the specifics are where stations get caught.
Here is the operative text, verbatim from the rule as adopted:
(1) Prior to any use to broadcast to the public, EAS Participants shall change any default password, use strong passwords, and change any password if the EAS Participant has reason to believe that the password has been compromised.
(i) A strong password is any password that has a minimum of 15 characters and does not use dictionary words. Instead of using a strong password, EAS Participants may use alternative authentication measures, such as look-up secrets, out-of-band devices, single- or multi-factor one-time password devices, or single- or multi-factor cryptographic authentication, that are reasonably sufficient to mitigate the risk of unauthorized access.
(ii) Passwords employed to comply with this requirement shall not be reused for the EAS Participant's other accounts, equipment, applications, or services.
Four separate obligations are packed in there. Take them one at a time.
Fifteen is longer than most station password policies and longer than most gear's defaults suggest. It is also, notably, a length at which the usual advice about mixing symbols and digits stops mattering much — length is doing the work.
"Does not use dictionary words" is the clause people read too fast. The Commission's stated reason is that dictionary words "can be cracked through brute force," which points at what it is really prohibiting: a password whose entropy comes from a word list rather than from its length. CorrectHorseBatteryStaple is 26 characters and is four dictionary words; whether it satisfies the letter of this rule is genuinely arguable. A random string of the same length is not arguable.
If you want to avoid the argument entirely, generate the password rather than composing it. A password manager doing 20 random characters is unambiguously compliant and takes less time than thinking of a phrase.
Subparagraph (ii) is the sleeper. Passwords used for compliance "shall not be reused for the EAS Participant's other accounts, equipment, applications, or services."
That is broader than "do not use the same password on two Barix boxes." It reaches your other accounts and services generally. The station email password, the automation system login, the streaming provider account, the router — if the password protecting your STL is also protecting any of those, the rule is not satisfied.
The practical consequence is that you cannot comply by choosing one excellent 20-character password and putting it on everything, which is exactly what a station without a password manager tends to do. Every device in scope needs its own distinct secret. For a typical small facility that is somewhere between six and fifteen unique passwords, which is unmanageable on paper and trivial with a password manager.
This clause is also the one most likely to be quietly violated by a station that believes it is compliant. Changing every default to the same strong password feels like a thorough afternoon's work, and it fails subparagraph (ii) on its face.
The rule requires changing a password "if the EAS Participant has reason to believe that the password has been compromised." Note the standard: reason to believe, not confirmed breach.
In a small station the realistic trigger is not a hacking incident. It is staff turnover. The contract engineer who set up the STL four years ago has the passwords. So does the part-timer who left in March. Neither event is a compromise in the dramatic sense, and both are ordinary reasons to believe a credential is no longer controlled.
This is also the part of the rule that makes compliance a recurring obligation rather than a one-time project — a point worth internalising before September 29, because nothing about the rule expires that day.
This is the most useful sentence in the rule for anyone with older gear, and it is widely missed.
Some broadcast equipment will not accept a 15-character password. Some caps at 8. Some has a 4-digit front-panel PIN and no way to extend it. The rule anticipates this: instead of a strong password, you may use "alternative authentication measures, such as look-up secrets, out-of-band devices, single- or multi-factor one-time password devices, or single- or multi-factor cryptographic authentication, that are reasonably sufficient to mitigate the risk of unauthorized access."
In plain terms, if the device cannot hold a long secret, you satisfy the rule by putting something else in front of it that can — a VPN with proper authentication, a jump host, a network segment that requires a separate credential to reach. The device's weak password stops being the only thing between the internet and your transmitter.
The operative test is "reasonably sufficient to mitigate the risk of unauthorized access." That is a judgement standard, not a checklist, which means the reasoning behind your choice matters. Write down what the device was, why 15 characters was impossible, and what you put in front of it instead. Nobody is asking you to file that. You will want it when the person who made the decision is gone.
Three things it is worth being clear about, because plenty of vendors will tell you otherwise between now and the deadline:
That last one matters. The original 2022 proposal did contemplate an annual certification to the Commission, and it did not survive into the final rule. If someone is selling you a filing service for this, they are selling you a filing that does not exist.
The password requirement is not limited to your EAS box. It covers "EAS equipment, studio transmitter link equipment, and any remotely managed equipment that routes, processes, or inserts content into the transmission" of your programming — which in a typical small station means the automation system, the audio processor, the codec, the RDS encoder and the transmitter remote control as well.
The equipment guide walks the scope device by device, and the rule reference covers all three requirements in the same detail as this page covers the first one.
Everything on this site is free to read. The Program Chain Compliance Kit is the implementation version — the device-by-device reference, the network patterns for a one-rack station, and the worksheets that leave a paper trail behind the work.
The rules on this site change without warning — a deadline gets waived, a filing window opens, a Public Notice lands on a Friday. Leave an address and you get an email when something changes that affects a small station. Nothing else, and one click to leave.