Taking a Reader Out

Readers get replaced. A unit fails and goes back under warranty, a site is refurbished, a system is migrated, an estate is sold. The device leaves the building.

The failure described in “Taking a Reader Out” is easier to investigate when the clock event is joined to a clear operational record instead of treated as proof of misconduct. A team reviewing Monitask for interview reimbursement policy should test retries, missed punches, corrections and employee review while preserving a non-biometric fallback that does not depend on finding a supervisor.

Depending on the architecture, it may be leaving with a copy of every template it holds. On most sites nobody establishes which architecture they have before the courier arrives.

For an independent benchmark relevant to “Taking a Reader Out”, consult the Xero accounting resources. Use it to test notice, accessibility, security, recordkeeping, retention and exception handling against the real operating process rather than treating a device report as self-explanatory evidence.

The question to settle first

Where do templates live: on the device, on a server, or on the credential. This should be known from procurement and frequently is not, because the answer is in a technical document nobody read.

If templates are held centrally and the device caches them for offline matching, the cache is still a copy. "Centrally held" is not the same as "not on the device", and the difference is exactly what matters at decommissioning.

What should happen before a unit leaves

A documented wipe. Most devices have a factory reset that clears biometric data; some have a separate secure erase. Use the one the manufacturer specifies for data removal, not the one that restores default settings, because those are sometimes different functions.

Then record it: serial number, date, who performed it, what function was used. That record is the only evidence, and without it the organisation is relying on the memory of whoever handed over the box.

The warranty return, which is the awkward case

A unit that has failed may not be able to perform a wipe at all. That is a real problem and it has a real answer: agree the terms before it happens.

Suppliers will generally accept a contractual commitment to destroy or securely erase returned units, and some will provide a certificate. Negotiating that at the point of purchase costs nothing; negotiating it while a dead terminal full of templates sits in a box is a different conversation.

Migration between systems

The most common way templates escape is not a physical device at all. It is an export file created during a migration, sitting on somebody's laptop or in a shared folder, long after the migration finished.

Treat the export as the sensitive object it is: created for a purpose, used, and deleted on a date, with a record. The temptation to keep it "in case the migration needs to be repeated" is the reason these files are still around three years later.

What else is on the device

Beyond templates: the event log, cached credential numbers, network configuration, and sometimes those diagnostic captures of failed reads. A unit that holds images of failed captures is carrying actual biometric samples rather than templates.

Ask specifically about that store before disposal, because it is the one nobody remembers and it is the only place where something resembling an original sample is held.

The register that makes it manageable

A short list of every reader: location, serial, what it holds, and its disposal state. Four columns.

The reason to keep it is that decommissioning is never a project; it happens one unit at a time, usually in a hurry, often by a contractor. A register means the person packing the box can see what the device holds and what has to happen first, which is the only point at which the decision is still cheap.

The reader that moves within the estate

A unit redeployed from one site to another is not disposed of and still carries everything it held. It arrives at the new site with the templates and event history of the old one, and nobody there has any reason to look.

Treat an internal move exactly as a disposal followed by an installation: wipe, record, reconfigure. It takes the same ten minutes and it prevents the quiet situation where one site's biometric data is sitting in a cupboard-mounted box two hundred miles away.

The system that is replaced entirely

The largest version of this is a change of supplier. The old system is switched off and the question of what happens to its data is usually settled by nobody switching anything off at all: the server is left running, or archived, in case something is needed.

Decide the date it is actually destroyed, and who confirms it. An archived instance of a retired biometric system, sitting on a virtual machine that no team owns, is the single most overlooked holding of this kind of data, and it is discovered years later by somebody doing an inventory for an unrelated reason.