Definition
Permissions (Permission) refer to the range of operations and data access that users, roles, or devices can perform on the IoT platform. Permission management is the security cornerstone of systems such as Device Management Platform, Charging Platform, Operations Platform, supporting access control for multi-tenancy, multiple regions, and multiple roles. Typical permissions include: device view/control, configuration modification, user management, report export, remote SIM locking, etc. In cross-border scenarios, permissions need to support fine-grained segmentation by country, region, and sub-account to meet local compliance and data isolation requirements.
Technical Features and Architecture
Technical features of permissions include: RBAC — Role-Based Access Control, decoupling roles and permissions; Resources and operations — permissions can be refined into specific operations (read, write, delete) for specific resources (such as device groups or regions); Inheritance and delegation — sub-accounts inherit primary account permissions and support permission delegation; Audit — changes in permissions and sensitive operations can be traced. Typical architecture includes: permission model definition, strong authentication and authorization, SSO or OAuth integration with the platform. In cross-border scenarios, GDPR and other data access permissions, multilingual permission text, and local operations personnel permission isolation need to be considered.
Application in IoT and cross-border scenarios
The application of permissions in IoT and cross-border scenarios includes: Charging Platform — Different roles such as CPO, eMSP, maintenance personnel, and finance personnel have different permissions for EV charging stations , CDR, and settlement data; Device Management — Customers have full permissions on their own devices, while operators have limited permissions on shared devices; Operations Platform — Maintenance personnel permissions are divided by region, and cross-border teams can only operate in their responsible areas; Logistics Platform — Data and operation permissions for roles such as shippers, carriers, and drivers on the Logistics Platform . The SimtoLink platform supports fine-grained permission configuration to ensure secure isolation in cross-border multi-tenant scenarios.
Resource Boundaries of Permission in a Cross-Border Tenant
Permission answers what this identity may do to which objects. Objects include device groups, regions, card batches, bills, and tickets. Actions include viewing, exporting, changing configuration, sending a lock, starting an upgrade, and closing an alert. The single word administrator is not a boundary. On a cross-border platform, one customer may have devices in several countries. Local maintenance should see only the chargers or vehicles in its own country. Headquarters finance should see the summed amounts, not every identifiable trip. Scope and action must both be limited. Limiting the action but not the country still lets local staff change a device in another country.
A role is a way to package permissions, not the identity itself. One person can hold a maintenance role in country A and a read-only role in country B. A delegation hands part of one's own permission to someone else for a while. The delegation should name the object scope, the actions, and the expiry. After expiry, caches already pushed to an edge gateway or a browser must expire too, or the revocation exists only in the central database. A device certificate represents the device, not the operator. A lock or an upgrade sent over the device channel should still trace back to the user account that approved the command. The audit record keeps the operator, the object, the action, the source address, and the result. When it is read across borders, visibility follows the region where the data sits.
Conditions for a Temporary Delegation to Take Effect
A temporary delegation can take effect when the delegator already holds the action and the resource being granted, the delegate has completed identity verification, the term is shorter than the matching work window, and high-risk actions such as lock, key replacement, and batch upgrade are selected on their own rather than inherited inside a role package. In cross-company work, a contractor account should sit under the entrusted tenant, not inside the device owner's super role. A group synced by single sign-on from a customer directory must map to a regional role on the platform. A directory label that says global administrator must not be mapped to write access on every device.
Copying an Administrator Role in Full
A common mistake is to copy the headquarters administrator when a new site goes live, so a field account can export the card list and the bills of every country. Another is to hide a menu on the screen while the interface still accepts writes, so a script or an integrated system can go around it. A third is to disable only the login after someone leaves, while issued tokens and edge caches stay valid. A fourth is to put card lock and device reboot in the same role, so finance stops a card and also trips the charger's relay. If the region filter is applied in the report layer rather than in the query, interface pages still return devices from other countries. Split roles by region and by action, authorize high-risk actions on their own, expire tokens and caches together with the account, and periodically check the interfaces that can actually be called, not only the menus.
Authorization at the interface should use the same region and action as the menu. Do not only hide a button on the page. Export should be authorized on its own, with a limit on scope and row count, so a read-only account cannot obtain another country's line items by exporting. The token revocation list must be pushed to edge gateways that are still in use, and a gateway must reject a revoked account before the local cache expires. Periodically call a write interface with a low-privilege test account and confirm that it is refused. That is more reliable than checking role names. Record the test in the audit, and do not make a trial change on production data.