Vault vs Vaultless Tokenization: What Is the Difference?
Vault tokenization stores original data in a central vault and maps it to a random token, whereas vaultless tokenization uses format-preserving encryption to create tokens without storing raw data.
In vault vs vaultless tokenization, the core difference is where reversal happens: a vault looks the token up in a protected database, while a vaultless system reverses it mathematically with a key.
Both models swap a sensitive value, such as an SSN, bank account number or card number, for a token that applications can store and pass around safely. They part ways on how that token is created, how the original comes back and what an attacker would need to steal.
| Factor | Vault-based tokenization | Vaultless tokenization |
|---|---|---|
| Data storage | Original values and token mappings are kept, encrypted, in a central vault | No original values or mappings are stored anywhere |
| Token generation | Random values from a cryptographically secure generator | Calculated from the value with format-preserving encryption (FPE) and a key |
| Data format | Random by default, with deterministic or format-preserving options | Keeps the original length and character set by design |
| Reversibility | Authorized lookup in the vault; no mathematical path back | Decryption with the secret key, often inside an HSM |
| Security and breach risk | The vault is a high-value target; stolen tokens are useless | No store to breach; a leaked key reverses every token |
| Performance and scale | One network lookup per detokenization; capacity grows with the vault | Computed locally; throughput grows with compute |
| Infrastructure and maintenance | Vault storage, backups, replication and recovery | HSMs or a key management service, plus key operations |
| Key management | Handled behind the vault's API, with keys never exposed to applications | Central to security; rotation and access control are critical |
| Compliance scope | Token-only systems are usually easier to keep out of PCI DSS scope | Systems that can reach the key stay in scope |
| Deletion and data residency | Delete one record to retire its tokens; originals can stay in regional vaults | No record to delete; keys and algorithms must exist in every region |
In short, vault vs vaultless tokenization comes down to trust. One model relies on a well-guarded store, and the other relies on a well-guarded key. Here's what each factor means in practice.
Data Storage
A vault keeps every original value, encrypted, in one protected store, alongside the mapping that links each value to its token. That store sits outside the applications that use the tokens and needs backups, replication and strict access rules.
Nothing is stored in a vaultless system. The original value exists only at the moment of tokenization and again whenever an authorized system decrypts a token. With no database of raw records, there's no central repository for an attacker to target, which is the main reason teams consider vaultless designs.
Token Generation
Vault tokens come from a cryptographically secure random number generator. Two tokens reveal nothing about each other or about the values behind them, and no amount of computing power can derive the original from the token alone.
Calculation replaces randomness in vaultless designs. A format-preserving encryption algorithm, usually NIST's FF1 mode, takes the value and a secret key and produces the token. The same input with the same key always gives the same output, so vaultless tokens are deterministic by nature.
Data Format
Format matters most to teams with rigid legacy databases. Vaultless tokens keep the original structure automatically:
- A 16-digit card number becomes another 16-digit string.
- A 9-digit SSN stays 9 digits.
- Fields with fixed lengths and validation rules accept the token without code changes.
Vault tokens are random strings by default. Many vaults can also issue format-preserving or deterministic tokens when a field or a matching workflow requires them.
Reversibility
Reversing a vault token is a lookup. An authorized service sends the token, the vault checks the request against its access policies and returns the original or forwards it to an approved destination. Because the token is random, there's no other way back.
Vaultless reversal is decryption. Any system that can use the key, usually through an HSM or key management service, can turn the token back into the original value on the spot. Control therefore depends entirely on who can reach the key.
Security and Breach Risk
Each model has a different worst case.
Vault-based: the vault holds every original value, so it's a high-value target. The scenario to defend against is a breach of the vault itself or of credentials with broad access to it, which well-run vaults manage with encryption, isolation, scoped access and monitoring.
Vaultless: there's no store to breach, so the risk moves to the key. If the key is mismanaged or compromised, every token created with it can be reversed, including copies sitting in backups, logs and partner systems.
Performance and Scale
Vault-based tokenization needs a network call for each detokenization request, and the vault has to scale and replicate as data grows. For most business workloads, batch requests and fast lookups keep latency well within acceptable limits.
Throughput works differently without a vault. Tokens are created and reversed locally, with no shared store to query, so throughput grows with compute. That advantage matters most for payment processors and platforms handling thousands of real-time transactions per second.
Infrastructure and Maintenance
Neither model is maintenance-free. The work sits in different places:
| Area | Vault-based | Vaultless |
|---|---|---|
| Core infrastructure | Vault storage, backups, replication, disaster recovery | HSMs or a key management service |
| Ongoing tasks | Capacity planning, access reviews, recovery testing | Key rotation, key access reviews, algorithm updates |
| Typical owner | The provider, when the vault is a managed service | Often an internal team, unless keys are fully managed |
Key Management
Encryption keys inside a vault protect the stored values and never leave the vault's boundary. Applications only handle tokens, so a compromised application server exposes no keys.
For vaultless systems, the key is the security model. It has to be stored in protected hardware, rotated on a schedule and limited to the smallest possible set of services. Algorithm choice matters too: NIST's revised draft of SP 800-38G, published in January 2025, drops the FF3 mode and keeps FF1, so systems built on FF3 or FF3-1 face a migration.
Compliance Scope
Both models aim to keep cardholder data and other regulated values out of as many systems as possible. Systems that hold only random vault tokens and can't detokenize are generally easier to place outside PCI DSS scope. With vaultless tokens, assessors also look at which systems can reach the key, because the token and the key together reveal the original value.
Deletion and Data Residency
Privacy laws such as GDPR, CCPA and DPDP give people the right to have their data erased. In a vault, deleting one record retires every token that points to it, wherever those tokens live. A vaultless design has no record to remove, so erasure means finding every copy of a person's tokens or rotating keys.
Residency follows the same pattern. A vault can keep originals in regional stores while tokens travel freely. A vaultless system has to deploy its keys and algorithms in every region where data must stay.
What Is Vault-Based Tokenization and How Does It Work?
Vault-based tokenization is a method that stores each original value in an encrypted token vault and returns a randomly generated token that has no mathematical relationship to the value it replaces.
Picture an HR platform onboarding a new employee. The SSN goes straight to the vault, the platform's database stores a token, and recruiters and analysts work with that token for years. Only the payroll service can ever resolve it, and every request is logged.
The vault itself is a separate, hardened service. It encrypts and stores originals, issues tokens and enforces who may get a value back. Here's the full flow:
- Data submission: a user enters a sensitive value, such as a 16-digit card number or an SSN, into an application.
- Transmission to the vault: the application forwards the raw value over an authenticated connection to the isolated token vault.
- Token generation: the vault creates a random token, or a deterministic one when records need to be matched.
- Database mapping: the vault encrypts the original and saves it with a record linking it to the new token.
- Token return: only the non-sensitive token goes back to the application for everyday processing and storage.
- Detokenization: when the original is needed again, an authorized service sends the token to the vault, which checks permissions, returns or forwards the value and logs the request.
| At a glance | Vault-based tokenization |
|---|---|
| Best for | Long-lived, regulated data reused across many systems |
| Key capabilities | Random or deterministic tokens, exact-match search, expiry, per-record deletion, scoped access |
| Main strength | Tokens can't be reversed without the vault's permission |
| Main limitation | Every detokenization depends on the vault being available and responsive |
What Is Vaultless Tokenization and How Does It Work?
Vaultless tokenization is a method that generates tokens on demand with a cryptographic algorithm and a secret key, so it never stores the original value or a mapping between tokens and values.
Most implementations rely on format-preserving encryption, usually the FF1 mode described in NIST SP 800-38G, with the key held in a hardware security module (HSM) or a cloud key management service. In effect, the token is the original value transformed, and the key is what turns it back.
A value moves through five stages:
- Data submission: a user enters a sensitive value into an application or payment terminal.
- Algorithmic computation: the system runs the value through a cryptographic algorithm without saving it to a database.
- Key integration: the algorithm applies a secret key held inside an HSM or key management service.
- Token output: the calculation produces a token that keeps the original length and format, and no lookup record is created.
- Detokenization: an authorized system reverses the calculation with the same key and algorithm to recover the original on demand.
A high-volume checkout is the classic case: each node tokenizes card numbers at the edge and passes tokens downstream without querying a central store.
Best for: high-volume, latency-sensitive and distributed workloads.
Key capability: format-preserving tokens computed locally, with no stored originals.
Main strength: no central database of raw values to breach or replicate.
Main limitation: a leaked key reverses every token created with it, which is why critics describe vaultless tokenization as reversible encryption.
What Are the Advantages and Disadvantages of Each Model?
The advantages and disadvantages of vault vs vaultless tokenization mirror each other: vaults offer random tokens, central control and easy deletion, while vaultless offers speed and no stored data.
Vault-Based Tokenization: Advantages and Disadvantages
Advantages:
- No mathematical link: random tokens can't be reversed by brute force or with any key, so stolen tokens stay useless.
- Central control: access rules, logging and access reviews all happen in one place.
- Simpler scoping: systems that hold only tokens are often easier to keep out of PCI DSS and other audit scopes.
- Record-level deletion: removing one vault record retires every token that points to it, which suits GDPR, CCPA and DPDP requests.
- Richer data controls: expiry, controlled sharing, exact-match search and staff access to real values can all be managed at the vault.
Disadvantages:
- High-value target: the vault holds every original value and needs strong encryption, isolation and monitoring.
- Lookup latency: each detokenization request needs a network call to the vault.
- Availability dependency: if the vault is slow or offline, every flow that needs real values waits with it.
- Operational overhead: backups, replication and recovery have to run reliably.
Vaultless Tokenization: Advantages and Disadvantages
Advantages:
- No central store: there's no database of original values to breach, back up or replicate.
- Speed at scale: tokens are computed locally, which suits very high transaction volumes.
- Format preservation: tokens keep the original length and character set, so legacy fields accept them.
- Distributed use: systems in many regions or at the edge can tokenize without calling a central service.
Disadvantages:
- Key dependency: a compromised key exposes every token created with it, wherever those tokens live.
- Closer to encryption: because tokens are reversible with a key, assessors review key access closely, much as they would for encrypted data.
- Harder deletion: with no stored record, removing one person's data means finding every copy of their tokens or rotating keys.
- Algorithm risk: security depends on the FPE mode in use, and NIST has already dropped FF3 from its revised standard.
What Are the Use Cases for Vault and Vaultless Tokenization?
Vault and vaultless tokenization use cases split by data lifespan and volume: vaults suit long-lived, regulated records, while vaultless suits high-volume, real-time and distributed workloads.
Vault-Based Tokenization Use Cases
| Use case | Who it's for | Why a vault fits |
|---|---|---|
| Card-on-file across payment gateways | Subscription platforms, marketplaces, card issuers, payout providers | The vault forwards card data to any connected gateway, so stored cards aren't tied to one processor |
| Staff-assisted payments | Travel agencies, hotels, contact centers | Authorized staff can view a card in a controlled, logged session while application servers hold only tokens |
| Long-lived personal identifiers | HR, payroll, lending, wealth management | SSNs and account numbers kept for years stay as tokens in every downstream system |
| HIPAA-regulated fields | Health insurers, benefits administrators | Member IDs, diagnoses and lab results are tokenized across claims and case systems |
| Erasure and retention programs | Any business under GDPR, CCPA or DPDP | Deleting one vault record retires every token linked to that person |
| Secrets and credentials | Managed service providers, IT teams | Passwords and API keys live in the vault, and tickets hold only references |
| Multi-tenant SaaS platforms | Vertical SaaS and platform teams | Sensitive fields leave the application database, shrinking the blast radius of any breach |
Vaultless Tokenization Use Cases
- High-volume checkout and digital wallets: retailers and payment apps tokenize card data at transaction speed, where even short lookups would add up across millions of payments.
- Cloud-native data pipelines: data engineering teams tokenize records as they stream into data lakes and warehouses, and deterministic tokens keep tables joinable for analytics.
- Globally distributed services: microservices running in many regions tokenize locally, avoiding replication lag between data centers.
- Legacy systems with fixed schemas: older banking and processing platforms accept format-preserving tokens without database changes.
Which Is More Secure: Vault or Vaultless Tokenization?
In vault vs vaultless tokenization, neither model is secure by default: a vault concentrates risk in a protected store, whereas vaultless concentrates it in a key that reverses every token.
A vault holds every original value, which makes it both a high-value target and a dependency for every flow that needs real data. Well-run vaults manage that risk with encryption at rest, per-customer keys, isolated infrastructure, strict access scopes and detailed audit logs. An attacker who steals tokens from an application database still gets nothing, because random tokens can't be reversed outside the vault.
Vaultless systems remove the central store, which shrinks one attack surface. The risk moves to the key. If that key leaks through a misconfiguration, a compromised service account or an insider, every token created with it can be reversed, wherever those tokens live. Rotating the key afterward doesn't protect tokens already copied elsewhere.
Here's how the two compare across common threat scenarios:
| Scenario | Vault-based tokenization | Vaultless tokenization |
|---|---|---|
| Tokens stolen from an app database | Useless without vault access | Useless without the key |
| Key or vault credentials compromised | Exposure limited by access scopes and monitoring | Every token made with that key is reversible |
| Insider with broad access | Every detokenization request is logged and attributable | Depends on who can reach the key and whether use is logged |
| Tokens copied to a partner or backup | Still random and useless outside the vault | Reversible anywhere the key can be used |
| Future advances in cryptanalysis | Random tokens have no formula to break | Depends on the strength of the FPE mode |
What decides real-world security: how tightly access is scoped, whether keys rotate, whether every request is logged and how quickly access can be revoked after an incident. A well-run vault and a well-run vaultless system can both be strong, and a poorly run version of either is weak.
How Do Vault and Vaultless Tokenization Affect PCI DSS Scope?
Vault and vaultless tokenization can both reduce PCI DSS scope, though random vault tokens usually leave fewer systems in scope, while any system that can reach a vaultless key stays in scope.
PCI DSS scope covers every system that stores, processes or transmits cardholder data, plus systems connected to or able to affect them. Tokenization helps by removing card numbers from as many of those systems as possible, which shortens the list of controls, evidence and testing a business owns.
The PCI Security Standards Council's tokenization guidelines separate reversible tokens into two kinds:
- Non-cryptographic tokens: random values mapped to the original through a lookup, which is how vault-based tokenization works.
- Cryptographic tokens: values generated from the original with a key, which is how vaultless tokenization works.
That distinction shows up during an assessment. With cryptographic tokens, auditors look closely at where the key lives and which systems could use it, since the token and key together reveal the card number. With random vault tokens, systems that hold only tokens and can't detokenize are usually easier to place outside the cardholder data environment.
A few points apply to both models:
- Systems that can detokenize remain in scope.
- Capture pages, payment forms and any service that touches the raw card number stay in scope.
- Card verification codes can't be stored after authorization, tokenized or not.
Whichever side of the vault vs vaultless tokenization choice a business lands on, the final boundary is a customer-specific decision. The QSA or acquirer confirms which systems stay in scope and which Self-Assessment Questionnaire applies.
Vault or Vaultless Tokenization: Which Should You Choose?
Choose vault-based tokenization for random tokens, per-record deletion and controlled access to real values, and choose vaultless tokenization when ultra-low latency at high volume matters most.
When Should You Choose Vault-Based Tokenization?
Choose a vault if:
- Sensitive data in your systems is long-lived and reused across many applications.
- Deletion requests must remove one person's data on demand.
- Authorized staff need controlled access to real values.
- Security policy calls for random tokens with no mathematical link to the original.
- Volumes are low to moderate, or batch requests cover your bulk work.
- Running key management in-house isn't something your team wants to own.
When Should You Choose Vaultless Tokenization?
Choose vaultless if:
- Thousands of real-time transactions per second pass through your platform.
- Applications run across many regions or at the edge.
- Legacy fields must keep the exact format of the original.
- Each value is used once and never needs per-record deletion.
- Your team already runs HSMs and rotates keys on a schedule.
If your answers split between both lists, a vault usually gives you more control over deletion, access and audit for the same compliance effort.
How to Migrate From Vaultless to Vault-Based Tokenization
Migrating from vaultless to vault-based tokenization means decrypting existing tokens in a controlled environment, re-tokenizing values in batches and updating every system that stores them.
Teams usually move for one of three reasons: they need to honor deletion requests record by record, they want to stop running key operations themselves or they need features such as controlled staff access and expiry. A clean migration follows a clear order:
- Inventory the tokens: list every database, warehouse, log store and service that holds vaultless tokens, and note which ones also detokenize.
- Plan the mapping: decide how each old token will map to its new vault token. Attaching existing record IDs to each vault entry makes the switch far easier to track and verify.
- Re-tokenize in batches: decrypt the original values inside a secure, short-lived environment and send them to the vault in bulk requests, never writing plaintext to disk.
- Run both systems briefly: keep the old key available for reads while new writes go to the vault, then move reads over one system at a time.
- Verify and clean up: confirm every system now stores vault tokens and check logs for any remaining calls to the old key.
- Retire the old key: revoke and destroy it, so the old tokens can never be reversed again.
Common pitfalls to plan for:
- Old tokens sitting in backups, exports or partner systems that nobody listed
- Fields with fixed lengths that reject the new token format
- Cutover windows that are too short for the batch volume
Rehearse the whole sequence in a test environment with real field formats and production-sized batches before touching live data.
How to Choose Between Vault and Vaultless Tokenization
Choose vault-based tokenization for strict data isolation and central compliance boundaries, and choose vaultless tokenization for high-speed, low-latency processing across distributed cloud systems.
Four criteria decide most projects.
1. Volume and Performance
- Choose vaultless if the application processes thousands of real-time transactions per second and lookups would create a bottleneck.
- Choose a vault if volume is low to moderate and a few milliseconds per lookup is acceptable, or if batch requests cover the bulk work.
2. Infrastructure and Data Distribution
- Choose vaultless if the architecture is cloud-native, multi-region or serverless and nodes must tokenize independently.
- Choose a vault if data must stay in defined regions, or if one controlled store simplifies governance.
3. Reversibility and Token Isolation
- Choose vaultless if tokens must match the exact format of the original to fit strict database schemas.
- Choose a vault if security policy requires tokens with zero mathematical relationship to the original, ruling out algorithmic recovery.
4. Regulatory and Audit Goals
- Choose a vault if the goal is to keep raw data inside one tightly controlled boundary, honor deletion requests record by record and keep a central audit trail.
- Choose vaultless if the goal is to avoid storing original data entirely and the team can enforce strict key access.
Quick decision matrix:
| Factor | Favor vault-based | Favor vaultless |
|---|---|---|
| Primary goal | Secure central storage and control | High-speed processing at scale |
| Data volume | Low to moderate | Extremely high, global |
| Latency tolerance | Accepts brief lookups | Needs instant computation |
| Architecture | Centralized or hybrid | Distributed, cloud-native, edge |
| Token format | Random, with optional format-preserving tokens | Format-preserving by design |
| Data deletion | Required at record level | Rarely needed |
| Key management | Handled by the vault | Run by a mature internal team |
Why Enigma Vault for Vault-Based Tokenization
Enigma Vault is a vault-based tokenization platform for structured data and payment cards. Data Vault encrypts each field under per-customer keys, takes batches of up to 5,000 records tagged with your own record IDs and supports deterministic tokens, exact-match lookup and per-record deletion. Card Vault forwards stored cards to your payment gateway through its proxy. Both run on PCI DSS Level 1 and SOC 2 Type II certified infrastructure, with a free monthly tier to start.
