Three ways to stop holding an identifier, routinely treated as interchangeable and not remotely so. The question that separates them is not how strong each one is. It is what you can still do afterwards, and who can undo it.
Talk to our technical team → — for integration questions, a security review or a volume estimate.
Do you need to match records afterwards, and do you ever need the original value back? Those two answers pick the approach; everything else is detail.
Most teams reach for encryption because it is familiar, then discover the compliance position has not moved: they still hold the data, and now they also hold a key that must be rotated, escrowed and audited.
| Redaction | One-way token | Vault token | Encryption | |
|---|---|---|---|---|
| Reversible | No | No | Yes, by the vault | Yes, with the key |
| Records still join | No | Yes | Yes | Only with deterministic mode |
| You still hold the value | No | No | Yes, in the vault | Yes, as ciphertext |
| Breach of that store yields | Nothing | Nothing | Everything | Everything, given the key |
| Key management | None | One server secret | Full lifecycle | Full lifecycle |
| Preserves format | No | No | Optionally | Only with FPE |
| Safe to send to a third party | Yes | Yes | The token, yes | Ciphertext, but they cannot use it |
“Tokenization” is sold as one thing and is really two, with opposite risk profiles.
Ask any tokenization vendor one question: can you return the original value? If yes, they are holding it, and everything that follows from that is now part of your threat model. If no, you cannot recover it either — decide before you tokenize a decade of records.
If tokens are derived from a single global secret, the same identifier produces the same token for every customer of that provider. Two organisations comparing token lists could then match individuals across their databases without either ever holding the identifier.
That is precisely the property that made the raw identifier dangerous in the first place — a national ID number is harmful mostly because it is a key that joins across otherwise unrelated systems. A globally-salted token rebuilds that key and calls it privacy.
A general principle, then the caveat that matters more.
Redaction and one-way tokenization remove the value from your systems. Encryption and vault tokenization keep it in a protected form, so obligations that attach to holding personal data generally still apply — and if a third party holds the key or the vault, that relationship is usually in scope too.
Two of the four, deliberately.
There is no reversible vault here and that is a decision rather than a gap: a vault would mean holding identifiers, which would contradict the retention position the rest of the product rests on. If you need the value back, you need a different tool, and you should be told that plainly rather than sold this one.
curl -X POST https://api.maskaadhaar.com/api/v1/tokenize \
-H "X-API-Key: $MASKAADHAAR_KEY" \
-F "file=@document.pdf" \
-F "types=global"
{"success": true, "reversible": false,
"tokens": [{"type": "iban", "token": "iban_a07945e8a890"}]}
Which identifiers it looks for is configurable; the full list and the checksum behind each one is on the identifier reference.
Encryption is reversible by design and the ciphertext is mathematically related to the value, so whoever holds the key holds the data. Tokenization replaces the value with an unrelated substitute; whether it can be reversed depends on whether a mapping is stored. A one-way token has no mapping and cannot be reversed by anyone, including the vendor.
Only if the provider stores a mapping. Vault-based tokenization keeps the original value and can return it, which makes the vault the most sensitive thing in the system. Derived tokens are an HMAC of the value under a secret salt, with nothing stored, and are irreversible by construction.
Yes, if the token is deterministic: the same input always produces the same token, so joins and duplicate detection still work. That is usually the reason tokenization is chosen over redaction, which removes the value entirely and takes the join key with it.
Redaction and one-way tokenization both remove the value from your systems. Encryption and vault-based tokenization keep it, in a protected form, so the obligations that attach to holding the data generally still apply. Check the specific framework rather than the general principle, and check who holds the key.
No. If a token is derived from a single global secret, the same identifier produces the same token for every customer, which turns the token into a cross-organisation correlation key — the exact property that made the raw identifier dangerous. Salting per customer prevents it.
Tell us what you need to be able to do with the data afterwards and we will tell you which of these fits — including when the answer is not us.