Encryption on Public Safety Radio: When You Need It, When It Hurts You

What radio encryption actually does

Strip away the acronyms and encryption on a land mobile radio system does one thing: it scrambles the audio between your radio and the radios you have shared a key with, so that anyone listening without that key hears noise instead of words. This is link-layer, or over-the-air, encryption. It protects the transmission while it is in the air. It does not encrypt your recorded call logs, your records management system, or the phone call the reporting party made to your dispatch center. Those are separate problems with separate protections.

The practical effect is a closed circle. Every radio inside the circle can talk to every other radio inside the circle. Anyone outside the circle, including a scanner hobbyist, a member of the press, a curious neighbor, and unfortunately also a neighboring agency that does not share your key, hears static. That closed circle is the entire value proposition and also the entire source of trouble. The value is privacy. The trouble is that the circle has a hard edge, and on a bad day the person on the wrong side of that edge is a crew you need.

It helps to be precise about what you are defending against. Encryption defends against passive listening: someone monitoring your traffic to learn what you are doing. It is very good at that. It does not defend against a lost or stolen radio that still holds a valid key, it does not defend against a crew member reading traffic off a screen, and it does not make your operational discipline any better. If your people say things on an unencrypted channel that they should not say, encryption does not fix the habit. It just moves the audience.

AES-256 and why the standard matters

Not all encryption is equal, and this is one of the few places in radio where there is a clear right answer. The accepted standard for public-safety voice encryption is AES, the Advanced Encryption Standard, at a 256-bit key length. AES-256 is a published, vetted, government-recognized algorithm. When people in the public-safety communications world say a system is "properly encrypted," this is what they mean.

Older and proprietary methods still show up on legacy equipment, and some of them are weak enough that a determined listener with modest resources can defeat them. Treat any pre-AES scrambling or vendor-specific low-bit encryption as privacy theater rather than real protection. If a channel carries traffic sensitive enough to justify encrypting it at all, it is sensitive enough to justify doing it with AES-256 rather than something that only looks encrypted.

There is a compatibility trap buried in this. Two radios can both claim to be encrypted and still be unable to talk to each other, because encryption interoperability requires the same algorithm, the same key, and the same key identifier. A radio running AES cannot decode a radio running an older proprietary scheme, even if both are on the same frequency. This matters most at the edges of a region where different agencies bought different equipment in different years. "We are both encrypted" is not the same as "we can hear each other."

The part nobody warns you about: key management

The algorithm is the easy part. The hard part, the part that quietly consumes staff time and causes most real-world failures, is managing the keys. A key is the shared secret that lets radios inside the circle understand each other. Keys have to be generated, loaded into every radio, kept secret, rotated on a schedule, and revoked when a radio is lost or a member leaves. None of that happens by itself.

In the manual model, keys are loaded into each radio with a physical key-loading device, one radio at a time. For a small department with a couple dozen portables and mobiles, that is an afternoon. For a large system, or for a region trying to keep dozens of agencies in sync, it is a standing job. Every new radio, every replacement after a failure, every key rotation means touching hardware. Miss a radio during a rotation and that radio drops out of the circle until someone notices and reloads it, usually at the worst possible time.

Over-the-air rekeying, usually shortened to OTAR, is the answer to the manual grind. OTAR lets a key management facility push new keys to radios over the radio network itself, without physically collecting them. It is a genuine improvement and it is how large modern systems stay manageable. But it is not free and it is not simple. OTAR requires infrastructure, it requires a key-management authority that somebody owns and operates, and it requires radios that support it. It also concentrates risk: the key management system becomes a critical piece of infrastructure that, if misconfigured or unavailable, can knock radios out of service.

• Who holds the keys. Someone, a person with a name and a backup, has to own key management. If that role is undefined, you do not have a key management program, you have a pile of encrypted radios that will slowly fall out of sync.
• Rotation schedule. Keys should change on a defined cadence and immediately after a compromise. Write the cadence down. An unrotated key that has been on every radio for years is a liability.
• Lost-radio procedure. A radio that leaves your control still holds a valid key until you do something about it. The plan for revoking or rekeying after a loss has to exist before the loss, not after.
• Spare and loaner radios. Mutual-aid loaners and shop spares need keys too, or they are useless in exactly the situation you keep them for.

The interoperability problem is a safety problem

This is the heart of the matter, and it is where encryption stops being an IT decision and becomes an operational one. The whole point of a shared regional radio plan is that when a big incident pulls in three fire departments, two EMS agencies, and a law enforcement unit, they can all hear each other. Encryption, applied carelessly, breaks that.

Picture a working structure fire that goes to mutual aid. Your engines are encrypted on your day-to-day tactical channel. The neighboring department that rolls in to help is not on your key. Now your incident commander is giving assignments that half the people on the fireground cannot hear. The fix in the moment is to move everyone to a common, unencrypted interoperability channel, which works only if crews are trained to do it, the channel exists in their radios, and nobody freezes. Every extra step you add to that transition is a step that can fail while people are inside a burning building.

The danger is not theoretical and it is not only about big incidents. A crew that keys up on the wrong encrypted talkgroup, expecting to reach a partner agency, gets silence and may not immediately understand why. That confusion costs seconds. On a pursuit, a rescue, or a fast-moving fire, seconds are the budget. Encryption that a crew does not fully understand is more dangerous than no encryption, because it fails silently. A dead radio tells you it is dead. An encrypted radio that cannot reach the person you are calling sounds exactly like a quiet channel.

