Station Compliance›Field Notes

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.

1. Fifteen characters, and no dictionary words

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.

2. No reuse — and read the scope of that carefully

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.

3. Change on suspected compromise

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 now that September 29 has passed, because nothing about the rule expired that day.

4. The escape hatch for equipment that cannot do 15 characters

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."

Corrected September 27, 2026. An earlier version of this post said you could satisfy the rule by putting something in front of the device: a VPN, a jump host, a separately authenticated network segment. The FCC's FAQ of September 21 says otherwise, in plain words: "Deploying a firewall or VPN to protect equipment subject to the password requirement is not sufficient for compliance. Even if the firewall or VPN uses a strong password, the equipment itself must employ strong passwords or alternative authentication measures that provide equal or better security as compared to a strong password."

So the alternative has to live on the device. If a device cannot hold a long password, the FAQ leaves three routes:

1. An alternative authentication measure on the device itself that is at least as secure as a strong password: one-time passwords, multi-factor, certificate or key-based login, look-up secrets. Check the manual and ask the vendor; some newer firmware adds these.
2. Replace it with equipment that can meet the requirement.
3. Obtain a waiver from the Commission. The FAQ names this route but, as of this writing, no process for it has been published. Talk to your communications counsel before relying on it.

Keep the VPN and the firewall anyway. They satisfy the rule's separate network segmentation requirement. They just do not stand in for the password.

Whichever route you take, write down what the device was, why 15 characters was impossible, and what you did about it. Nobody is asking you to file that. You will want it when the person who made the decision is gone.

What the rule does not require

Three things it is worth being clear about, because plenty of vendors will tell you otherwise between now and the deadline:

• It does not require multi-factor authentication. MFA appears in the list of acceptable alternatives to a 15-character password, not as a mandate.
• It does not require rotation on a schedule. There is no 90-day rule here. Change on compromise, and change defaults before use.
• It does not require you to file anything. There is no certification, no report, and no new recordkeeping obligation attached to § 11.35(d). The one exception is if a piece of equipment can’t meet the password requirement and can’t be replaced: the FCC’s FAQ says that needs a waiver, and a waiver is a request you file.

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.

Where this applies

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.