P2PE vs E2EE vs Tokenization vs Encryption: Card Data Protection and PCI DSS Scope Reduction Compared (2026)

Most payment teams treat “we encrypt card data” as the end of the security conversation. Under PCI DSS it is often the start of a longer audit. A database column encrypted with a key your own engineers can reach is still cardholder data, and every system that touches it is still in scope. A terminal that encrypts the card number before your point-of-sale software ever sees it can, by contrast, take an entire store network out of scope. The difference is not the cipher. It is who holds the key, and where plaintext ever exists.

That is the real axis behind the p2pe vs tokenization debate, and it matters now because PCI DSS v4.0.1 is the only active version of the standard, its future-dated requirements have been mandatory since 31 March 2025, and assessors are testing scope boundaries harder than before.

You will leave with a data-flow model for each approach, a scope map, a comparison table, the key-management mechanics (AES DUKPT, HSMs, FF1), and a decision framework you can apply to card-present and online channels.

What this covers: point to point encryption (validated P2PE), vendor end to end encryption payments, vault and network tokenization, field-level and format-preserving encryption, SAQ eligibility, key management, failure modes and a decision matrix.

Disclaimer: This article is systems-architecture analysis, not compliance, legal or financial advice. Scope decisions belong to your Qualified Security Assessor (QSA), acquirer and the payment brands.

Context and Background

The Payment Card Industry Data Security Standard (PCI DSS) applies to any entity that stores, processes or transmits cardholder data, and to every system component that can affect the security of that data. That second clause is what makes scope expensive. A flat network where the point-of-sale (POS) server, the loyalty database, the Wi-Fi controller and the back-office PCs can all reach each other is one big cardholder data environment (CDE). Every component then needs hardening, logging, vulnerability management and evidence.

PCI DSS v4.0.1 was published on 11 June 2024 as a limited revision of v4.0. Version 4.0 was retired at the end of 2024, and the requirements that v4.0 introduced as “best practice until 31 March 2025” became mandatory after that date. Several of those future-dated items land directly on encryption choices. Requirement 3.5.1.1 requires keyed cryptographic hashes when hashing is used to render a primary account number (PAN) unreadable. Requirement 3.5.1.2 restricts disk- or partition-level encryption as the sole PAN protection to removable media. Script-integrity requirements for payment pages (6.4.3 and 11.6.1) changed how online checkouts are assessed.

Four families of controls compete to shrink scope. Point-to-point encryption (P2PE) is a PCI Security Standards Council (PCI SSC) programme with its own standard, validated solution listings and a dedicated self-assessment questionnaire. End-to-end encryption (E2EE) is the industry name for the same idea without the PCI validation. Tokenization replaces the PAN with a surrogate value after capture, and comes in vault (acquirer) and network (EMV payment token) flavours. Encryption at rest, including format-preserving encryption, protects stored data but rarely removes anything from scope by itself.

If you need the vault internals, our deep dive on card tokenization and PCI DSS vault architecture covers token generation, vault sharding and detokenization APIs. This post does not repeat that. Instead it compares the four approaches as a single system, because in practice you deploy at least two of them together. The primary standards are published in the PCI SSC document library, and the comparison below cites them where they are specific.

My thesis is simple. Scope follows plaintext and keys, not algorithms. Each approach is best understood by asking three questions: where does the PAN exist in clear text, who can turn ciphertext or tokens back into a PAN, and which systems sit on the path in between.

P2PE vs Tokenization: The Reference Data-Flow Model

Direct answer: P2PE encrypts card data inside a PCI-approved terminal and only a third-party solution provider can decrypt it, so merchant systems on the path leave PCI DSS scope. Tokenization replaces a PAN with a surrogate after capture, shrinking scope wherever only tokens are stored. They solve different problems and work best together.

Figure 1: Where each control acts on one card-present and one online transaction. P2PE or E2EE protects data in motion from terminal to decryption HSM. Tokenization protects data at rest in merchant systems. Network tokens replace the PAN toward the card network. Merchant-held encryption such as FPE protects storage but leaves key-holders in scope.

