News

When a fuel tanker enters a cellular dead zone, its access rules should not disappear with the network signal. A smart tanker lock can verify access locally using a preloaded authorization policy, cryptographically protected credentials, and trusted device state. The cloud issues or updates permissions beforehand; the lock decides whether a particular opening is allowed without contacting the server.

The difficult part is not simply storing an approved user list. A disconnected lock must reject expired permissions, prevent copied messages from being reused, and retain evidence of each attempt. At an unloading point with poor coverage, weak offline controls can either stop a legitimate delivery or allow access that dispatch can no longer revoke immediately.

What must be available before coverage disappears

Offline operation requires an authorization path that does not depend on a live cloud response. The lock needs trusted verification keys, an applicable policy, and persistent security state. The operator needs an appropriate credential, delivered through a supported local interface such as NFC, Bluetooth, or a contact-based electronic key.

Two architectures are common: the lock stores approved identities and their permissions, or the operator presents a signed authorization token that the lock can verify. Hybrid designs combine both. A cached access list is straightforward but may become stale. Signed tokens carry explicit scope and expiry, although they still require protection against copying and replay.

A phone having connectivity is not the same as the lock having connectivity. A phone may obtain a credential before arrival and carry it to the lock. That can support disconnected operation, provided the lock independently validates it rather than trusting an “approved” message displayed by the app.

A local authorization transaction, step by step

Consider a driver requesting access to a tanker outlet inside a coverage gap. A defensible signed-token design follows this sequence:

1. Receive the authorization. The credential identifies the issuer, intended lock or asset, permitted operation, validity window, and a unique authorization identifier. It may also bind permission to a particular operator key.
2. Verify authenticity and scope. The lock checks the signature against a trusted issuer key, then confirms that the permission applies to this device and requested operation. A valid signature alone does not authorize every action.
3. Authenticate the presenter. Where operator binding is required, the lock issues a fresh challenge. The operator’s device proves possession of the associated secret or private key, preventing a copied token from being sufficient.
4. Evaluate local constraints. Firmware checks validity, usage limits, revocation information already received, and any configured operating conditions. Required conditions that cannot be established should trigger the documented denial or exception policy.
5. Record and actuate. The controller persistently records the authorization decision and updates consumption state before or transactionally with actuation. It then records the sensed outcome separately from the command.

That final distinction matters: an accepted credential does not prove that the mechanism opened, and an unlock command does not prove that an outlet was accessed. Audit records should distinguish authorization, actuator operation, and available position or tamper observations.

Replay protection needs persistent state

Encryption of the local radio link is useful, but it does not by itself stop someone from reusing a previously valid authorization. Likewise, a digital signature establishes authenticity and integrity, not freshness.

A fresh, unpredictable challenge can prevent replay of a recorded authentication exchange when the response is cryptographically bound to the challenge, device identity, and requested action. Single-use permissions additionally require the lock to remember which authorizations have been consumed. These controls address different risks and may be needed together.

Ask what happens if power fails immediately after credential acceptance. Used-token records, counters, and pending transactions must survive reboot without permitting another opening. A design that keeps replay state only in volatile memory can lose its protection when the battery is disconnected.

Expiry is only reliable when time is trustworthy

A time-bound credential requires a dependable time reference. The lock might maintain a protected real-time clock and periodically synchronize it through an authenticated channel. Firmware must also detect clock rollback and define behavior after battery depletion, clock reset, or excessive uncertainty.

A monotonic counter helps establish ordering, but does not independently establish calendar time. Similarly, a timestamp supplied by an operator’s phone should not be trusted merely because the phone is paired.

Evaluate expiry behavior at the edges, not just during normal operation:

• Does uncertainty near the expiry boundary cause denial, a limited grace period, or another explicit rule?
• Can resetting power or restoring old storage extend a credential’s usable life?
• Does a maximum offline interval stop cached permissions from remaining valid indefinitely?

Grace periods improve availability but enlarge the access window. They should be an explicit policy choice, not an undocumented workaround for clock drift.

The unavoidable limit: disconnected revocation

A fully isolated lock cannot learn that an otherwise valid credential was revoked seconds ago. No cryptographic algorithm removes that communication limit. Offline security therefore depends on bounding how long stale authority remains acceptable.

Set these limits according to operational exposure. A permission for one unloading operation can be narrower than a standing maintenance credential. Emergency access should use a separately defined, accountable process rather than a shared override code that bypasses normal controls.

Audit records and recovery after reconnection

Local logs should include the credential identifier, decision and denial reason, device identity, time with its confidence or synchronization status, sequence number, and relevant sensor events. Secret keys and reusable authentication secrets should not appear in logs.

Integrity protection and sequence continuity help detect alteration, deletion, or missing records. Storage also needs an explicit full-capacity policy: silently overwriting unuploaded security events may destroy evidence, while refusing all access can interrupt operations. The chosen behavior should be visible to operators.

After reconnection, the system should authenticate the server, upload queued events with acknowledgments and duplicate handling, and retrieve current policy, revocations, and key updates. Local records should remain available until durable receipt is confirmed. Reconciliation must preserve the distinction between what the lock knew at decision time and what the server learned later.

Evidence to request during technical evaluation

Request demonstrations with cellular service disabled, not merely screenshots showing an offline indicator. Include a copied credential, wrong-lock permission, expired token, repeated transaction, power interruption during authorization, uncertain clock, full log storage, and reconnection with pending events. Ask for the expected decision and recorded evidence for each test.

Hardware and firmware determine whether these rules withstand physical access. Review protected key storage, secure boot, signed firmware updates, rollback resistance, debug-interface controls, and local-interface authentication. Credential verification is only as dependable as the software enforcing it and the state it protects.

For petroleum service, separately verify hazardous-location suitability and any applicable equipment approvals against the actual installation and jurisdiction. Cybersecurity features do not establish ignition safety. A technically credible offline design should document both its security boundary and its operational failure behavior—especially when the clock, battery, credential, or communication path cannot be trusted.