We are not a recordkeeper, and we built the product so we would not have to be.
Attestation answers a question about a machine at a moment in time. Answering it does not require us to remember the machine afterwards, and almost everything on this page is the work of making sure we do not.
For device attestation we hold an email address. It exists so you have an account to log into and somewhere to send a certificate. Everything else about the device has a date on which it is deleted.
This page is the companion to what we cannot do. That one lists what the evidence does not prove. This one lists what we do not keep. A company that publishes only its strengths has told you nothing you can check.
Three kinds of record
Whose data it is decides whether it expires
Not every row in our database is the same kind of thing, and treating them alike produces either a company that keeps too much or one that cannot issue an invoice.
Yours
Anything about you, your device or your machine as an operator, arriving through the ordinary paths. It expires. All of it. The schedule below gives each kind its own date, and the dates are not negotiable by us.
Ours
If you choose to help us by lending your device to our research, what that produces is ours and we keep it. That choice is a separate, explicit one — it is never the default, it is never bundled into attestation, and declining it changes nothing about the service you receive.
Required by law
Invoices and ledger entries. We keep them for as long as Kansas and the IRS require and no longer. An invoice records an amount and a date — it does not need to carry your device's identity, and ours do not.
The schedule
Yours, and it expires
Every row is deleted on the stated day whether or not anyone asks.
| What it is | Why we have it | Deleted | Status |
|---|---|---|---|
| Your email address | So an account exists to log into, and so a certificate has somewhere to go. | When you close the account. Invoices keep an amount and a date, never an address. | In force |
| Attestation evidence | The raw material a verdict was computed from. | 90 days, and immediately when you close the account. | Not yet enforced |
| Continuity record | One value per counter, per device — derived from what your device reported, not the reading itself — plus the date its current unbroken run began and when we last saw it. We do not accumulate a history — see below. | When you close the account, or after 90 days without the device attesting. | In force |
| Failed attestations | A device that could not prove something is how we learn what hardware does in the field. | 30 days. | In force |
| Device characterisation | What a model of device can and cannot prove. | 30 days, unless you have explicitly contributed it to our research. | Not yet enforced |
The continuity record deserves a paragraph of its own, because it is the one that sounds like a history. It is not one. We keep one value per counter, per device: not the counter your device reported, but a value derived from it under a key, stored as a value that cannot be read from the database alone. Beside it we keep the date the current unbroken run began and when we last saw the device. We do not accumulate a history — each reading replaces the one before it, and there is no record of what the counters were last week.
That is a change from what this page said until the evening of 5 October 2026, and what it replaced is worth stating rather than quietly removing. Until then we stored the counters as we received them, and anyone who took the database could read them. We also kept the date we first saw a device and a count of the times its run had broken. Those two columns are gone — dropped from the table, not hidden inside it — because we do not sell them and they were the part that most resembled a history. It went live at 20:46 UTC that evening and was verified on real hardware the following morning. In force
The deletion is the one row on this page we are willing to call enforced, so here is exactly what that rests on. The ninety-day sweep runs once a day and writes a line every time, including the days it deletes nothing, which is the cheapest proof we could give ourselves that it has not quietly stopped. The other half — the record going when you close your account — is deployed and covered by tests, but no account has yet closed in production, so we have not watched it happen. That distinction is the sort of thing a status tag flattens, which is why it is written out.
Now the limit of the new form, stated by us rather than found by you. The protection is against the database. That is its whole extent: a stolen backup, a leaked query result or a demand served on those rows yields values that cannot be turned back into your device’s counters by anyone holding only those rows. It is not protection against someone holding both the database and the key the values were derived under, and today both live on the same server. Hardware counters take only a small range of plausible values, so anyone with that key could test guesses until one matched. We will not call this a one-way record, because that would claim a strength the arrangement does not have. Putting the key somewhere it cannot be read alongside the database is the fix. Not yet built
A device that has not attested for ninety days loses its record, and that is not a limitation we regret. We did not watch the gap. A machine returning after three months of silence starts a new run, because telling you it had been unchanged the whole time would be a claim nobody can support.
The schedule
Ours, and it stays
One category, and it only exists if you put it there on purpose.
Lending your device to the research
Hardware attestation is poorly documented in public. Which claims a given handset reports, at what security level, which root its chain ends at — most of that exists nowhere you can look it up, and the only way to find out is to hold the device and spend the afternoon.
So there will be a way to help: run an attestation and contribute what it reveals about that model of hardware. What comes back is a fact about a model, not about you or your machine, which is why we may keep it.
It will be a separate decision, never a default, never bundled into attestation, and declining it will change nothing about the service.
This does not exist yet. It is described here because the retention schedule above refers to it, and a schedule that mentions a category nobody can see is the kind of gap this page exists to close.
The schedule
Required by law
Invoices and ledger entries, kept for the period Kansas and federal tax law require. We would keep them for less if we were allowed to.
What they contain is an amount, a date, an account and what was sold. They do not contain device identifiers, and the schedule above applies to your devices whether or not you have ever been invoiced.
Most of this page is not enforced yet, and we are not going to pretend otherwise.
The schedule above was decided on 4 October 2026. The code that deletes on those dates is being written now. Until each row says it is in force, assume the data is still there.
We are publishing it in this state on purpose. A retention schedule put up the day it becomes true, with no trace of what came before, tells a reader nothing about whether we are the kind of company that keeps its own rules. One published before it is true, with the gap marked, can be checked against us later.
Known today and being fixed: records had no expiry at all, a closed account kept its email address, and bundles issued to customers carried more of the operator's hardware evidence than they needed to. Each one is recorded and each has a fix in progress.
Your part
Asking us to delete something
You do not have to wait for a schedule. Write to privacy@svnkg.com and ask, and we will tell you what we hold and remove it.
A self-service control is coming and does not exist today, which means a request currently depends on a person reading mail. We would rather say that than imply a button that is not there.
The full Privacy Policy