Short answer
Give each party the least it needs. The driver unlocks only at an approved stop on an assigned trip, once. The dispatcher plans trips and sends lock commands from the office, with every command logged by name. The customer gets no unlock rights at all: they receive alerts and exported reports as proof of what happened.
Key takeaways
- NIST defines least privilege as limiting each user to the minimum access needed for assigned tasks; for a container lock that means the unlock right sits with as few people as possible.
- ENTEK roles are fixed as admin and driver, and each module is fully on or off for a role, so the policy decides who gets an office login, not how a role is fine-tuned.
- A driver unlock is approved only if the trip allows it, the driver is assigned, the vehicle is at the stop, and the one unlock for that stop is unused; the database checks this, not the phone.
- Every command is written to an append-only log with who sent it and the result, and that record cannot be silently edited later.
- Customers do not need a login: add them as email, SMS or WhatsApp recipients and send them Smart Lock reports exported as PDF, Excel or CSV.
01Three parties, one lock: why the unlock needs a written policy
A container lock is only as strong as the list of people who can open it. On a typical Saudi cargo run three parties touch the trip. The driver is with the container and is the one physically present at each stop. The dispatcher, or any office user who plans and supervises trips, sits at a screen and can send commands to the lock. The customer owns or receives the cargo and wants proof that nobody opened it on the way. Each party has a fair reason to care about the lock, but only one of them needs to open it at a given stop, and the customer never does. Without a written policy, unlock rights drift: a supervisor shares a password, a customer asks for a login “just to see”, an old employee keeps access. A one-page policy fixes who may unlock, where, how often, and what proof must be left behind. The template later in this article is built to be copied as it is.
02Two principles to build on: least privilege and separation of duty
You do not need to invent the rules. NIST defines least privilege as restricting each user’s access to the minimum necessary to accomplish assigned tasks. Applied to a lock, the driver gets the unlock only where the delivery happens, and the office gets commands only for the people who supervise trips. NIST also describes separation of duty: no user should hold enough privileges to misuse the system on their own. In cargo terms, the person who plans a trip and decides where unlocking is allowed should not be the only person who checks the photos and the log afterwards. Where a container is very valuable, the idea of two-person integrity helps: NIST describes it as a task that needs at least two authorised people present. You can apply that as a working rule, for example a second person reviews every office unlock the same day. These are management habits, not software switches, so the policy has to state them in plain words.
03The driver: one unlock, at the right stop, with live photos
In ENTEK Smart Lock the driver’s right to unlock is set per trip. When an office user plans a trip, they choose whether the driver may unlock at all. If yes, the driver can request an unlock from the Driver Portal once the stop shows arrived. Arrival is decided by GPS and a database rule, not by the driver pressing a button. The request is checked twice: the screen gives a quick answer, then the database checks for real that the driver is assigned to this trip, the vehicle is at this stop now, and the one unlock allowed at this stop has not been used. If that second check fails, the request is refused, even if the screen looked fine. After an approved unlock there is a short mandatory delay, and then the driver takes proof photos with the live camera only, with no option to pick from the gallery. The policy should say: turn driver unlock off on trips where the driver has no reason to open the container.
04The dispatcher: office commands, named and logged
Office users send commands from the trip detail screen. Each lock reports which commands it supports, and the screen shows exactly those; in the production example they are rear lock, top lock and unlock main lock, and unlocking the main lock asks for its password. Every command is written to an append-only log before it is sent and updated with the result afterwards, together with who issued it and whether it was approved or denied. Once written, that record cannot be silently edited. The lock’s command history reads like “top lock, Executed, user, date”. Two limits shape the policy. First, ENTEK roles are fixed as admin and driver, and each module is either fully on or fully off for a role; there is no read-only or partial office role. Second, the MCP assistant and the API act with the user’s own permissions: the assistant asks before any change, and API tokens are named and can be withdrawn. So keep the list of office logins short, and treat the main lock password as a shared secret to rotate.
05The customer: proof without a key
The customer’s real need is evidence, not control. Because there is no customer or read-only role, the safe default is to keep customers off the dashboard and send them what they need instead. Alert rules can be set per lock, for example open too long or left its assigned zone, with recipients by email, SMS or WhatsApp; a customer contact can be one of those recipients. Rules are checked every 30 seconds and messages usually arrive within about a minute, so write “within about a minute” in the customer agreement, never “instant”. After the trip, Smart Lock offers six report types, including Access Control and Driver reports, each exportable as PDF, Excel or CSV. The trip audit log records every arrival, departure and photo, with lines such as “Exited location without sending photo”. If a customer insists on seeing a live screen, that is a scoping question to discuss with ENTEK as a project, not a login you hand out from the admin list.
06Reviewing the policy every month
A policy that is never checked becomes a wish. Set one monthly review with a named owner who is not the main dispatcher, in line with separation of duty. Start with users: invite, deactivate and delete are on the Users screen, so deactivate anyone who left or changed job, and confirm that each admin still needs office access. Then read the Events screen with the Unauthorized attempts filter, and the Access Control and Driver reports, and ask why each refused request happened: a wrong stop, a second unlock, or a driver not on the trip. Check trips where photos were missed. Rotate the main lock password if anyone holding it left. Note one honest limit: the platform keeps a protected company-wide audit log, but there is no screen that shows it today, so your monthly evidence comes from the command history, the trip audit logs and the exported reports. Saudi organisations that follow the NCA Essential Cybersecurity Controls can map this review to their own access management process.
| Action | Driver | Dispatcher (office user) | Customer | Evidence kept |
|---|---|---|---|---|
| Plan a trip and its stops | No | Yes | No; may agree the stop list in the contract | Trip created line in the trip audit log |
| Allow driver unlock on a trip | No | Yes, only where delivery needs it | No | Trip settings |
| Unlock at an arrived stop | Yes, once per stop, on assigned trips only | Only by exception, reviewed the same day | Never | Command, who sent it, approved or denied |
| Unlock away from a stop | Never; refused automatically | Only for a written emergency reason | Never | Command log; unauthorized attempts in Events |
| Hold the main lock password | No | Named office users only; rotate when one leaves | No | Password prompt on the unlock main lock command |
| Take proof photos | Yes, live camera only | Reviews them | Receives them in reports if agreed | Photos per stop and review status |
| Receive alerts | Optional | Yes | Yes, as email, SMS or WhatsApp recipient | Sent and failed counts per channel |
| Office login to the platform | Driver role only | Admin role, short named list | No login by default | Users list with active and inactive states |
| Monthly access review | No | Not the owner of the review | Gets the exported report | Access Control and Driver reports (PDF, Excel, CSV) |
| Check | Where in ENTEK | Action if it fails |
|---|---|---|
| Every active user still needs access | Users screen | Deactivate the account |
| Refused unlock requests have a known reason | Events, Unauthorized attempts filter | Talk to the driver; fix the stop zone or the trip |
| Office unlocks match a written reason | Lock command history | Escalate to the policy owner |
| Stops left without photos | Trip audit log, Driver report | Coach the driver; tighten the trip settings |
| Main lock password holders are current | Your own password register | Rotate the password |
| Customer alert recipients are correct | Alert configuration per lock | Update or remove the contact |
Figures and sources
- NIST definition of least privilege: access restricted to the minimum necessary to accomplish assigned tasks (Source: NIST CSRC Glossary, least privilege (CNSSI 4009-2022; NIST SP 800-12 Rev. 1), as of 2026-10-19)
- Least privilege as stated in NIST SP 800-53 Rev. 5: each entity granted the minimum resources and authorizations it needs to perform its function (Source: NIST CSRC Glossary, least privilege (NIST SP 800-53 Rev. 5), as of 2026-10-19)
- NIST description of separation of duty: no user should be given enough privileges to misuse the system on their own (Source: NIST CSRC Glossary, separation of duty (NIST SP 800-192), as of 2026-10-19)
- Minimum number of authorised people under two-person integrity: at least 2 authorized persons present (Source: NIST CSRC Glossary, two-person integrity (NIST IR 8401), as of 2026-10-19)
- Current version of the Saudi Essential Cybersecurity Controls: ECC 2-2024 (Source: National Cybersecurity Authority (NCA), Essential Cybersecurity Controls, as of 2026-10-19)
Questions
Should the customer have a login to unlock the container?
No. The customer needs proof, not control. Add their contact as an alert recipient by email, SMS or WhatsApp and send them exported Smart Lock reports. ENTEK has no read-only or customer role, so a login would give more than they need.
Can a driver unlock twice at the same stop?
No. The database allows one driver unlock per stop, and only when the trip allows it, the driver is assigned and the vehicle is at that stop. A second request is refused and recorded.
Can I create a custom dispatcher role with fewer rights?
Not today. ENTEK roles are fixed as admin and driver, and each module is fully on or off. Control the risk with a short list of office users, a monthly review, and the command log that names who sent each command.
How do I prove who opened a container?
Every command is logged before it is sent, with who issued it and the result, and the record cannot be silently edited. Add the trip audit log, the live-camera photos and the Access Control report exported as PDF, Excel or CSV.
How fast will the customer hear about an opening outside a stop?
If an alert rule is set and the customer is a recipient, rules are checked every 30 seconds and the message usually arrives within about a minute. Promise “within about a minute”, not “instant”.
Where do I get the locks for this policy?
The master unit and door locks can be bought through the ENTEK marketplace or requested through an RFQ at entek.ai from verified Saudi suppliers. The trip, unlock and logging rules in this article are built into ENTEK Smart Lock.
Sources
Related insights
- Geofenced Unlock: How a Container Lock Knows It Is at the Right Stop
- RFID, Password or Remote Command: Three Ways to Open a Lock, Three Ways to Fail
- The Trip Audit Log as Evidence in a Cargo Dispute
- Tamper Alerts That Turn Out to Be Nothing? Telling Real Openings From Noise
- Containers Opened on the Way? How a GPS Smart Lock Shows Where and When