Read the figure left to right. A card or mobile wallet is read by a terminal with Secure Reading and Exchange of Data (SRED) capability. The terminal emits ciphertext, which crosses the merchant POS and store network as an opaque blob. The gateway or processor hands it to a decryption hardware security module (HSM). Only inside the provider’s CDE does a clear PAN reappear. From there, the authorization goes to the card network and issuer, and a token goes back to the merchant. On the online path, a hosted iframe or redirect sends the PAN straight to the gateway, so the merchant’s servers never receive it. The dotted line at the bottom shows the anti-pattern: a merchant database encrypted with keys the merchant holds.

Plaintext exposure is the first scoping question

Every approach can be placed on a line according to where the PAN is last seen in clear text inside merchant-controlled systems. With validated P2PE, the answer is “never”: the card is read inside a tamper-responsive secure processor and encrypted before it leaves. With E2EE, the answer is “probably never”, but nobody independent has validated the device configuration, the key loading or the decryption environment. With tokenization alone, the PAN is clear somewhere on the merchant side before tokenization happens, unless capture is outsourced. With merchant-side encryption at rest, the PAN is clear in the application that encrypts it.

This ordering explains most of the SAQ outcomes later in the post. Scope reduction is achieved by pushing the first plaintext moment out of your estate, not by encrypting harder once it arrives.

Key custody is the second scoping question

PCI SSC guidance on encrypted cardholder data, long stated in its FAQs, is that encrypted data remains in scope for an entity that has access to the decryption keys. It can be considered out of scope only for an entity that cannot decrypt it, where the keys are held by a separate party and the entity has no means of obtaining them. That single rule separates the four approaches more cleanly than any algorithm comparison.

In P2PE, the solution provider owns the base derivation keys in its HSMs, and the merchant has no path to them. In vault tokenization, the token service provider owns the mapping and the detokenization API. In network tokenization, the card network’s token service provider (TSP) owns the mapping. In merchant-side field encryption, the merchant owns the keys, often in a cloud key management service (KMS). The envelope encryption and KMS key management architecture guide is useful for that last case, but excellent key hygiene does not change the custody fact.

Data in motion versus data at rest

P2PE and E2EE are transport controls. They protect the PAN from swipe, dip or tap to the decryption point. They say nothing about what happens to the PAN after the provider decrypts it, and they offer no reusable reference for recurring billing, refunds or customer-on-file payments.

Tokenization is a storage control. It gives merchant systems a durable identifier for the card that is useless to an attacker outside the token domain. Network tokens add a transport property too, because each transaction carries a fresh cryptogram, but that applies between token requestor and network, not between terminal and gateway.

This is why “P2PE or tokenization” is usually the wrong question. A typical well-architected retailer uses P2PE at the counter, hosted fields online, provider vault tokens for refunds and analytics, and network tokens for stored credentials. Merchant-held encryption is reserved for the few places where a business genuinely must retain PANs, such as a bank-issuer back office.

What “out of scope” actually means

Out of scope does not mean unregulated. A merchant on SAQ P2PE still attests to a short list of controls: protecting and inspecting terminals, restricting physical access, managing paper records that contain PAN, maintaining an incident response plan, and following the P2PE Instruction Manual (PIM). A merchant using tokens still has to prove that no system can detokenize, and that tokens cannot be converted back to PANs by anyone in its estate. The goal is a smaller, testable boundary, not the absence of one.

Walk-through: How Each Approach Works and Where Scope Lands

This section takes each approach in turn, with the mechanism, the standards that govern it, and the scope consequence. It ends with the comparison table.

Validated P2PE: the standard, the devices and the keys

The PCI P2PE Standard defines requirements for a solution: the encryption devices, the applications on them, the solution management, the decryption environment and the key management. PCI SSC published P2PE v3.1 in September 2021 and v3.2 on 30 June 2025. The council describes v3.2 as a minor revision covering POI device testing and sampling, whitelist management, non-payment software and P2PE applications. From 1 January 2026, all new submissions, including reassessments of listed products, must use v3.2, while products already validated to v3.0 or v3.1 are not affected until their own revalidation.

Only devices with SRED may capture account data in a P2PE solution. SRED is a module of the PCI PIN Transaction Security (PTS) Point of Interaction (POI) requirements, introduced in PTS POI v3.0. A PCI SSC FAQ explains why it is required: the original PTS standard protected only PIN data, whereas SRED requires the device to protect the PAN for its whole lifetime inside the device and to encrypt account data as it leaves. PTS POI v7.0 was published in May 2025, adding requirements around biometric interfaces, third-party applications and a minimum 128-bit effective strength for terminal security keys.

