Short answer: a receiver should not operate equipment merely because it can decode a radio packet. It should also verify who sent it, whether the command is fresh, whether that transmitter is allowed to request that function, and whether the machine is currently in a state where the request is permitted.
That distinction sounds obvious, but it is missing in a surprising number of wireless controls. On the bench, “valid packet” and “accepted command” look like the same event. In the field they are not. A copied transmitter, a replayed recording, a remote that should have been removed from service, or an old command recovered after a brownout can all produce a perfectly recognizable RF frame.
After years of reviewing remote-control projects, I have learned to look at security from the receiver outward. The transmitter matters, but the receiver is where a radio message becomes physical action. That is the point where the design must stop trusting and start deciding.
Put a decision boundary between the radio and the output
I use a simple chain when reviewing a design:
Antenna → decoder → identity and freshness check → function authorization → machine-state check → output request
The decoder answers only one question: “Does this frame match the expected modulation, timing, and packet format?” It does not prove that the command is current, that the sender still belongs to this machine, or that the requested movement is appropriate now.
The output should therefore be driven by a validated request inside the controller, not directly by the packet decoder. Even on a small MCU, keep these steps separate in the firmware. It makes the security review clearer and prevents a later feature—such as service pairing or group control—from quietly bypassing the normal checks.
Start with a realistic threat model
Security specifications often begin with an encoder name. I prefer to begin with people, access, and consequences.
Can an unknown person stand close enough to receive a transmission?
Would a copied command open access, move machinery, disable an alarm, or interrupt a process?
Are transmitters shared between shifts, contractors, vehicles, or sites?
Can a lost handset be identified and removed without erasing every valid one?
Who can reach the receiver’s learn button or service connector?
How long is the equipment expected to remain in service?
A light inside a locked cabinet and a gate facing a public road do not need the same control architecture. Neither do a single-owner workshop and a warehouse with fifty handheld transmitters. “433 MHz” says nothing about this risk, and “encrypted” does not finish the analysis.
Freshness matters as much as identity
A receiver can recognize the correct transmitter and still accept the wrong transmission at the wrong time. This is the replay problem: a previously valid command is recorded and sent again later.
Fixed identifiers do not provide freshness. Rolling counters can provide it if the counter, acceptance window, and resynchronization behavior are designed properly. A challenge-response exchange, authenticated sequence number, or short-lived session can also work in systems that support two-way communication.
The practical details are where designs fail. Define what happens when a button is pressed repeatedly out of range, when the receiver loses power between receiving and saving a counter, and when two receivers paired to the same transmitter see different parts of the sequence. A generous resynchronization window may reduce service calls, but it also widens the set of messages the receiver is willing to accept. That trade-off should be documented, not left at a library default.
I also reject duplicate commands at the application layer. RF transmitters often repeat a frame several times to improve reliability. The receiver needs a clear rule for deciding whether those frames represent one operator action or several. Otherwise, the anti-replay layer may be correct while the machine still starts twice.
Treat enrollment as an administrative function
In many installations, the easiest attack path is not the radio protocol. It is the learn button.
If anyone can open an enclosure, press one exposed button, and add a transmitter, strong packet authentication has only protected an unauthorized enrollment. Service mode should require deliberate physical access or an authenticated maintenance action. It should time out automatically, show an unmistakable indication, and return to normal operation after success or failure.
Do not allow normal control while the receiver is in an ambiguous enrollment state. I have seen equipment where a long press both operated a relay and entered learn mode. That may be convenient during a demonstration, but it is poor behavior on a working machine.
For managed sites, keep an inventory that connects each stored credential to a real transmitter, owner, vehicle, or role. “Memory slot 17” is not enough when a handset disappears six months later.
Plan removal before the first remote is paired
A security feature that cannot be serviced will eventually be bypassed. Lost-transmitter handling is the test I use most often.
Ideally, the receiver can revoke one transmitter without affecting the others. If it can only erase all memory, write down the recovery procedure: who collects the remaining handsets, who re-enrolls them, how the site confirms that the lost unit no longer works, and what happens during the downtime.
For larger fleets, expose stable credential identifiers in the service interface and log enrollment and deletion events. The log does not need to contain personal information; it needs enough information to answer “what changed, when, and by which maintenance action?”
Also define the memory-full condition. A receiver should fail visibly when it has no space, not silently overwrite an old credential or appear to accept a new one.
Authorize functions, not just transmitters
Pairing a handset to a receiver should not automatically grant every output. A maintenance remote may need jog control but not automatic operation. A delivery driver may open one gate but not a second gate leading into production. A handheld transmitter used for setup may be allowed only while a keyed service mode is active.
This is easiest to implement when the application stores permissions by credential and command. The receiver first authenticates the message, then looks up whether that identity may request that function. The machine controller still has the final say based on limits, guards, operating mode, and interlocks.
Group control needs the same discipline. A broadcast command can be useful for lighting or shutters, but a broad group credential should not accidentally become a master key for unrelated equipment.
Protect keys and counters through the full product life
Cryptography is only as strong as its production and service process. A product family built around one shared secret may be easy to manufacture, but one extracted key can affect every unit. Unique device keys reduce that blast radius, while adding work in programming, traceability, replacement, and long-term support.
On the receiver, store keys and counters so an ordinary readout or memory copy does not create a working clone. Handle brownouts during nonvolatile writes. Use versioned records, integrity checks, and a recovery state that keeps outputs off if security data is inconsistent.
Firmware updates also need a policy. A receiver should not accept an older image that reintroduces a known weakness simply because the image has a valid format. If authenticated update and rollback protection are required, include them in the architecture early; they are difficult to bolt on after production.
Test the hostile and untidy cases
A normal functional test proves that the intended remote works. A security test proves that other plausible inputs do not.
Record a valid command and replay it immediately, after power cycling, and after later valid commands.
Press the transmitter many times out of range, then return and check resynchronization behavior.
Try to enroll during normal operation and after an interrupted enrollment.
Fill receiver memory and confirm that no existing credential is replaced.
Delete one transmitter and verify that only that transmitter is rejected.
Copy receiver nonvolatile memory to a spare unit and verify the intended clone protection.
Interrupt power during counter, pairing, deletion, and firmware-update writes.
Send valid but unauthorized commands from a credential with limited permissions.
Apply repeated, malformed, and high-rate packets and confirm that control timing remains predictable.
Run these checks with the production firmware and the real service procedure. A protocol can be sound while a factory test command, debug header, or undocumented master remote defeats it.
Know when a simple keyfob is no longer enough
Basic one-way RF remains a sensible solution for many low-consequence controls. It is inexpensive, responsive, and easy to maintain. The mistake is stretching it into an access-management system it was never designed to be.
If the application needs individual revocation, role-based permissions, reliable event history, mutual authentication, fleet-wide key rotation, or confirmation that a command was executed, move to a managed two-way design or place the RF receiver behind a controller that provides those functions. Do not promise them through marketing language that the radio protocol cannot support.
The practical rule I use
A decoded RF packet is evidence, not authority. Before the receiver turns it into an output request, it should be able to answer four questions: Who sent it? Is it fresh? Is that sender allowed to request this function? Is the machine allowed to do it now?
If the design cannot answer one of those questions, document the limitation and make sure the application consequence justifies it. That is a more honest—and usually more secure—engineering decision than adding the word “secure” to a datasheet.
For access control, lifting equipment, industrial machinery, alarms, or any application where unauthorized operation could injure people or release valuable assets, have the final architecture reviewed against the applicable security and functional-safety requirements by qualified specialists.