Container Seal Numbers Need Chain-of-Custody Events, Not a Free-Text Field

A container seal number typed into a free-text field looks like a security control. In practice, it is often only a label: easy to mistype, overwrite, or copy forward, and disconnected from the person, place, and time at which the seal was actually handled.

That is inadequate for a control meant to reveal unauthorized access. A high-security seal can deter entry and make tampering visible, but it cannot prove an unbroken chain of custody on its own. The operational evidence comes from a sequence of verified events: application, inspection, handoff, replacement, break, and final disposition.

A Strong Seal Is Only the Starting Point

Seal selection matters. Inbound Logistics explains that ISO 17712 establishes uniform procedures for the use and acceptance of high-security mechanical seals on maritime containers and trailer loads. These seals are designed to resist casual removal and expose interference.

Yet physical strength does not answer the most important custody questions. Who applied the seal? Was its number checked against the shipping record? Was it intact at the terminal gate? If customs opened the container, who authorized the break and which replacement seal was applied?

Those questions matter in a worsening theft environment. FreightWaves reported that U.S. cargo theft rose 16% year over year in 2025. It also reported 645 incidents in the third quarter of 2025, a 29% year-over-year increase. A seal is useful evidence only when operations can distinguish an expected change from an unexplained one.

Model the Seal as Events, Not an Attribute

A transportation management system should not treat seal_number as one editable shipment attribute. It should create an append-only event whenever the seal's state changes.

Five event types cover the normal lifecycle:

• Applied: The container is closed and a specific seal is attached.
• Verified: A carrier, terminal, warehouse, or consignee confirms the number and condition without changing the seal.
• Broken: An authorized party removes the seal and records why.
• Replaced: A new seal follows an authorized opening, with an explicit link to the old number.
• Exception: The seal is missing, damaged, unreadable, mismatched, or otherwise suspect.

Every event should capture the shipment and equipment IDs, seal number and type, timestamp, geolocation or facility, actor identity and role, seal condition, and supporting photo. Application and replacement events should also record whether the seal is ISO 17712 compliant. Break and exception events need structured reason codes, notes, authorization, and the next required action.

This structure preserves history. A corrected typo does not erase the original entry, and a replacement does not make the prior seal disappear from the record.

Mismatches Must Stop the Workflow

The most dangerous design is a warning that users can ignore while the shipment continues. Inbound Logistics advises that containers with seal-security issues should not continue moving until the discrepancy is researched and resolved. That principle should become workflow logic.

At a terminal gate, the observed seal must match the last valid applied or replaced event. Before a customs release step, the system should confirm that every authorized inspection and resealing event is complete. At delivery, the consignee should verify both number and condition before breaking the seal.

A mismatch should place the move on security hold and block the next gate, customs, or delivery milestone. The TMS can then open an exception task, notify the designated security owner, and request evidence from the current custodian. This is not bureaucracy for its own sake. Allowing movement first and investigating later destroys location certainty and weakens any claim.

Photos Need Context

A seal photo is valuable, but an image stored in a shared folder is barely better than free text. The photo must belong to the event and show enough context to support verification: the legible seal number, closure hardware, visible container number where practical, and any signs of damage.

The system should preserve upload time, capture time when available, user identity, and location. It should reject an application or replacement event when the photographed number and entered number conflict. Barcode or optical-character recognition can reduce transcription errors, but the user should still confirm the result before submission.

The objective is not to collect more media. It is to make each image answer a custody question without forcing an investigator to search across email, chat, and local camera rolls.

Control Overrides Without Hiding Them

Legitimate exceptions happen. Customs may open a container. A seal can become damaged during handling. An emergency inspection may occur where the preferred seal type is unavailable. The control model must accommodate these events without turning “override” into an escape hatch.

Define a small set of authorized roles, such as security manager, customs coordinator, or facility supervisor. Require a reason code, written justification, evidence, and replacement plan. High-risk overrides should require approval by a second person. The event log should show who requested the override, who approved it, and which blocked milestone was released.

Reports should monitor missing verifications, repeated overrides by location or partner, replacement frequency, mismatches, seal types, and time spent on security hold. Patterns can expose weak training, poor seal inventory control, or a custody point that deserves investigation.

Build a Defensible Custody Record

The right control is simple in concept: do not ask for the current seal number; ask what happened to the seal. An ordered event history turns a small piece of hardware into operational evidence. It lets teams stop suspect freight before it moves, document authorized openings, and reconstruct custody without relying on memory.

CXTMS connects shipment milestones, equipment, documents, photos, users, and exception workflows in one transportation record. Request a CXTMS demo to see how event-based controls can strengthen container security from origin through delivery.