Definition
Remote locking (Remote Lock) refers to the process of sending instructions to IoT devices through the Device Management Platform or connection management platform to remotely disable device functions or SIM card connectivity capabilities. Remote locking is used for: arrears control — locking the SIM when data is used up or the data plan expires to prompt users to renew; theft prevention and asset management — remotely locking devices when lost or misused; compliance and risk control — locking the SIM in cases of abnormal usage or illegal roaming. Remote locking is issued via channels such as push notification, telemetry, and once the device or SIM receives the command, it stops connecting to the network. Unlike network deactivation, remote locking is reversible; after unlocking, the device can resume network connectivity.
In cross-border scenarios, remote locking needs to support unified SIM locking for devices deployed in multiple countries and integration with multiple operators; one card for multiple countries — after locking, the device is unusable in all countries.
Technical Features and Architecture
The remote device lock technology architecture includes: Platform Layer —— Device Management Platform and Connection Management Platform (CMP) initiate the lock command; Channel Layer ——delivers to the device or SIM via OTA, push , SMS, remote signaling ; Execution Layer ——the device firmware or SIM card executes the lock, stopping network access; Status Layer —— the device status is updated to "locked," and the platform can query it. Compared with mass activation , it supports mass locking; combined with network entry and network exit , locking is a controllable state in the device lifecycle. In cross-border scenarios, the lock command needs to be delivered through channels reachable by networks in multiple countries.
Before locking, ensure the device is online or supports offline locking (e.g., via operator-side SIM lock); unlocking is also issued through the platform.
Application in IoT and cross-border scenarios
Remote device locking is widely applied in: EV charging stations and equipment —— EV charging stations , Charging stations Locking devices when fees are unpaid or regulations are violated to protect the interests of operators; Logistics and assets —— Logistics trackers , asset devices are locked when lost or in violation; In-vehicle and mobility —— Remote locking of in-vehicle terminals and car-sharing vehicles; Cross-border deployment —— Overseas EV charging stations , unified lock management for cross-border logistics devices. Cross-border charging networks, global logistics, and multinational equipment rentals all rely on remote device locking to achieve fee control and asset protection, One card for multiple countries Locking is effective worldwide once activated.
SimtoLink supports remote lock capability, in conjunction with Device Management Platform , covering 200+ countries and regions, assisting in cross-border device management.
Whether a Remote Lock Acts on the Card or on the Device
A remote lock has at least two entirely different paths. One acts on the SIM or the subscription. The home network or the connectivity platform stops data, SMS, or all services, and the terminal cannot open a session no matter which country it is in. The other acts on the device. The platform sends a command that stops a charger from delivering power or stops a terminal's peripherals. The card itself may stay online so it can receive an unlock. Reversibility and visibility differ. After a stop on the card side, the device has no data channel and cannot report that it has locked. After a lock on the device side, the heartbeat can continue and confirm that the lock was executed. If the ticket does not say whether the lock is the subscription, the function, or both, field staff will look for the status in the wrong system.
A card with several identities needs the scope written even more clearly. If only the identity currently in use on the visited network is stopped, the device may come back online after it switches to another identity. Unlock must name the scope as well, so the home-country test identity is not the only one restored while the destination identity stays stopped. A lock command should have a unique sequence number, a reason, and a condition for expiry or manual release. The approver who releases an overdue lock, a lost-asset lock, and a compliance lock is not the same person. They cannot share one unlock button. The result must distinguish three outcomes: the operator has accepted the stop, the device has confirmed that the function is off, and the command timed out with no confirmation. The first does not include the second.
State to Check Before Sending a Lock
Before sending, check whether the target is the card, the device, or both; whether the visited network in that direction supports the requested stop scope; if the path is a device command, whether the device is online now or can be woken; whether a transaction that must not be interrupted is open, such as charging that has not ended or an upgrade that is being written; and whether the person responsible for unlock is named. For a device that must stop safely first, send a device-side stop of output, wait for confirmation, and only then stop the card. Stopping only the card leaves the charger with no remote way to stop, while local output may continue. A batch lock needs a preview of scope, split by country or fleet, so one selection does not take the global inventory. A card-side stop on an offline device can take effect immediately. A device-side command has to queue and expire, so it is not executed by mistake months later.
Still Waiting for a Heartbeat After the Stop
A common mistake is that data on the card is already stopped, and the platform still treats a heartbeat timeout as a failed lock, so it sends the command again, SMS cost rises, and the state does not change. Another is to lock only the device application, so the user swaps the SIM and keeps using the same hardware. A third is that a multi-identity card stops only the current set. After a border switch the service returns, and the lock looks as if it released itself. An unlock sent on a data channel that is already stopped never reaches the device. It has to go by SMS that is still open, or the operator restores data first. A fourth is a lock with no recorded reason. After finance collects the overdue amount, nobody dares to unlock, or a security case that is not finished is released as if it were only an overdue bill. The status page should show subscription state and device confirmation side by side. When the subscription is stopped, do not wait for a data heartbeat. A device lock must see a device receipt. On release, check that the reason still holds, and keep the operator.