Nabel Solutions

Serial Xtractor™

The intelligence layer for asset identification

Live in beta

Scanners have read barcodes and text for years. The hard part was never reading the label. It was knowing what was worth recording.

What happens on a scan

In under a second it captures and identifies the serial number. Against a target list that's the whole cycle — a match saves immediately and automatically. Without a target list, you configure the operator review time.

  1. Scan

    The unit captures an image of the device.

  2. Xtract

    Barcodes and printed text are read. The serial number is identified. Everything is recorded.

  3. Destroy

    With an immutable and auditable record.

You decide how much supervision it gets

The serial shows before it's written. Your operator has a configurable timeframe for review. Say nothing and it records.

Target list

Scanning against a list of expected assets, an exact match records immediately. On to the next device.

Review window

No list, or no match — the serial is automatically identified and presented for operator review.

Held for review

Anything it can't read confidently waits for operator review. A held asset is a failsafe, not a fault.

A wrong serial is worse than a missing one. Nothing gets invented to force a match. Everything is recorded and searchable.

What comes out

Every session produces a timestamped certificate and an immutable manifest. Your certificate, your client's compliant record.

An integration that writes serials straight into your own system is in development — see the API.

  • Your organization and your customer
  • Date and time
  • Serial, model and device type
  • Destruction method
  • Total devices by category
  • An image of each asset
  • Verification signature — that sanitization ran on this device
  • Validation signature — that the method is sound for this media
  • A QR code anyone can use to verify the certificate

A record that can't be quietly changed

Every scan is chained to the one before it. Each entry's hash includes the previous entry's, so removing a scan, reordering them or altering a captured serial breaks the chain and fails verification.

When the certificate is issued we sign the session's final chain digest. One signature seals the whole chain, and nothing on the certificate can be altered afterwards without that signature breaking.

This is what chain of custody means in practice. A spreadsheet can be edited by anyone who opens it, and nothing about it says so.

  • Written once, never edited — corrections are new entries, not overwrites
  • Each entry is bound to the one before it by its hash
  • The certificate is signed against the whole chain, not typed alongside it
  • Every entry keeps its capture, its readings and the operator decision

Your auditor doesn't have to trust us

Every certificate carries a QR code. It resolves to a public page that checks the signature against our published key and reports a match or a mismatch.

No account, no API key, no relationship with us. The public key is published at a stable address, so an auditor who has already pinned it does not even need to load the page.

Scan capture times come from the device's own clock, because that is what an operator on a warehouse floor has. The cryptographically anchored moment is when the batch was signed, and we would rather say which is which than imply both.

  • Signed with a published key, so anyone holding the certificate can check it
  • Timestamped by an independent time authority, embedded in the certificate
  • The signature covers the whole scan chain, so a removed or reordered scan fails too

What we can and cannot do

We hold the signing key and we operate the database. So the honest claim is not that we cannot alter a record. It is that we cannot alter one quietly.

  • Alter a scan and the chain breaks the next time that session is read.
  • Alter a certified session and the signature fails on every copy of the certificate already in your hands.
  • Issue a second certificate under the same number and the first stays valid — two conflicting signed documents is itself evidence.

Customer-held keys and hardware key custody are on the roadmap, tied to compliance-heavy deployments. Today the trust boundary is where this says it is.

Two people, two devices, neither of them ours

The operator is a signed-in user in your organization. The witness gets a link, opens the manifest on their own device, and attests to what they saw.

Their attestation records the session digest at the moment they saw it, the time, and the device it came from. Both are embedded in the signed certificate.

What this is not, yet — two cryptographic signatures backed by keys your own people hold. That is a passkey rollout still on the roadmap. Today it is two independent parties attesting from two devices we do not control, which is the separation an assessor is asking about when they ask who witnessed it.

  • The witness needs no account and no app — a link and their own phone
  • Neither device is controlled by us
  • The attestation is bound to the same digest the certificate is signed against

Questions

How accurate is it?

Our target is 99.99%. Going into beta, with a target list our accuracy is 100%. Without one, Serial Xtractor correctly identifies the serial without help on 79.6% of devices. All reads without a target list wait for a configurable amount of time for for operator intervention, mitigating wrong serial number written to your manifest. The figure improves as we develop the model.

How do we know a record hasn't been altered?

Each scan is chained to the one before it by its hash, and the certificate is signed against the final digest of that chain. Removing a scan, reordering them or changing a serial breaks the chain and fails verification. Altering anything after issue breaks the signature on every copy of the certificate already in your hands.