The key management is where P2PE earns its trust. Most solutions use Derived Unique Key Per Transaction (DUKPT). A base derivation key (BDK) lives only in the provider’s HSMs. At a key injection facility (KIF), each terminal receives an initial key derived from the BDK and a unique identifier. For every transaction, the terminal derives a fresh working key and discards the previous state, so compromising one terminal does not reveal past keys. It sends the ciphertext along with a key serial number (KSN). The HSM re-derives the same key from BDK plus KSN and decrypts.

The current DUKPT specification is ANSI X9.24-3-2017, which defines AES DUKPT alongside the legacy Triple DES (TDES) variant. The industry is mid-migration. PCI PTS POI v6.2 requires terminals to support AES PIN encryption with DUKPT or master/session keys, and NIST SP 800-131A Rev. 2 disallows three-key TDEA encryption after 31 December 2023. However, PCI SSC’s own migration material notes that payment brands have published no single public TDES sunset date for account-data encryption, so many installed terminals still run TDES DUKPT. Ask your provider which variant your fleet uses and when it moves.

Figure 2: P2PE transaction sequence. A key injection facility loads an initial key; the SRED terminal derives a per-transaction AES DUKPT key and emits ciphertext with a KSN; the merchant POS forwards an opaque blob; the provider’s HSM re-derives the key from the BDK and KSN, decrypts inside its CDE and returns an authorization result and a token.

Notice what the merchant POS does in Figure 2: nothing cryptographic. It forwards bytes it cannot read. That is why the POS, store network and back office can fall out of scope, provided the terminals are the only place card data is entered.

Merchants consume P2PE in one of two ways. Most buy a validated solution listed on the PCI SSC website and become eligible for SAQ P2PE if the payment brands agree. Some large merchants run a merchant-managed solution, which means they own the decryption environment themselves; that design shifts scope back into their own estate and requires assessment against the standard. Listing status matters too. PCI SSC states that solutions shown orange or red on its list (overdue for revalidation by up to or more than 90 days) are still validated, but those red for more than 90 days move to the expired list and no longer qualify.

E2EE: the same idea without the validation

Many gateways and terminal vendors sell “end-to-end encryption” that is technically similar: SRED terminals, DUKPT keys, HSM decryption at the provider. The difference is assurance. No P2PE assessor has validated the device chain of custody, the key injection, the decryption environment or the instruction manual. The merchant therefore cannot use SAQ P2PE.

In practice, a QSA may still accept that ciphertext crossing the store network is unreadable to the merchant, and reduce testing on those segments. That is a judgement made per assessment, documented in the Report on Compliance or in the SAQ choice, usually SAQ B-IP for standalone IP-connected terminals or SAQ C for payment applications connected to the internet. The best E2EE products approach P2PE in engineering quality; the weakest are TLS between a POS PC and a gateway with the card read in software, which provides no scope reduction at all. Ask for the device SRED approval, the DUKPT variant and the decryption-environment attestation before believing a brochure.

Tokenization: vault tokens and network tokens

A token is a surrogate value that stands in for a PAN. PCI SSC addresses three token types in separate documents. The 2011 PCI DSS Tokenization Guidelines give a high-level introduction and explicitly define no technical requirements. The 2015 Tokenization Product Security Guidelines offer best practices for acquiring tokens but have no validation programme. For EMV payment tokens, PCI SSC publishes additional security requirements for Token Service Providers, which payment brands may require.

A vault token (also called an acquirer or PSP token) is issued by your gateway or a third-party vault. The vault stores the PAN-to-token mapping, encrypts the PANs, and exposes a detokenization API inside its CDE. Your systems store tokens, and only the vault can recover the PAN. The token is usually only usable with that provider, which creates lock-in; migrating tokens between providers requires a PAN export between two compliant parties.

A network token is issued by the card network’s TSP under the EMVCo Payment Tokenisation framework, at the request of a token requestor such as a merchant or PSP. It is bound to a domain (a merchant, a channel or a device), each use requires a cryptogram, and the network updates it when the underlying card is reissued or expires. Our post on network tokenization architecture for payments covers requestor onboarding and lifecycle events in depth.

