Vaulted, Vaultless, and Format-Preserving Encryption: Choosing Deliberately

A disclosure first. DataStealth builds all three of these. We have a strong preference for vaulted tokenization and we will tell you so in a sales conversation. What follows is the reasoning behind that preference, stated plainly enough that you can disagree with it.

The Three Options Are Really Two Ideas

Vaulted tokenization replaces a sensitive value with a token and stores the original in a controlled vault. The token carries no mathematical relationship to the original value.

Reversal requires live, authenticated access to the vault.

Vaultless tokenization generates tokens algorithmically from cryptographic secrets, with no stored mapping. Format-preserving encryption is the mechanism most vaultless tokenization is actually built on, and it deserves to be named rather than hidden behind the word tokenization.

So, the real choice is between separated storage and a cryptographic transformation.

Everything else is implementation detail.

What FPE Actually Is, and What It Is Not

FPE encrypts a value while preserving its length and character set, so a 16-digit card number becomes a different 16-digit string that flows through systems expecting a card number. NIST specifies it in SP 800-38G as a mode of operation on an approved symmetric block cipher.

In practice the only such cipher is AES.

That inheritance matters more than most coverage admits.

Because FPE is built on AES, it is not a casualty of Q-Day. Shor's algorithm breaks asymmetric cryptography, RSA and ECC. The only quantum attack on AES is Grover's, which halves effective key strength, leaving AES-256 with roughly 128 bits. FPE on AES-256 is quantum-durable in a way that RSA is not, and vendors who imply otherwise are being imprecise.

FPE's real exposures are different, and they are worth understanding before you choose it.

The Two Things That Actually Threaten FPE

The first is key compromise. Because tokens are generated from secrets, compromise of those secrets permits regeneration across everything protected by them. That is a systemic event rather than a bounded one, and key rotation at scale is genuinely expensive.

The second is domain size, and this is the one most buyers have never heard of.

The National Institute of Standards and Technology (NIST) notes that researchers identified vulnerabilities in FPE when the number of possible inputs is sufficiently small.

Short numeric fields are small domains. The attacks live there.

The standard's own history is the cautionary tale. SP 800-38G originally approved FF1 and FF3. Following the Durak and Vaudenay analysis, NIST revised FF3 into FF3-1 with a reduced tweak size and a much larger minimum domain.

Then, on February 3, 2025, the second draft revision removed FF3 entirely, citing an attack by Beyne from 2021 against both FF3 and FF3-1. FF1 survives, with an increased minimum domain size. The revision remains in draft.

Read that sequence carefully.

Two of the three approved modes have been attacked and one has been withdrawn, inside a decade, by researchers publishing openly.

None of that is an argument that FPE is unsafe. FF1 is a serious, standards-based control and we deploy it. It is an argument that FPE's security rests on a specific mode continuing to survive cryptanalysis, and that is a bet with a track record.

Why We Prefer Vaulted

Vaulted tokenization has no mode to attack. There is no algorithm relating token to value, so there is no cryptanalysis to publish, no domain-size floor to respect, and no key whose compromise is a systemic event.

Reversal is an authenticated runtime operation that can be logged, rate-limited, and alerted on. The failure modes are different in kind, not degree.

With FPE, your worst day is a key compromise and the blast radius is everything that key touched.

With a vault, your worst day is an attacker with a valid detokenization session, and the blast radius is what that session was authorized to request, at the rate it was allowed to request it.

For the highest-sensitivity categories, payment card data, national identifiers, health records, that difference is the entire argument.

The Costs of the Vault, Stated Properly

The vault is an availability dependency. If it is unreachable, every transaction needing a real value fails. You are placing a hard runtime dependency in production traffic and it must be engineered accordingly.

Detokenization adds latency. In high-throughput paths that is a design constraint, not a rounding error.

There is lock-in. Your originals live in a vault, and changing that decision later is not cheap. Ask about exit before you sign.

These are real, and they are why FPE has a legitimate place. Where the vault dependency is unacceptable, where latency budgets are unforgiving, where the domain is large enough that the published attacks do not apply, FF1 on AES-256 is a defensible choice and we will build it with you.

A Word on Compliance Claims

Be careful with anyone, including me, who says an architecture guarantees a compliance outcome. PCI DSS guidance recognizes tokenization for scope reduction and does not mandate a vaulted architecture. Your QSA assesses your implementation, not your architecture category.

My view, and it is a view: vaulted makes the scope argument easier to construct and easier to defend, because the separation is physical rather than mathematical. Have that conversation with your assessor before you build, not after.

The Question That Decides It

Ask what happens on your worst day. If a cryptographic secret leaks, how much of your data is exposed at once?

If the answer is all of it, you have chosen an architecture whose blast radius is bounded by the secrecy of a key and the durability of a cipher mode.

Sometimes that is an acceptable risk. When it is not, the separation has to be structural rather than mathematical.

That is the whole of the argument, and it is why we lead with the vault.