Certificates

Every successful, verified wipe earns a certificate of erasure — issued as two cryptographically signed PDFs modeled on NIST SP 800-88r2, generated by AVERASE cloud and verifiable by anyone against the platform's records.

Certificates are produced only by the AVERASE web application. The bootable engine renders and signs nothing and carries no signing key — it reports the wipe's outcome, and the cloud does the certifying. That separation is what makes a certificate worth trusting: the evidence is signed by a key that never leaves the server.

Two documents, one record

A certifiable wipe result enqueues one generation job, and that job renders both documents from the same facts — the same certificate number, the same signature, the same signed_at. There is no state in which one exists without the other.

Neither document is a summary of the other in any weaker sense — both are covered by the same Ed25519 signature over the same canonical payload, so verifying one attests the facts printed on both.

When a certificate is issued

A wipe result is certifiable when both hold:

• wipe_status is completed, and
• validation is approved (a blank validation counts as approved).

Everything else persists on /wipes as evidence but does not certify:

One rule surprises people: a Clear wipe on solid-state media is always capped at review, even when its verification passes. NIST 800-88 is explicit that a logical overwrite cannot reach over-provisioned cells on flash, so the engine downgrades the validation to unverified with: "NIST 800-88: Clear overwrite cannot reach over-provisioned cells on solid-state media — validation capped at REVIEW (use Purge to certify flash)". Purge is the certifiable path for flash media.

When a certifiable wipe result arrives, generation is enqueued immediately and runs in the background — the /wipes Certificate column shows Pending → Generating → the finished CW-000123 link (or Failed if generation errored).

Certificate numbers

Each certificate gets a number that is unique per account and assigned under a lock, so the sequence is gap-free — your first certificate is number 1, your five-hundredth is number 500, with nothing missing in between. The printed reference formats it as CW-%06d: certificate 123 is CW-000123. Both documents carry it. (The cert_… prefixed id used in URLs is a separate, global identifier.)

The Certificate of Sanitization

A US Letter page mirroring NIST SP 800-88r2 Appendix C. The AVERASE wordmark sits top-left with CERTIFICATE OF SANITIZATION opposite it, above a meta line of the form AVERASE v<version> · Certificate No. CW-000123 · Generated <timestamp> UTC. Four sections follow.

Media Information

Sanitization Details

Sanitization Technician

The attestation statement, printed verbatim:

I attest that the data erasure process has been carried out in accordance with sanitization guidelines provided by the given specification.

Below it, Technician Name, Organization, Date (MM/DD/YYYY, filled in), and a ruled Signature line for wet ink.

Validator

Blank rows for independent quality-control sign-off, per the NIST form: Validator Name and Organization print — when no validator is recorded, with ruled lines for Date and Signature.

A footer closes the page: "This report is digitally protected to prevent tampering by AVERASE's development process. AVERASE is intellectual property of ©MAESON Technologies LLC."

The Erasure Report

The same wipe, in full. It carries the identical header and meta line, then lays seven sections out in two columns.

Sanitization Technician

The contact block the short certificate omits — all six fields come from the account's certificate profile.

Media Information

Everything on the certificate, plus the identifiers a technical audit asks for.

Sanitization Details

Verification

The section that makes the report worth keeping: not just that the wipe verified, but how much of the drive was re-read to prove it. See Verification & results for the mechanics.

Media Destination

Sanitization Attestation and Validator

Side by side. The attestation repeats the certificate's statement over Technician, Organization, Date, and a signature line. The Validator column states its purpose — "Independent secondary validation (NIST SP 800-88 verify/validate; R2v3 quality control) — completed by a person other than the technician" — over ruled lines for Validator Name, Organization, Date, and Signature.

Digital Protection

The report closes by printing what the signature covers: Certificate No. and Signed At. The printed block is a pointer, not the proof — the authority is the verify endpoint.

Where the fields come from

Nothing on either document is typed in at generation time. Every value is drawn from a record that already existed when the wipe finished:

Unset values print as — (or Unknown for Data Backed Up) rather than being omitted, so a reader can tell a blank field from a missing section. Hotswap-station wipes leave Source blank: drives pass through a chassis rather than living in one machine, so there is no source asset to match.

Cryptography

Three mechanisms protect a certificate's integrity. All three cover the record, so they cover both documents equally.

1. Ed25519 signature. The certificate's facts are serialized into a canonical payload with a fixed field order — certificate_number, account, drive_serial, drive_model, drive_capacity_gb, wipe_method, passes_completed, started_at, completed_at, verification_hash, signed_at — and signed with a dedicated Ed25519 key (separate from the device-token key). The public key is published alongside the signature, so verification never requires trusting the PDF itself.
2. HMAC tamper token. An independent HMAC-SHA256 over the same canonical payload, keyed by a server-side secret. The public verify endpoint recomputes it — any altered field flips the answer to "valid": false.
3. Verification hash. The payload embeds the wipe's own verification_hash — a SHA-256 over every byte the engine re-read from the drive during post-wipe verification — chaining the certificate to the physical evidence.

Because the signature covers the record rather than the file bytes, an edited PDF does not produce a different signature — it produces a document whose printed facts no longer match the ones the verify endpoint returns. Compare the two and the edit is obvious.

Storage and download

Finished PDFs live in private object storage (R2) — objects are never publicly listable or directly addressable. Downloading one goes through the web app, signed in and scoped to your account, and each request responds with a redirect to a presigned URL valid for 5 minutes:

If generation hasn't finished you're redirected back with "Certificate is still generating."

There is no certificate index page. /wipes is the certificate listing: its Certificate column links both documents for each certified wipe (opening in a new tab), shows Pending / Generating / Failed badges while in flight, and marks non-certifiable wipes "Not issued" with the tooltip "Certificates are only issued for successful, verified wipes".

A certificate_generated webhook fires when generation finishes, if you want to pull certificates into your own systems as they're issued.

Verify a certificate

curl https://averase.com/certificates/cert_abc123/verify

{
  "valid": true,
  "certificate_number": "CW-000241",
  "account": "MAESON Technologies LLC",
  "drive_serial": "S6MZNF1WA04527",
  "drive_model": "SAMSUNG MZVL2512HCJQ",
  "drive_capacity_gb": 512,
  "wipe_method": "NIST 800-88 R2 Purge",
  "passes_completed": 1,
  "completed_at": "2026-08-01T14:22:07Z",
  "signed_at": "2026-08-01T14:22:09Z"
}

{
  "valid": false,
  "certificate_number": "CW-000241",
  "account": "MAESON Technologies LLC",
  "drive_serial": "S6MZNF1WA04527",
  "drive_model": "SAMSUNG MZVL2512HCJQ",
  "drive_capacity_gb": 512,
  "wipe_method": "NIST 800-88 R2 Purge",
  "passes_completed": 1,
  "completed_at": "2026-08-01T14:22:07Z",
  "signed_at": "2026-08-01T14:22:09Z"
}

{
  "valid": false,
  "error": "not_found"
}

What's next?

• Wipes — the grid where certificates surface
• Certificate verification API — the endpoint in the API reference
• The wiping process — methods, techniques, and the verification that feeds the certificate
• Inventory — where Property Number, Classification, and Destination are edited
• Webhooks — get notified the moment a certificate is generated