Figure 3: Two token types after capture. A vault token maps to a PAN in the provider’s vault and only that provider can detokenize. A network token is issued by the card network’s TSP, carries a per-transaction cryptogram and receives lifecycle updates. In both cases merchant systems hold only tokens and fall outside the CDE if they cannot detokenize.

The scoping rule for tokens is the custody rule again. Systems that store or process only tokens, and that have no ability to call detokenization or access the vault, can be out of scope. A system that can call the detokenize endpoint is effectively a PAN-reading system and stays in scope. One subtle failure is the “convenience detokenize” endpoint that a support tool or a data science notebook can reach with a service credential. It quietly pulls those tools back into the CDE.

Token format also matters. Many vaults issue format-preserving tokens that keep the last four digits, and sometimes the first six or eight digits, so receipts and BIN-based routing still work. A token that passes a Luhn check and looks like a real PAN can confuse data-loss-prevention scanners and auditors. Good vaults let you choose tokens that deliberately fail the Luhn check, or use a reserved range, so a token is never mistaken for a live card.

Encryption at rest and format-preserving encryption

When a merchant or issuer must keep PANs, Requirement 3.5.1 lists the acceptable ways to render them unreadable: one-way hashes of the entire PAN (keyed, under 3.5.1.1), truncation, index tokens, or strong cryptography with associated key-management processes. Encryption at rest is the most common route for systems of record.

Format-preserving encryption (FPE) encrypts a 16-digit number into another 16-digit number, so legacy schemas, fixed-width files and validation logic keep working. NIST SP 800-38G (2016) specifies FPE modes based on AES. Revision 1 has been in draft for years. Its second public draft, published 3 February 2025, drops the FF3 family after a cryptanalytic weakness in its tweak schedule, keeps FF1, raises FF1’s minimum domain size, and forbids floating-point arithmetic in implementations. At the time of writing I could not confirm that a final Rev. 1 has been published, so treat FF1 as the only mode to build on and check the NIST page for the final text.

FPE has a domain-size trap specific to card numbers. If you preserve the BIN and last four digits, only six to nine digits remain to encrypt, which is a small domain. Small domains are exactly where FPE modes are weakest, which is why NIST raised the minimum. Encrypt the whole PAN, or use tokenization instead, when the remaining domain is tiny.

None of this changes scope. A database encrypted with FF1 or AES-GCM under keys your applications can use remains in scope, along with every system that can call the decrypt operation. Encryption at rest is a strong control inside the CDE, not a way out of it.

The comparison table

Dimension	Validated P2PE	Vendor E2EE	Vault tokenization	Network tokenization	Encryption at rest / FPE
Protects	Data in motion, terminal to provider	Data in motion, terminal to provider	Data at rest in merchant systems	Stored credentials and network messages	Data at rest in systems of record
First plaintext PAN on merchant side	None	None, but unvalidated	Before tokenization unless capture is outsourced	Depends on capture method	In the encrypting application
Who can recover the PAN	Solution provider HSM	Vendor HSM	Vault operator	Card network TSP	Key holder, often the merchant
Governing PCI document	P2PE Standard v3.x, PTS POI SRED	PCI DSS only, QSA judgement	Tokenization guidelines 2011 and 2015	TSP security requirements, EMVCo framework	PCI DSS Req. 3.5 to 3.7
Typical SAQ outcome	SAQ P2PE	SAQ B-IP, C or D	Depends on capture; often A, B-IP or D	Depends on capture	SAQ D or ROC
Key management burden on merchant	Terminal handling and PIM only	Terminal handling	API credentials	Token requestor credentials	Full key lifecycle, Req. 3.6 and 3.7
Reusable for recurring payments	No	No	Yes, with one provider	Yes, portable across PSPs that support it	Yes, but in scope
Authorization rate effect	Neutral	Neutral	Neutral	Often positive, brand-reported	Neutral
Main lock-in	Terminal fleet and provider	Terminal fleet and vendor	Token portability	Low	KMS and schema

Read the table by row, not by column. No single approach wins on every row, which is the point. The approaches that minimize scope (P2PE, outsourced tokens) are the ones that move key custody to a third party, and in exchange you accept provider lock-in.

A worked scope example (illustrative)