Can Nabel forge a record?

Not quietly, and we would rather answer this plainly than let you wonder. We hold the signing key and we operate the database, so the honest claim is not that we cannot alter a record — it is that we cannot alter one without it being provable. Altering a scan breaks the chain. Altering a certified session invalidates the signature on copies you already hold. Issuing a second certificate under the same number leaves the first still valid, and two conflicting signed documents is itself evidence. Customer-held keys are on the roadmap.

Can our auditor verify a certificate without involving you?

Yes. Every certificate carries a QR code that resolves to a public verification page, which checks the signature against our published public key. No account, no API credential and no relationship with us. An auditor who has pinned our public key in advance does not need to load the page at all. Your auditor does not have to trust us, and does not have to trust you.

Who witnesses a destruction, and how is that recorded?

The operator is a signed-in user in your organization. The witness gets a link, opens the manifest on their own device and attests to what they saw — the session digest at that moment, the time, and the device it came from. Both attestations are embedded in the signed certificate. Two independent parties, two devices, neither controlled by us. It is not yet two cryptographic signatures backed by keys your own people hold; that is on the roadmap and we will not describe it as more than it is.

What does the equipment do with our clients' data?

It depends on the deployment. The offline deployments — secure tablet, fixed mount and on-shredder — have no connectivity. Nothing reaches us, and records leave only when your operator exports them. The mobile app is a connected product: scanning works offline, but it is backed by a cloud service we operate, and sessions, captured images, serials and record entries are held there. If your client's policy will not allow that, the offline deployments exist for exactly that reason. Our privacy notice sets out what the app's service holds. Get in touch to find out more.

Where is the app's data held?

In the United States. Our platform provider runs it on AWS in US-East-2, on infrastructure certified to ISO/IEC 27001 and covered by SOC 2 reporting. To be exact about whose certification that is: it is our provider's, not ours. Nabel Solutions does not yet hold ISO 27001 certification or a SOC 2 report of its own — what we can tell you is that the ground it runs on is independently audited. Our privacy notice names every company that touches your data.

Who designed how our data is handled?

On competence rather than certification: the product's data handling was designed by an ISO/IEC 27001:2022 Lead Implementer who also holds CISSP, CISM and CRISC. Those are individual credentials, held by people rather than by the company — but they are why the design looks the way it does.

Is the app's data backed up?

Yes, frequently, on our infrastructure provider's certified infrastructure.

Can we keep everything on site instead?

Yes. The secure tablet, the fixed mount and the on-shredder unit have no connectivity at all — nothing reaches us, and records leave only when your operator exports them. If a client's policy will not allow asset images and serials on a third party's infrastructure, those deployments exist for exactly that reason. Need a connected on-prem solution, or need it on independent infrastructure, reach out to discuss.

Can it write into the ITAD ERP we already use?

It can but it doesn't, yet. We are looking for integration partners now. Today the record is exported by your operator; the API puts the serial into your system of record as the scan happens instead. If you run an ERP, or built one, get in touch.

We have procurement or security requirements. Who do we talk to?

Us, directly. Get in touch.

How is this different from the barcode scanner we already have?

A barcode scanner gives you every code on the label or a single code but leaves your technician to work out which is the serial. Xtractor identifies the serial itself in a single capture in less than 1 second. That one step is the difference between ~10 seconds an asset and under 1.

What if a device has no barcode at all?

It reads printed text as well, and identifies the serial from that.

Does it need an internet connection?

The offline deployments never do — they ship with no connectivity at all. The mobile app scans without a connection, but needs one to export a manifest and to reach the service behind it. If you need capture and export to work with no network whatsoever, choose an offline deployment.

Can it save a serial without anyone checking it?

Yes, and that is the point — but you control it. You set how many seconds your operator gets to stop a serial before it saves. Set that to zero for hands-off running, or longer if you want eyes on every asset.

What happens when it cannot read a label?

It holds the asset for a person rather than guessing.

Whose name is on the certificate?

Yours. It is your document, issued by your organization to your client.

Will it work on the devices we actually handle?

Only one way to know, give it a try for free on the mobile app.

What does it cost?

It depends on how many stations you need and how you would rather pay for them. Get in touch and we will give you a straight number.

Try it on your own labels

A demo on our devices tells you little about yours. That's the test worth running.

We're on a mission to bring automation to ITAD

Interested in hearing more, or got something you'd like to talk through? Get in touch.