Trust & Compliance
Security at WipeCert
Our trust model, key management, data flows, and disclosure policy. The information here is what auditors and security review teams ask for — documented in plain language, sourced from production reality, no marketing fluff.
Trust Model
Anyone can verify a certificate without trusting WipeCert.
Every wipe certificate is signed with Ed25519 (RFC 8032) over the certificate's canonical JSON form (RFC 8785, JCS). The public verification key is published as JWKS at /.well-known/jwks.json. Three implications:
- No CA, no key escrow.Customers and auditors verify against our published JWKS directly. There is no third party we trust on our customers' behalf.
- Tampering is detectable. Any change to the certificate body — one byte in a serial number, one digit in the hash — invalidates the signature.
- Offline verification works. Auditors can re-verify a certificate years after the fact using only the PDF, the public key, and the documented algorithm. No WipeCert API call required.
const { createPublicKey, verify } = require("node:crypto");
const canonicalize = require("canonicalize");
const jwk = await fetch("https://wipecert.com/.well-known/jwks.json").then(r => r.json()).then(j => j.keys.find(k => k.kid === payload.kid));
const ok = verify(null, Buffer.from(canonicalize(payload), "utf8"), createPublicKey({ key: jwk, format: "jwk" }), Buffer.from(signature, "base64url"));Key Management
Where the signing key lives.
kid field). Future rotations append a new key to the JWKS without invalidating older signatures — verifiers select by kid."use": "verification-only"), re-sign affected certificates, post incident notice on /status.Data Flows
What we collect, where it lives.
WipeCert stores three kinds of customer data in a managed Postgres database (US-East AWS region), with row-level security gated by organization_id:
GET /api/account/export. Returns JSON in a documented format. To request deletion instead, email privacy@wipecert.com from the account's registered email — we respond within 30 days.Standards
What we align with.
NIST SP 800-88 Rev. 1
Media sanitization (Clear, Purge, Destroy)
ISO/IEC 27040
Storage security and sanitization
DoD 5220.22-M
Multi-pass overwrite (legacy support)
RFC 8785 (JCS)
JSON canonicalization for signing
RFC 8032 (EdDSA)
Ed25519 detached signatures
GDPR Art. 17
Right to erasure (data subject requests)
HIPAA §164.310(d)(2)
Disposal of electronic PHI
WipeCert is not currently SOC 2 Type II audited. We will publish the attestation on this page once the audit completes.
Subprocessors
Vendors with access to customer data.
We maintain a current list of subprocessors with their purpose, region, and DPA links. Customers and auditors can request the full list at any time by emailing privacy@wipecert.com from a verified account email or under an executed mutual NDA.
Enterprise customers receive subprocessor change notifications with at least 30 days' notice as part of their data processing agreement.
Application Security
How the dashboard and API are hardened.
/auth/mfa/enroll.x-api-key header on agent endpoints. Keys are stored as bcrypt hashes; the plaintext is shown exactly once at generation.organization_id. The service-role key is only used by trusted server-side handlers (webhooks, agent APIs).X-Frame-Options: DENY at the platform edge.Vulnerability Disclosure
If you find something, tell us.
We welcome reports from security researchers. Please email security@wipecert.com with:
- A description of the issue and the affected endpoint or page
- Steps to reproduce (curl or browser)
- Impact assessment in your own words
- Your contact information for follow-up
We acknowledge reports within 2 business days, triage within 5, and aim to patch critical issues within 14 days. We will not pursue legal action against researchers acting in good faith — please don't pivot beyond the proof of concept, don't exfiltrate other customers' data, and don't test against accounts you don't own.