Consider a hypothetical regional retailer with 120 stores. Each store has two terminals, one POS server, a back-office PC, a Wi-Fi controller and a digital signage player on one flat network. Head office runs an order management system, a data warehouse and a customer service tool. The numbers below are illustrative, chosen to show the mechanism, not drawn from a real assessment.

With terminals that read cards into POS software and no segmentation, every one of roughly 600 store devices plus the head-office systems that connect to them is in the CDE. Each needs vulnerability scanning, file-integrity monitoring, log review and patch evidence. Assessment sampling helps, but the baseline control set still applies to all of them.

Swap to a validated P2PE solution, with POS software that never receives the PAN, and the store estate shrinks to the 240 terminals plus the processes that protect them. If the retailer stores only provider tokens for refunds and receipt lookups, and nothing at head office can detokenize, the order management system and data warehouse also leave the CDE. The remaining in-scope work becomes terminal inventory, tamper inspection, staff training, an incident response plan and adherence to the PIM.

Now add an e-commerce channel. If checkout uses the PSP’s hosted payment fields, the web servers never receive the PAN, and the channel can typically use SAQ A. Since 31 March 2025, SAQ A requires the merchant to confirm its site is not susceptible to attacks from scripts that could affect the e-commerce system, or to manage payment-page scripts. The two channels are assessed separately but share the same token vault.

The sum is a smaller and more testable boundary, but not zero. The trade is visible: the retailer is now dependent on one P2PE provider for terminals and on one PSP for tokens, unless it also adopts network tokens to keep stored credentials portable.

Trade-offs, Gotchas, and What Goes Wrong

Every approach fails in a characteristic way. Knowing the failure modes is more useful than knowing the marketing.

P2PE scope leaks through side channels. The classic leak is a “fallback” path: a manual key-entry keyboard on the POS, a phone order typed into a back-office web form, or an unsupported card type routed to a non-P2PE device. The moment one PAN is entered outside the validated terminals, the systems on that path are back in scope. SAQ P2PE eligibility also requires that the merchant does not electronically store, process or transmit account data on any system other than the P2PE devices, so a single exception can disqualify the location.

Terminal tampering is still a merchant problem. P2PE removes the network from scope, not the terminal from attack. Skimming overlays, swapped devices and shimmers target the physical device. The PIM requires inspection procedures for a reason, and stores that skip them lose the protection the solution assumes.

E2EE claims are hard to verify. Without a P2PE listing, you must collect your own evidence: SRED approval numbers, the key injection facility’s controls, and how the vendor separates decryption keys from its support staff. If you cannot obtain it, assume your QSA will not grant scope reduction.

Token domains decay. Tokens tend to leak into places that make them reversible: a debugging log that captured the detokenize response, an analytics export joined to a raw file from the old system, or a service account with detokenize permissions that everyone shares. Each turns an out-of-scope system back into an in-scope one. Treat detokenize rights like production root.

Token lock-in is real. Vault tokens are typically valid with one provider. Changing PSPs requires a PAN migration between compliant parties, which is slow and contractually fiddly. Network tokens reduce this, but not every acquirer and not every card market supports them uniformly.

FPE and hashing have structural weaknesses on PANs. The PAN space is small and structured. An unkeyed hash of a 16-digit PAN with a known BIN can be brute-forced quickly, which is why 3.5.1.1 now requires keyed hashes. FPE over a truncated domain is weaker for the same reason.

Crypto migration is not finished. TDES DUKPT remains common in installed terminal fleets. A fleet replacement planned around a provider’s AES DUKPT roadmap is a multi-year project, and a new terminal procurement that ignores it buys technical debt.

Practical Recommendations

Choose by channel and by data need, then by assurance level. The decision flow below captures the order of questions that most often leads to the smallest defensible scope.

Figure 4: Decision framework for PCI scope reduction. Start with the capture channel, prefer a listed P2PE solution for card-present and hosted fields for online, then decide whether stored-card reuse is needed. If it is, combine provider vault tokens for operations with network tokens for portability; if not, truncate and discard.

The decision tree ends with tokens for a reason. Capture method decides the SAQ; storage method decides whether the rest of the business is in scope. Most teams get the first decision right and then rebuild a CDE through the second.

For card-present, a listed P2PE solution is the strongest scope reducer available to a merchant, and it is worth paying for if you run many locations. For online, hosted fields or a redirect beat any form of client-side or server-side encryption you build yourself. For storage, prefer tokens you cannot reverse over encryption you can.

