Migrating from vaultless tokenization to a vault means decrypting existing tokens in a controlled environment, re-tokenizing the original values into a secure vault, then updating downstream systems before the old keys are retired.
Vaultless tokenization usually wins the first round. It needs no database, generates tokens on the fly with format-preserving encryption and fits existing schemas, because each token looks like the data it replaces.
The costs arrive later.
Take a lending platform that tokenized two million SSNs this way. Every token depends on one key. When the security team schedules a key rotation, it finds those tokens in underwriting, servicing and a partner's nightly file, and every copy has to be re-encrypted. When a former borrower asks to be forgotten, there's no record to delete, because the SSN lives inside each token.
Or take a private club that keeps member cards on file through a vaultless scheme tied to its processor. The day it wants a second gateway, it learns those tokens can't move.
Both teams are running into the same limits:
- One key for everything: If the key leaks, every token ever issued can be reversed.
- Rotation pain: Changing that key means re-encrypting every stored token across every system.
- Nothing to erase: An erasure or expiry request has no single record to delete.
- Compliance questions: PCI guidance treats reversible tokens as encrypted card numbers.
In this article, we'll explore the limitations of vaultless tokenization, then follow the lending platform and the club through a phased migration that moves them to a vault without a risky cutover.
What Is the Difference Between Vaultless and Vaulted Tokenization?
Vaultless tokenization generates tokens from the original value with an encryption key, whereas vaulted tokenization issues random tokens and stores the original value in a secure vault that maps each token back.
The two approaches can produce tokens that look alike. What separates them is what stands between the token and the original value.
Here's how the lending platform's SSNs and the club's card number look under each model:
| Original value | Vaultless token | Vault token (random) | Vault token (format-preserving) |
|---|---|---|---|
| SSN 123-45-6789 | 847-29-3016 | tok_8fK2xQ9mLp | Not needed for SSNs |
| SSN 987-65-4321 | 302-81-5574 | tok_Qm3Lw7Zr2N | Not needed for SSNs |
| Card 4111 1111 1111 1111 | 4111 1183 9927 1111 | tok_c7Rn4Wz1Hd | 4111 1162 0459 1111 |
With vaulted tokenization, there's no relationship between a value and its token. If an attacker learns that tok_8fK2xQ9mLp stands for 123-45-6789, that tells them nothing about tok_Qm3Lw7Zr2N or any other borrower. The values sit in the vault, and each token is only a random reference.
With vaultless tokenization, every token comes from the same algorithm and key. An attacker who obtains that key can turn 847-29-3016 back into 123-45-6789 and 302-81-5574 into 987-65-4321, along with every other token the platform has issued.
| Factor | Vaultless tokenization | Vaulted tokenization |
|---|---|---|
| Token generation | Derived with an algorithm, usually format-preserving encryption | Random, with no mathematical link to the value |
| Data storage | No central store; the value is recoverable from the token and key | Original value encrypted and stored in the vault |
| Mapping dependency | Relies on keeping the encryption keys safe | Relies on the vault's lookup table and access controls |
| Key compromise | Every token can be reversed at once | Tokens stay meaningless without vault access |
| Key rotation | Every stored token must be re-encrypted | Keys rotate inside the vault while tokens stay the same |
| Erasure and expiry | No record to delete | Each record can be deleted or set to expire |
| Access control | All-or-nothing access to the key | Scoped access per value, with audit logs |
| Token format | Matches the original format | Random by default, format-preserving when needed |
| PCI DSS view | Treated as encrypted PAN that may stay in scope | Systems holding only tokens can sit outside the cardholder data environment |
With Enigma Vault, you get random tokens by default. Each one comes from a cryptographically secure random number generator, with 128 bits of entropy and no structure to reverse. When your downstream systems expect card formats, Enigma Vault lets you issue Luhn-passable tokens that keep the first six and last four digits.
The same trade-offs shape every data tokenization program, and they sit at the center of the vault vs vaultless tokenization decision.
What to Prepare Before Migrating From Vaultless Tokenization
Preparing to migrate from vaultless tokenization means mapping every place tokens live, every service that detokenizes them, the formats downstream systems expect and who controls the encryption keys.
Most migration problems trace back to a token nobody knew about. For the lending platform, the inventory turns up SSN tokens in a reporting replica nobody owns and in a partner's nightly file. Each one still depends on the key the team planned to retire.
| Area | What to document | Why it matters |
|---|---|---|
| Token locations | Databases, warehouses, log stores, backups and partner files | Missed copies keep the old keys alive |
| Detokenization callers | Every service, job and person that reverses tokens today | Each one must switch to the vault |
| Token formats | Length, character set, Luhn checks, first-six and last-four rules | Downstream validation can break on new tokens |
| Key custody | Where keys live, who can use them, HSM access | Decryption during migration needs controlled key use |
| Compliance owners | Security, privacy, PCI and audit contacts | Scope changes need sign-off |
| Rollback plan | How to fall back if a phase fails | Operations keep running if something breaks |
Two decisions round out the plan:
- Migration order: Most teams move one data type at a time, starting where risk is highest. The club moves member cards first and member IDs later, while the lender starts with SSNs.
- Success measures: Agree up front on what done looks like, such as zero fallback reads to the legacy key, every historical token resolving through the vault and no plaintext in logs.
How to Migrate From Vaultless Tokenization to a Vault: Step-by-Step
Migrating from vaultless tokenization to a vault runs in five phases: set up the vault, run dual-mode tokenization, re-tokenize historical data, update downstream systems, then validate and retire the old keys.
A phased approach avoids downtime and gives every team a checkpoint before the old system goes away.
Phase 1: Set Up the Vault and Access Controls
- Provision the vault: Stand up the vault service and confirm availability and recovery requirements.
- Scope credentials: Give each service its own credentials with only the actions it needs, such as store, retrieve or delete.
- Design the mapping: Plan how each legacy token links to its new vault token, usually through a reference ID stored with the record.
For the club, each card's new vault token carries the member number as its reference ID. With Enigma Vault, every stored card accepts your own reference ID, and Data Vault lets you attach your own record IDs to each secret, so vault entries map cleanly onto your existing data model.
Phase 2: Run Tokenization in Dual Mode
Dual mode lets old and new tokens coexist while the history moves.
- Update the tokenization service: Add vault calls behind the same internal interface applications already use.
- Route new writes to the vault: Every new value gets a vault token from the start.
- Handle reads in order: Look up the token in the vault first. If it isn't there, decrypt it with the legacy key.
A servicing agent at the lending platform never notices the switch. New borrowers get vault tokens, and existing records still resolve through the legacy key until their turn comes.
Phase 3: Decrypt and Re-Tokenize Historical Data
- Extract legacy tokens: Pull them from every location found during preparation.
- Decrypt in an isolated environment: Run decryption in a locked-down job with restricted key access and no plaintext written to disk or logs.
- Re-tokenize in batches: Send recovered values to the vault in controlled batches and record each new token.
- Store the mapping: Keep a legacy-to-vault token map until cutover is complete.
With Enigma Vault, you can send up to 5,000 values in a single Data Vault request. For the lending platform's two million SSNs, that turns the migration into a weekend job instead of a quarter-long project.
Phase 4: Update Downstream Systems
- Replace legacy tokens in application databases and APIs with vault tokens.
- Send updated files to processors and partners, or agree on a transition window.
- Purge legacy tokens from logs and caches as retention rules allow.
The club's monthly dues run keeps working through this phase. Our payment proxy fills in the card number at charge time and forwards the request to the club's existing processor, so the gateway receives the same data while the club's systems hold only tokens.
Phase 5: Validate, Cut Over and Retire the Keys
- Run parity checks: Confirm every historical token resolves to the same value through the vault.
- Turn off fallback reads: Remove the legacy decryption path once lookups stop hitting it.
- Revoke and archive keys: Retire the encryption keys under your key management policy.
- Switch to vault-only mode: Disable the vaultless code path entirely.
The lending platform knows it's ready when a full week of production traffic passes with zero fallback reads to the legacy key.
How to Keep Downstream Systems Working During Migration
Downstream systems keep working during migration when new tokens match the formats they expect, link back to existing records and stay consistent enough for joins and deduplication to run unchanged.
Tokens rarely live in one place. Billing systems validate them, and partners receive them in files. Each consumer needs the new token to behave like the old one.
Match the expected format: The club's booking system rejects any card number that fails a Luhn check, so a random token would break it. A format-preserving vault token passes the same check and keeps the first six and last four digits, and the booking code stays as it is.
Link new tokens to old records: A reference ID stored with each vault entry connects it to the record or legacy token it replaces. The club can trace every migrated card back to a member without keeping the old keys around.
Keep tokens consistent: Deterministic tokens give the same value the same token every time. The lender's fraud team counts unique applicants by SSN, and that count stays the same after the move.
Coordinate with processors and partners: Gateways and partners that store your tokens need a transition plan. A gateway-agnostic proxy removes much of that work for card payments, since the vault supplies the card number at charge time.
Enigma Vault lets you choose token behavior per data type: format-preserving tokens for cards, deterministic tokens for identifiers that drive joins and a reference ID on every record. In the software platforms we work with, Luhn-passable tokens slot into existing checkout code, and charges route through our proxy to whichever gateway the platform or its merchants use.
Why Do Teams Migrate From Vaultless Tokenization to a Vault?
Teams migrate from vaultless tokenization to a vault when key risk, rotation costs, erasure requests or processor lock-in start costing more than a vault, often after an audit or a security event.
| Trigger | What breaks with vaultless tokenization |
|---|---|
| Audit finding | Reviewers question tokens that can be reversed with a key |
| Key rotation deadline | Every stored token has to be re-encrypted |
| Erasure request backlog | No record exists to delete for one person |
| Processor switch | Tokens tied to one format or provider can't move |
| Suspected key exposure | Every token issued under that key is at risk |
| Retention policy | Per-record expiry can't be enforced |
Most teams hit more than one trigger at once. The lending platform's rotation project surfaces an audit question about who can use the key, and the club's gateway plan exposes how many systems hold card-derived tokens that only the old scheme can read.
Audits add pressure from the other side. When an assessor asks who can reverse a token and where that access is logged, a vaultless setup can only point to the key. A vault answers with a named credential and an audit record for every request.
Many of the card-on-file operators we see reach this point with cards scattered across spreadsheets, legacy systems and old payment terminals. For them, the vault also becomes the first real system of record for those cards. Enigma Vault helps organizations like these move cards and identifiers into one governed place without changing how the business runs.
Why Vaultless Tokens Count as Encrypted Data Under PCI DSS
Vaultless tokens count as encrypted data under PCI DSS because they're generated with reversible encryption, so anyone holding the key can recover the card number from the token itself.
Returning to the club's card: 4111 1183 9927 1111 looks like a card number because, to anyone holding the key, it still is one. Most vaultless systems create tokens like this with format-preserving encryption, such as the FF1 method defined in NIST SP 800-38G, using keys held in hardware security modules.
That's why the PCI Security Standards Council's Tokenization Guidelines treat these tokens differently. When a token is generated with reversible encryption, "the resultant token is an encrypted PAN, and may be subject to PCI DSS considerations."
Three consequences follow for the club:
- Scope can follow the token: Systems that store reversible tokens may stay inside the cardholder data environment.
- Key protection becomes the control: Every system that can reach the key is part of the security boundary.
- High-value tokens add risk: Tokens that can initiate a payment may carry the same value to an attacker as the card number itself.
Treating tokens as encrypted PAN also brings PCI DSS key management requirements into play, from documented key custody to scheduled rotation and secure key storage. For a vaultless system, those controls cover every token in circulation.
The club's vault token, tok_c7Rn4Wz1Hd, has no mathematical relationship to the card. Systems that hold only tokens like it can be designed out of scope, with the acquirer or QSA confirming the final boundary.
With Enigma Vault, your applications hold only tokens while card data stays in our vault, which runs on PCI DSS Level 1 certified infrastructure.
What Are the Limitations of Vaultless Tokenization?
The limitations of vaultless tokenization include a single key that can reverse every token, costly key rotation, no record to erase or expire, no per-record access control and tokens locked to one system.
One Key Can Reverse Every Token
Vaultless security rests entirely on the key. If it leaks through a misconfigured HSM policy or a compromised service account, all two million of the lending platform's SSN tokens become readable at once. There's no second barrier, because each token carries its own value.
With a vault, a stolen token table is a list of random strings.
Key Rotation Means Re-Encrypting Everything
Rotating a vaultless key changes every token it produced. Every stored copy has to be re-encrypted in a coordinated window, or the old key has to stay alive. Many teams quietly keep the old key, which defeats the purpose of rotating it.
Erasure Requests Have Nothing to Delete
Returning to the former borrower who asked to be forgotten:
- With vaultless tokenization: The SSN lives inside tokens copied across underwriting, servicing and the partner file. Each copy has to be found and removed by hand.
- With a vault: The lender deletes one vault record, and every token that pointed to it stops resolving.
Expiry works the same way. Vaultless tokens can't be set to expire per record, so retention depends on cleanup jobs that rarely reach every copy. SSNs are exactly the kind of PII that privacy laws let people ask to remove.
No Per-Record Access Control or Audit Trail
Anyone who can use the key can reverse any token. The lender can't let a support agent reveal one borrower's SSN while blocking bulk access, and nothing records which value was revealed to whom.
Tokens Stay Locked to the System That Issued Them
The club's card tokens follow the format and keys of the scheme that issued them. Adding a gateway means decrypting and reprocessing every stored card, the very migration the club hoped to avoid.
What Can a Vault Do That Vaultless Tokenization Can't?
A vault can keep tokens meaningless if a key leaks, rotate keys without reissuing tokens, delete single records and control who sees each value, which vaultless tokenization can't do.
| Business need | Vaultless tokenization | With Enigma Vault |
|---|---|---|
| Breach impact | A leaked key exposes every token | Random tokens reveal nothing without authorized vault access |
| Key management | Rotation reissues every token | Per-customer AES-256 keys roll over inside the vault while tokens stay the same |
| Erasure and expiry | No record to delete | Delete any record, or set expiry from 60 seconds to 7 years |
| Access and audit | Key holders see everything | Scoped OAuth2 credentials, one-time ephemeral keys and a log of every API request |
| Format compatibility | Matches the original format | Random by default, with Luhn-passable card tokens when needed |
| Processor portability | Tied to the issuing system | Payment proxy forwards charges to any REST-based gateway |
Keys rotate without touching tokens: In a vault, keys protect the stored values while tokens stay random. With Enigma Vault, each customer has its own AES-256 keys, no key is shared between customers and your team never manages one.
Retention becomes a setting: With Enigma Vault, you have a better way to handle erasure. The lender's former borrower becomes a single delete call. Every record can also carry its own expiry, and expired records are removed automatically.
Access becomes specific: Scoped credentials decide which service can store, read or delete. When another client needs one value, a one-time ephemeral key shares it and then expires.
Processors become interchangeable: For the club, adding a second gateway is a configuration change, because the cards never lived with the processor in the first place.
Enigma Vault is designed so the systems you run every day hold only references, while the vault holds the values and decides who can use them. That model is what a data privacy vault adds over a tokenization algorithm.
Who Should Migrate From Vaultless Tokenization to a Vault?
Organizations that should migrate from vaultless tokenization to a vault include payment platforms tied to one processor, lenders holding SSNs as encrypted tokens, payers with scattered member IDs and card-on-file businesses.
SaaS and Payment Platforms
Platforms that tokenized cards inside one processor's format face a migration every time they add a gateway, often just as merchants start asking for cards on file and recurring billing. An independent vault lets the platform route charges to any gateway while customers never re-enter a card. The same logic applies to any credit card tokenization setup that needs to stay processor-neutral.
Fintech and Lending
- Signal: SSNs and bank account numbers stored as format-preserving encryption values.
- Risk: Each key rotation turns into a re-encryption project across underwriting and servicing systems.
- Outcome: Random vault tokens with exact-match lookup keep servicing workflows running, and deterministic tokens keep duplicate-application checks working.
Health Insurers and Administrators
Member IDs copied into claims tools and contact-center notes are hard to rotate and harder to erase. A vault gives each identifier one governed record, with tokens scoped to the systems that use them and every retrieval logged.
Aviation, Cruise and Member Clubs
Card-on-file records in these businesses are collected over years across booking channels and phone calls:
- Existing cards move into the vault in bulk.
- Bookings and dues keep charging against the new tokens through the existing processor.
- Staff stop handling card numbers in booking and membership tools.
How Enigma Vault Simplifies Migration From Vaultless Tokenization
Enigma Vault makes migration from vaultless tokenization to vaulted tokenization easy. Our approach is the same for cards and personal data: we re-tokenize values in batches, keep your downstream formats intact and retire the old keys in phases.
In one private aviation deployment, existing cards were imported into the vault in bulk, staff signed in through enterprise single sign-on and every charge kept running through the operator's existing processor. The cards moved into certified custody, and the operation didn't change. For card-on-file operators, we package that pattern as Agent Vault, a fixed-scope, eight-week engagement that includes the migration.
Batch Migration With Data Vault
Data Vault accepts up to 5,000 values per request, so historical SSNs and account numbers move as batch calls. You can attach your own record IDs to each value so entries map onto your existing data model, and deterministic tokens keep joins and lookups working once the migration is done.
Card-on-File Migration With Card Vault
- Format-preserving tokens: Card Vault can issue Luhn-passable tokens that keep the first six and last four digits.
- Reference IDs: Each stored card carries your own reference, linking it to the customer or legacy record.
- Any gateway: The payment proxy fills in card details inside the vault and forwards charges to Authorize.net, Stripe, Braintree, PayPal or any REST-based gateway.
- Migration support: Our team works with you on card-on-file migrations, as covered in card vault tokenization.
Governance After the Move
Every record can expire on a schedule or be deleted on request. Scoped OAuth2 credentials limit what each service can do, one-time ephemeral keys share a value with another client, and every API request is logged.
Enigma Vault Solution and Pricing
Our platform runs on PCI DSS Level 1 and SOC 2 Type II certified infrastructure. Each vault is priced independently, so you can run Card Vault for cards and Data Vault for SSNs and account numbers on the plans that fit each workload.
| Plan | Card Vault | Data Vault | Includes |
|---|---|---|---|
| Lite | $0 per month, free forever: 1,000 requests, then $0.08 per request | $0 per month, free forever: 1,500 requests, then $0.06 per request | Card tokenization and gateway proxy, or AES-256 field encryption, with community support |
| Plus | $49.99 per month: 20,000 requests (roughly 200 to 300 daily transactions), then $0.04 per request | $49.99 per month: 30,000 requests, then $0.03 per request | Ephemeral key sharing and email support |
| Premium | $249.99 per month: 250,000 requests (roughly 2,000 daily transactions), then $0.02 per request | $249.99 per month: 400,000 requests, then $0.01 per request | Highest request volume and priority support |
Every plan is billed through AWS Marketplace, and teams with custom volume or dedicated infrastructure needs can ask for an enterprise plan. See the full pricing page, try the Card Vault demo or request a demo to plan your migration with our team.
