Most security pages ask you to trust the operator. This one describes properties you can check in the open-source code: where data is processed, what is encrypted when, who holds keys, and what happens when things go wrong. The site-wide security policy covers reporting and response; this page covers the wallet itself.
On-device processing
Capture, liveness analysis and template creation run on your phone. At the Trusted level, fingerprint and iris capture happen inside your device's secure hardware — the enclave the operating system itself cannot read into — and the device proves its own integrity through Google Play Integrity or Apple App Attest. The principle, and why edge processing beats cloud matching categorically, is argued in biometrics: on-device vs in the cloud.
Encryption before movement
Nothing leaves your device in the clear. Payloads — document data, biometric templates, attestation material — are sealed with envelope encryption (X25519-XSalsa20-Poly1305) on the phone, travel over TLS 1.3, and rest under AES-256 with key rotation. The network stores encrypted payloads it cannot browse; the chain records encrypted references and signed results, never readable evidence.
Trusted processing units
Verification itself runs inside hardware-sealed enclaves — AMD SEV-SNP confidential VMs, Intel SGX, AWS Nitro — whose attestation the chain verifies before any data is released to them. The decryption key is derived inside the hardware and never exists outside it, so no operator, provider or foundation staff member has an access path. Raw data is destroyed when scoring ends; only the result leaves.
- Stage 1 Captured On your phone: document scan, selfie, liveness.
- Stage 2 Encrypted on your device Sealed before anything moves. Keys stay in your phone.
- Stage 3 Processed in a sealed enclave Hardware-attested. No operator can look inside.
- Stage 4 Raw data destroyed The enclave keeps nothing after scoring ends.
- Stage 5 Only the result remains A score and tier — never documents or biometrics.
The full explainer — the vault metaphor, what attestation proves, and the destruction timetable — is at trusted processing: the lock and the key.
Key handling
Your wallet is anchored by key pairs generated on your device, with private keys held in platform secure hardware where the design never exports them. Signing in to my.identity.org.au uses passkeys or device-bound credentials — a signature from that hardware, not a password. No shared secret exists, so there is nothing to phish, reuse or crack offline.
Revocation and deletion
Every consent is revocable at any time, immediately effective for all future processing, and recorded with a timestamp — the mechanics are in revoking consent. Deletion is real because it is cryptographic: when you delete your identity, data leaves active systems within 30 days and backups within the rotation period (typically 90 days), and encryption keys are destroyed — which makes any remaining ciphertext, including on-chain references, permanently unreadable.
If your device is lost or stolen
A thief holding your phone does not hold your identity. Biometric checks gate the wallet; keys sit in hardware they cannot extract; and from any browser you can sign in to the web wallet and end every session. On a new phone you re-establish control by re-verifying — fresh liveness against your enrolled identity — rather than by anyone's password reset.
What a breach could and could not expose
The system is designed so that a full compromise of its server-side infrastructure yields ciphertext without keys, verification results and consent records — not documents, not biometrics. No design makes attacks impossible; this one makes the worst case survivable. If a breach ever involved biometric data, affected people would be notified within 72 hours under the published breach response commitments.