Two-Way SMS for Remote Equipment: Authentication and Command Safeguards

Limit the permitted command set

Begin with read-only status requests. If actions are required, list each operation, authorised role and local preconditions. Avoid arbitrary text being interpreted as a machine command. A sender-number allowlist is useful filtering but should not be treated as strong authentication by itself, especially for consequential actions.

Handle delay and replay

Define command expiry, a unique request identifier and duplicate rejection. A delayed command must not run after the operating context has changed. Use an authenticated channel and confirmation workflow appropriate to the risk; where SMS cannot meet those requirements, use it for notification and move control to a more suitable interface.

Keep local control authoritative

The local controller must enforce permissives and interlocks regardless of the message content. Remote commands should never bypass an emergency stop or maintenance lockout. Return separate accepted, executed and rejected results, including a reason when practical. A gateway accepting text is not proof that the physical equipment reached the requested state.

Test misuse and loss of communication

Test expired messages, duplicate identifiers, revoked users, malformed input and lost replies in a controlled environment. Confirm the state remains safe when delivery is uncertain. Keep an audit trail and a process for removing departed staff. Document which actions are intentionally unavailable remotely and why.

FAQ