The 4 most common mistakes in log retention

There are records. But are they any use?

Many businesses say "we keep logs", and they are right: somewhere, a file is growing. The question is whether that file will prove anything when the day comes. What Law 5651 expects from a public-access provider is that the accuracy and integrity of internal IP assignment records are preserved; not merely that they exist.

The four mistakes we see most often in the field are below. Next to each one we note which setting or screen in the Hotspot-Box panel prevents it.

Mistake 1: The records live only on the device

A log kept in the memory of a router or AP lives and dies with that device. It fails, gets factory-reset, is replaced or stolen, and two years of archive go with it. On top of that, most APs overwrite their oldest entries after a few days or a few thousand lines.

A single copy is not a copy.

Panel counterpart: the archive copy setting. The box sends each day's signed archive to a server you specify over SFTP or FTPS. The panel shows the target, the last successful transfer and any error. For a third copy, you put the ZIP you export from the panel onto offline media; we describe these three layers as the "3-2-1 rule" in a separate article.

Mistake 2: The records are unsigned

A plain text file can be edited by anyone. Deleting a line or changing a time takes seconds and leaves no trace. This does not mean you would alter a record in bad faith; it means you have no answer when the other side asks "how do we know it was not changed?".

An unsigned record is a disputable record.

Panel counterpart: the hash chain and the timestamp. The box takes a SHA-256 digest of each day's records, links it to the previous day's digest and obtains a timestamp from an RFC 3161 service. Only the digest is sent. If any row changes later, the chain breaks and verification in the panel shows it. The chain starts on the day the box is installed; earlier records are not signed retroactively, so note the switch-over date.

Mistake 3: The record is tied to no identity

A DHCP server's lease table says "this MAC address received this IP". But who was behind that MAC? On a guest network that opens without verification, there is no answer. The record exists but connects to nothing.

An anonymous record is half a record.

Panel counterpart: captive portal login methods. Before a guest gets online, they verify their phone with an SMS code; coupon, e-mail or registered-user login are the alternatives. Each session row carries that verification detail: the phone number is stored encrypted and shown masked in the panel, a coupon code or e-mail is written to the record. MAC, internal IP, session time and verification detail end up in the same row.

Two nuances. First, device memory relies on the MAC address and MAC randomisation on phones can defeat it; the guest simply verifies again and the record chain is unaffected. Second, if you hand out coupons, recording who received which coupon is your internal process; the box knows which session each coupon was used in.

Mistake 4: Deletion when the disk fills

When a device's memory or a server's disk fills up, many systems silently delete the oldest file or stop writing. Both are bad: the first shortens your retention period without telling you, the second cuts the record flow unnoticed. You usually learn about either months later, when someone asks.

Silent deletion is the most dangerous kind.

Panel counterpart: two separate mechanisms. First, the disk usage alarm: when the threshold is crossed, a warning arrives by e-mail, Telegram or webhook. Second, controlled retention: records are kept for 730 days, an expired day is deleted automatically and that deletion is written to the audit trail. So deletion does happen, but planned, scheduled and recorded. Because the period ended, not because the disk filled.

Four mistakes, one table

Mistake	Consequence	Prevented in the panel by
Device-only storage	Archive goes with the device	SFTP/FTPS copy, ZIP export
Unsigned records	Integrity cannot be proven	SHA-256 chain, RFC 3161 timestamp, verification
Not tied to an identity	Nobody knows who was behind the IP	SMS/coupon/e-mail verification, session row
Deletion on a full disk	Retention shrinks silently	Disk alarm, 730-day automatic deletion, audit trail

Do not add a fifth: never testing

All four mechanisms can be in place and still not work. The SFTP password was changed, the alarm e-mail lands in spam, the NTP server was blocked at the firewall. Five minutes in the panel once a month: were the latest timestamps obtained, are any days pending, when was the last SFTP transfer, and did you verify one day and look at the report?

In some settings (a unit inside a shopping mall, a residential complex, a shared office) who carries the record-keeping duty is debated. Get legal advice on that; the box keeps the same records in the same way regardless.

You can read about the box's record-keeping mechanism on the product page and the virtual machine option on the virtual appliance page.

This article is general information and is not legal advice.