Last updated: 26 August 2026
v1.5, 26 August 2026
OneAddress is built on a zero-knowledge foundation. Your address is encrypted in your browser before it's ever stored, and service payloads are encrypted with each service's own key. Here's how every layer of the system protects your data.
The receiving organisations are formally called Participating Organisations in our agreement with each of them. This page calls them services, and our technical documentation and developer materials call them partners. All three terms are interchangeable and refer to the same organisations.
Because of our zero-knowledge architecture, OneAddress cannot:
Read your addresses, including in response to a court order: we hold no key that decrypts them and we have built no way to recover one. What we could be compelled to hand over is the encrypted data itself, which is of no use without your PIN or recovery code. Recover your vault PIN ourselves: only you know it, and we never hold a copy or a way to derive it. Access your vault data on our servers: it's encrypted ciphertext. Read the plaintext address payload after it is encrypted for a service: it is encrypted with the service's public key before leaving your browser. Tamper with your address data undetected: it is encrypted end-to-end with AES-256-GCM, whose authentication tag fails if the ciphertext is altered, and we do not hold the key needed to re-encrypt it.
One thing we will not overstate. A 6-digit PIN has a million possible values. We slow guessing down deliberately (600,000 rounds of key derivation per attempt), but anyone who obtained a copy of your stored ciphertext and was willing to spend real computing time could try every one of them offline. That is why we now offer a recovery code instead: it has close to 100 bits of randomness, which puts it beyond any such search. We would rather tell you where the limit actually sits than claim a guarantee the mathematics does not support.
Lost your PIN? If you saved the recovery code shown when you set up your vault, use it from the "Forgot PIN?" link on the vault unlock screen to set a new PIN, your vault, services, and address history are untouched. We can't recover your PIN ourselves, and we don't store your recovery code either, only your device (or wherever you saved it) holds it, so keep it somewhere safe. Without the recovery code, "Forgot PIN?" instead offers to wipe your vault: a confirmation code is sent to your registered email, and confirming permanently deletes your encrypted data (saved services, account references, and address history) so you can start fresh with a new PIN. Your account itself (email, payment history) is preserved either way.
A government-document verification with a liveness selfie is mandatory before every address dispatch, on both the account and guest flows. It is performed by Global Data Pty Ltd, an Australian identity service provider based in Melbourne and an approved Gateway Service Provider for the Australian Government's Document Verification Service (DVS). The verification includes a DVS cross-check against the issuing authority's records. OneAddress never receives or stores your photo or your document. We receive the result, a verification reference, and on a pass your verified name and date of birth. An address can only be sent on the strength of a successful verification, and each verification authorises at most one update: an immediate update requires a verification completed within the last 24 hours, while a scheduled move (which you can book up to 3 months ahead) is dispatched against the specific verification completed and reserved at the time you scheduled it. On the account flow your vault PIN is also re-entered at the moment you authorise the update, immediately before an immediate dispatch, or at scheduling time for a scheduled move, so an attacker who somehow obtained your session would still be blocked by both your PIN and an ID check. Full data-handling detail is in our Privacy Policy section 6.
OneAddress is designed to comply with: the Privacy Act 1988 (Cth) and Australian Privacy Principles (APPs); the Notifiable Data Breaches (NDB) scheme; and general data protection best practices. Some of our service organisations are subject to APRA prudential standards and financial-sector security requirements in their own right, our webhook security model (HMAC-SHA256 signing, ±5-minute replay window, ECDH per-service key isolation) is designed to meet the security expectations those services face. Our zero-knowledge architecture means a breach of our database would not expose any plaintext customer addresses.
We welcome reports from security researchers acting in good faith. If you believe you have found a vulnerability in OneAddress, email security@oneaddress.io with a clear description and reproduction steps. We aim to acknowledge reports within 2 business days.
In scope: the customer application (oneaddress.io), the service portal (services.oneaddress.io), our published service SDK, and our public API endpoints.
Out of scope: denial-of-service attacks, social engineering of OneAddress staff, physical attacks, and third-party services we depend on (Stripe, Neon, Resend, Cloudflare, Global Data, Vercel), please report issues with those to the providers directly.
Safe harbour: we will not pursue legal action against researchers who act in good faith, do not access customer data beyond what is needed to demonstrate the vulnerability, and give us a reasonable opportunity to remediate before public disclosure.
Bug bounty: we do not currently run a paid bug bounty programme. We will publicly acknowledge researchers who report valid vulnerabilities (with their consent) once the issue has been remediated.
Questions about our security architecture?
security@oneaddress.io