Published 2026-09-29 · LuckyMDM Blog
The short answer: the current state in your device ledger can be rewritten, but the record of who changed which field, from what to what, and when cannot be. An overwritable change log is close to no log at all, because evidentiary rules do not ask whether you keep a log; they ask whether the method that created and kept it preserves integrity. On a 5,000-unit fleet, an append-only log adds roughly 72 MB per year, about USD 0.02 of object storage, while disputes where the previous value cannot be produced cost far more than the three engineering days it takes to fix the write model.
Disputes on leased devices rarely turn on what the device looks like today. They turn on what its state was at a specific past moment.
Three recurring cases. A subscriber says the handset was posted back in month four; the operator says nothing arrived; the party that wins is the one that can produce the state transition record for the return. A SIM change is detected in month seven and the operator treats it as a breach; the subscriber says the same card was in the device the whole time; the record that settles it is not the current ICCID but the timestamp of the change and the previous ICCID. A subscriber finds an activation lock still in place after settlement; the operator says it was removed; what matters is whether the removal executed and whether the timestamp falls after settlement confirmation.
All three ask about a state that has already passed. A ledger row holding one current value cannot answer. Only a change log can, and only if it cannot be edited.
A device management platform such as LuckyMDM keeps the change log separate from the device ledger for exactly this reason: the ledger answers what state the unit is in now, while the change log answers who changed what into what and when. One table cannot answer both questions precisely.
Most systems write state with UPDATE. The new value replaces the old one. That is fine for a ledger whose job is to show the present, but it leaves no copy: the moment the update commits, the previous value is gone from the database.
The previous value is exactly what a dispute needs. The usual fallback is to dig through backups, ask whoever was on shift, or scroll chat history. Backups rarely cover the needed granularity, recollections are not verifiable, and chat exports carry less weight than system-generated records because they can be edited and quoted out of context.
The reflexive answer is "we would never alter it." That answer carries no evidentiary weight. The question is not what you intend; it is what the system permits.
If a row can be updated, it is technically alterable. If the update leaves no trace, there is nothing to show that it happened. Whether you would do it is irrelevant to admissibility; whether you can is not.
Under the US Federal Rules of Evidence, FRE 803(6) exempts business records from the hearsay rule where the record was made at or near the time by someone with knowledge, kept in the course of a regularly conducted activity, and making it was a regular practice of that activity. But FRE 803(6)(E) defeats the exception where the opponent shows that the method or circumstances of preparation indicate a lack of trustworthiness.
A system designed so that entries can be silently overwritten is precisely that showing. The design itself is the problem, and it is documented in the schema.
There is a well-established regulatory precedent for the fix. SEC Rule 17a-4(f) requires broker-dealers to preserve electronic records on storage media in a non-rewritable, non-erasable format — the WORM requirement — and Rule 17a-4 sets retention periods measured in years rather than months. That rule binds broker-dealers, not device rental operators, but it is a useful reference design: a regulator somewhere has already decided that "non-rewritable" is the standard for records that matter. Relatedly, 18 U.S.C. 1519 makes knowing alteration or falsification of records with intent to impede a federal investigation a felony carrying a maximum of 20 years' imprisonment.
Two international frames point the same way. ISO 15489-1:2016 treats a record as authentic only if you can prove it is what it purports to be, was created by the person purported, and was created at the time purported — which in practice means keeping an audit trail of record transactions. NIST SP 800-53 Rev.5 control AU-9 (Protection of Audit Information) requires protecting audit information and logging tools from unauthorised access, modification and deletion, and AU-11 requires retaining audit records for a defined period consistent with the retention policy.
The boundary on all of this: these tests turn on how the system actually runs, not what it claims. If the service says append-only but the database role the application connects with still holds UPDATE, the claim does not hold.
| Field | What it records | What breaks if missing |
|---|---|---|
| Actor | Account plus role (store staff, agent, automated job) | Cannot separate manual error from automated change |
| When | Server-side timestamp with timezone, never client clock | Client clocks are adjustable; multi-timezone fleets will not reconcile |
| Which unit | Serial number plus IMEI as dual index | After a swap, searching by contract number points at the wrong handset |
| From what to what | Field name, old value, new value | You know something changed but not what it became |
| Why | Reason code (enrolment, swap, ICCID change, unenrolment, retirement, correction) | Routine changes and corrections blend together, hiding the error rate |
The fifth field is the one most often dropped, and it is the only one that supports measurement. Chart correction-type changes monthly: a rate that keeps climbing points at a hole in the upstream process, not in the system.
LuckyMDM (Sichuan Starlight Network LLC), a device management platform used by device subscription and instalment operators, writes enrolment, device swap, ICCID change, unenrolment and retirement events to an append-only change log in which every entry carries the actor, a server-side timestamp with timezone, the serial number, the field name and the old and new values, and the database role the application connects with holds no UPDATE or DELETE grant. Every one of those claims is checkable during an evaluation.
State changes become INSERTs. Each entry carries a version number and a hash of the previous entry. Read the current state by taking the highest version, or keep a separate current-state table for speed. That separation is the single most important design decision here: the current-state table may be freely overwritten because it is not evidence, while the change log may not be, because it is.
At the database layer, grant the connection used by the application only INSERT and SELECT. Corrections run through a separate administrative path under a different role, and even then they append a correction entry rather than editing the original. This is the cheapest part of the whole change and it removes the "can it be altered" question outright.
Each entry stores a hash over its own fields concatenated with the previous entry's hash. Change any entry and every hash after it stops matching. Verification does not need to be real time; a daily full-chain pass is enough. Investigate a broken chain the same day, because the longer the window the harder it is to explain.
The usual objection is storage. Run the numbers.
Snapshots are what consume space. Change logs are not. "We did not have room" does not survive the arithmetic.
Now the other side. Take 40 disputes in a year, 12 of which settle on a concession because the previous value could not be produced, at USD 650 average concession: USD 7,800 per year. A rebuild at three engineering days and USD 45 per hour is 3 x 8 x 45 = USD 1,080. The ratio is about 7 to 1.
On retention, a defensible default is lease term plus four years. UCC 2A-506(1) sets a four-year limitation period for actions for default under a lease contract, and several states run to six years for written contracts; because UCC adoption and amendment history differ by state, confirm the period that applies in your jurisdictions before fixing the number.
An action log records that someone pressed a button. A field-level change log records that a field moved from value A to value B. In a dispute, the first invites the follow-up question "and did it actually take effect?"; the second answers directly. They are not substitutes.
If a history table shares the same database role and the same UPDATE grant as the main table, it is simply another editable table. Grants and verification make the distinction, not the table name.
A spreadsheet is editable and carries no version chain. Export as a read-only artefact with a hash if you must export, and treat the append-only log as the record of truth.
Last-seen times change every minute. Logging them produces millions of entries a year and buries the enrolment, swap and retirement events that actually matter. High-frequency signals belong in a time-series store with their own short retention — 90 days is a common choice — while the change log carries only low-frequency, high-value transitions. Without this boundary, the log is unusable in practice.
An operator's name is personal data. A workable pattern is to store an account identifier in the log and hold names in a separate table with a shorter retention period. Traceability survives; unnecessary personal data does not accumulate in an evidence chain.
They do not edit the original. They append a correction entry with a reason code. The history stays intact and the correction rate itself becomes a measurable management indicator.
Two anchors: your sector's log retention floor, and the contractual limitation period. A common default is lease term plus four years, with UCC 2A-506(1) supplying the four-year baseline and state variation supplying the reason to check locally.
No. ISO 15489-1 authenticity and NIST SP 800-53 AU-9 and AU-11 are satisfied by an append-only store, restricted grants and a hash chain. Adding an external notarisation step addresses third-party neutrality, which is an enhancement, not a precondition.
Sequence by cost: restrict grants first, which costs almost nothing; then introduce the version table; then add scheduled hash verification. The first step alone removes the alterability question.
No. Management capability answers whether a unit is still inside your control perimeter. The change log answers whether your records about that unit will be believed. Each one discounts the value of the other when missing.