How we keep your identities and data safe

Every identity we issue — whether a code or a chip tag — is derived from a cryptographically secure random source. We use unique 32-character tokens with collision checking at scale: even with 100 million codes in production, the probability of a duplicate is effectively zero.

Identities are generated server-side. No client, application, or third-party integration can allocate an identity that the platform has not recorded, which removes whole classes of enumeration and prediction attack from the model.

Chip identities use NXP 13.56 MHz HF, ISO 14443-compliant secure elements with password-locked user memory — a 32-bit password, a 32-bit pack, and a configured AUTH0 lock byte.

The authenticator is a credential that rotates on every successful verification and expires within sixty seconds. It is not the chip UID, which can be programmed by a counterfeiter, and it is not the public URL record, which is intended to be readable by anyone holding the product.

Because the credential lives in protected memory, a passive reader extracts nothing of value from the tag. Cloning requires the genuine tag to be read in real time, which defeats the purpose of the counterfeit.

The full architecture is described on the ChipTech page.

• All data at rest is encrypted with AES-256, with keys held separately from the data they protect.
• All data in transit is encrypted with TLS 1.3.
• Account passwords are hashed with bcrypt at cost factor 12. Plaintext passwords are never persisted or logged.
• Database access requires short-lived signed tokens that expire every 15 minutes.
• Data is backed up nightly to encrypted, geographically separate storage on a rolling 30-day window.
• Payment card data never reaches our infrastructure — it is held directly by the payment processor.

Only a small number of named engineers hold production access. That access requires hardware-backed multi-factor authentication, is time-bound, and every production query is logged and reviewed.

Access is reviewed quarterly. Leavers are removed from production systems on their last day, and access is re-attested each cycle.

Secrets — signing keys, database credentials, and API tokens — are held in a managed secret store and rotated on a defined schedule, and immediately on any suspected exposure.

The platform runs on third-party cloud infrastructure. We treat that dependency as an accountable risk: every provider handling personal data is contractually bound to our instructions, assessed before onboarding and on a recurring cycle, and limited to the data required for its function. The full arrangement is described in Section 04 of our Privacy Policy.

On our own systems, dependency vulnerabilities are scanned on every build and critical findings block release. Runtime patching, container image rebuilds, and independent security testing are part of the standard release cycle rather than an annual exercise.

Container images are pinned to a known-good base with the runtime kept within its supported release line, and images are rebuilt regularly so that security patches reach production on a predictable cadence.

We maintain a documented incident response plan covering detection, triage, containment, eradication, recovery, and notification. Suspected or confirmed breaches are escalated immediately to the responsible owners.

An incident at one of our subprocessors is treated as our incident. We do not wait for a provider’s investigation to complete before containing access. We notify affected customers without undue delay and in any event within 72 hours of becoming aware of a breach affecting their data, and we notify supervisory authorities within the statutory deadline, on our own initiative.

The notification process, including what we publish about an incident, is set out in Section 06 of our Privacy Policy.

We satisfy audit obligations in the first instance by providing documentation. On request, and under confidentiality, we will share:

• Our current SOC 2 Type II report once certification is complete, or a summary of the controls in scope and the auditor’s opinion to date while it is in progress.
• A summary of the most recent independent penetration test, with findings and remediation status, subject to redaction of information that would weaken the platform.
• A summary of our vulnerability-management and patch-cadence practice, and our incident-response plan.
• Our current subprocessor list, with purpose and data held, as published in our Privacy Policy.

Where that documentation is not sufficient to satisfy your diligence, you may carry out an audit on at least 30 days’ written notice, no more than once per calendar year except following a personal data breach, during normal business hours, at your own cost, subject to a written confidentiality undertaking and to not disrupting the service.

We operate a managed bug-bounty programme and we work with external researchers. Report any suspected vulnerability or unauthorised access to [email protected].

We acknowledge reports within one business day and keep reporters informed as the investigation progresses. We ask that you avoid accessing data belonging to other customers, avoid service disruption, and give us reasonable time to remediate before public disclosure. We do not pursue legal action against good-faith research that respects those boundaries.