When you genuinely need encryption

None of this means encryption is a bad idea. There is traffic that has a real, defensible reason to be protected, and for that traffic encryption is the right tool. The test is simple: would broadcasting this in the clear expose someone to harm, violate a legal duty, or hand a real advantage to a bad actor? When the answer is yes, encrypt it.

• Protected personal and medical information. Patient names, conditions, and locations relayed over the air can be sensitive, and there are legal duties around health information. Traffic that carries it has a strong case for protection.
• Personally identifying information generally. Home addresses of protected individuals, information tied to minors, and details that could enable stalking or harassment do not belong in the clear.
• Tactical positioning on active threats. On a barricaded-subject or active-threat incident, broadcasting where your people are staging and how they plan to move can be read by the very person they are moving on. This is a life-safety reason to encrypt.
• Investigative and surveillance traffic. Traffic that tips off a subject to an approach or an operation has an obvious reason to be protected, and this is the least controversial encryption case of all.

Notice what these have in common. They are specific categories of traffic on specific channels for specific reasons. None of them is "everything the department says all day." The strongest case for encryption is always narrow and reasoned. The moment the justification becomes "just encrypt it all to be safe," you have left the world of managing risk and entered the world of avoiding thought, and that is where the interoperability failures come from.

The full-dispatch-encryption debate

The genuinely contested question in public-safety radio right now is whether routine dispatch traffic, the ordinary call-for-service radio chatter, should be fully encrypted. Reasonable people who all want the same thing, safe crews and a safe public, land on different sides of this. It is worth laying the argument out honestly rather than pretending there is an obvious answer.

On one side, agencies point out that even routine dispatch traffic can leak personal information, that anyone with an app can now follow along in real time in a way that was harder when scanners were a hobby, and that broadcasting a victim's address or a crew's arrival time in the clear can enable harm. From this view, encrypting dispatch is basic privacy hygiene for the people you serve.

On the other side sit real costs that do not show up on the first day. Full encryption of dispatch cuts off the press, neighboring agencies without your key, tow operators, hospitals, and members of the public who have long relied on open traffic for legitimate reasons, including simply knowing what is happening in their own neighborhood during a disaster. It also raises a transparency question that communities are entitled to weigh in on: public-safety agencies operate on public authority, and there is a real argument that the public has an interest in being able to hear how that authority is exercised. Blanket encryption removes that ability by default, for everyone, all the time.

We are not going to tell you which side is right, because the honest answer depends on your community, your legal environment, and your governance. What we will say plainly is that this decision belongs in the open, with elected officials and the public in the room, not buried in a procurement order for new radios. When encryption of routine dispatch happens as a quiet technical default rather than a deliberate policy choice, the department inherits a controversy it never chose to have, and usually finds out about it after the fact.

The middle path: encrypt what needs it

The good news is that the choice is not binary. Modern trunked systems let you encrypt selectively, channel by channel and talkgroup by talkgroup. You do not have to encrypt everything or nothing. The mature approach, the one most departments arrive at once the initial enthusiasm wears off, is selective encryption: protect the traffic that genuinely needs it and leave the rest, especially interoperability, in the clear.

A workable layout for many departments looks something like this. Routine day-to-day operations run in the clear or, if privacy of dispatch is a settled local policy, on encrypted talkgroups that still have a clear-channel fallback. Sensitive categories get their own encrypted talkgroups: a channel for medical detail, a channel or mode for tactical operations, a protected path for investigative traffic. And the mutual-aid and interoperability channels are always in the clear and always in the radio, no exceptions. Crews are trained to move to them the instant a partner agency is involved.

• Decide per channel, not per department. The unit of decision is the talkgroup, not the whole system. Ask of each one, what does this carry and who needs to hear it.
• Keep a clear-channel fallback. Every crew should have a known, trained path to unencrypted communication when the encrypted path fails or a partner cannot join.
• Train the transition, do not just document it. Moving to a common channel under stress is a skill. It belongs in drills, not only in a binder.
• Reassess when partners change equipment. A regional radio refresh can silently break an interoperability assumption you have relied on for years. Revisit the plan whenever a neighbor re-equips.

Writing a policy your crews can actually follow

Encryption fails in practice far more often than it fails in theory, and it fails because the humans using it were never given a clear, trained, written procedure. A radio configuration is not a policy. The policy is the set of decisions about what is encrypted, why, who manages the keys, how crews reach a partner agency, and what to do when something does not work. If that lives only in the heads of two people in the radio shop, you have a single point of failure wearing a uniform.

There is also a real cost angle to plan around. Encryption capability is frequently a licensed feature rather than something every radio does out of the box. That means budget line items, per-radio licensing, and the ongoing operational cost of key management and, if you go that route, OTAR infrastructure. None of this is a reason to avoid encryption. It is a reason to scope it deliberately, so you are paying to protect the traffic that needs it rather than buying a blanket you will regret. Count the loaners, the spares, and the mutual-aid partners in that math, because a plan that only funds your own front-line radios will spring a leak on the first big incident.

Whatever you land on, write it down in language a probationary crew member can follow at two in the morning. Which channels are encrypted. Which are always clear. How to reach a mutual-aid partner. Who to call when a radio drops out of the circle. What happens when a radio is lost. Then train it, drill the channel transitions until they are reflexive, and review the whole thing on a schedule and after every incident where communications did not go the way you expected.