Checklist:

• Inventory every place a PAN can be entered, including fallback key-entry, phone orders and unsupported card types.
• For card-present, confirm the solution is on the PCI SSC validated P2PE list and is not on the expired list; read the PIM.
• Ask your terminal provider for the SRED approval, the DUKPT variant (TDES or AES), and the AES migration date.
• For online, use hosted fields or redirect, and meet the payment-page script controls that apply to your SAQ since March 2025.
• Store provider tokens only; restrict detokenize rights to a named, monitored service in the provider’s environment.
• Add network tokens for stored credentials where your PSP supports them, to reduce lifecycle failures and lock-in.
• Where PANs must be stored, use keyed hashes or strong encryption with full key-management controls, and FF1 only for FPE.
• Re-validate scope annually with a data-discovery scan for PAN patterns in logs, exports and tickets.

Frequently Asked Questions

What is the difference between P2PE and tokenization?

P2PE protects card data in transit. It encrypts the PAN inside a PCI-approved terminal, and only the solution provider’s HSM can decrypt it, so the merchant’s POS and network never see plaintext. Tokenization protects data at rest. It replaces a PAN with a surrogate value that merchant systems can store and reuse, while only the token provider can map it back. P2PE does not give you a reusable reference for refunds or recurring billing, and tokenization does not protect the capture path. Most merchants need both.

Is E2EE the same as P2PE?

Technically they often look alike: SRED terminals, DUKPT keys and decryption in a provider HSM. The difference is validation. P2PE is a PCI SSC programme where an assessor validates the devices, key injection, decryption environment and instruction manual, and the solution appears on a public list. Vendor E2EE has no such validation, so it does not qualify a merchant for SAQ P2PE. A QSA may still reduce testing for encrypted segments, but that is a case-by-case judgement rather than a programme outcome.

Does encryption take data out of PCI DSS scope?

Usually not for the entity holding the keys. PCI SSC guidance says encrypted cardholder data stays in scope for any entity that can decrypt it. It may be out of scope only for an entity that has no access to the keys, for example a merchant passing P2PE ciphertext it cannot read. A database you encrypt with your own KMS keys remains in scope, along with every application and person able to call decrypt. Encryption is a strong control inside the CDE, not a way out of it.

What is SAQ P2PE and who is eligible?

SAQ P2PE is a short self-assessment questionnaire for merchants that capture card data only through a validated, listed P2PE solution. Eligibility requires that the merchant does not electronically store, process or transmit account data outside the P2PE devices, follows the P2PE Instruction Manual, and has no legacy non-P2PE capture path. It does not apply to e-commerce. Payment brands and acquirers decide merchant eligibility, so confirm with your acquirer before planning around it. Solutions on the expired-validation list no longer qualify.

Are network tokens better than vault tokens?

They solve different problems. Network tokens are issued by the card network’s TSP, carry a per-transaction cryptogram and are updated automatically when the card is reissued, which helps with stored-credential approvals and portability across PSPs that support them. Vault tokens are issued by your PSP or a third-party vault, work for any card the provider supports, and are easier for internal reference use. Many merchants store a vault token internally and let the PSP manage a network token underneath it.

Is FF3-1 still allowed for format-preserving encryption?

NIST’s second public draft of SP 800-38G Revision 1, published in February 2025, no longer specifies FF3 after a cryptanalytic weakness in its tweak schedule, and keeps FF1 with a larger minimum domain size. I could not confirm a final Rev. 1 at the time of writing, but new designs should use FF1 only. FPE is also weak when the encrypted domain is small, such as a PAN with BIN and last four preserved, so tokenization is often the better choice.

Further Reading

• Card tokenization and PCI DSS vault architecture — vault internals, token formats and detokenization controls.
• Network tokenization architecture for payments — token requestors, cryptograms and lifecycle management.
• SoftPOS and tap-to-pay architecture with PCI MPoC — card acceptance on commodity phones, where SRED hardware is replaced by attestation.
• Envelope encryption, KMS and HSM key management — key hierarchies and rotation for data you must keep.
• PCI SSC: P2PE v3.2 release notes — official summary and transition dates.
• NIST SP 800-38G Rev. 1, second public draft — format-preserving encryption, FF1 and the removal of FF3.

By Riju — about