PCI P2PE v3.2 Guide: Point-to-Point Encryption

Card-present merchants carry most of their PCI DSS burden because cleartext card data passes through their tills, networks and back-office systems, and a validated point-to-point encryption solution is the main way to take it out. The PCI Point-to-Point Encryption (P2PE) Standard, now at v3.2 (June 2025), defines how account data is encrypted inside an approved payment terminal and stays encrypted until it reaches a secured decryption environment. This guide explains who the standard applies to, its five domains and Appendix A, the access and key management controls that sit at its core, how merchants should adopt a listed solution, and how assessment works. It is written for payment security leads in retail and hospitality, solution and component providers, and assessors. For PCI DSS itself, start with our overview of the standard and our scoping guide; this page does not repeat them.

Key takeaways

P2PE moves risk to the provider. Encryption happens only in PCI-approved PTS POI devices with SRED, decryption only in a secured environment, so cleartext account data should not exist anywhere in between.
Scope shrinks, it does not vanish. PCI DSS v4.0.1 states that a PCI-listed P2PE solution can significantly reduce the PCI DSS requirements applicable to a merchant, but it does not completely remove PCI DSS from the merchant environment.
The standard has five domains plus Appendix A. Encryption device management, application security, solution management, decryption environment, and cryptographic key operations, with Appendix A covering merchant-managed solutions only.
Identity and keys are the heart of it. Remote access to terminals needs multi-factor or cryptographic authentication, HSM API calls must be limited to authorised users and processes, and key loading needs dual control and split knowledge.
The P2PE Instruction Manual is the merchant's contract with reality. Merchants keep the scope benefit only by following the PIM, including device inspection and reporting tampering.

What it is and who it applies to

The P2PE Standard, formally the PCI Point-to-Point Encryption (P2PE) Security Requirements and Testing Procedures, sets security requirements and testing procedures for P2PE Solutions, P2PE Components and software that runs on the terminals. Its stated aim is to encrypt account data from the point of interaction in the merchant encryption environment through to decryption in a decryption environment, removing cleartext account data between those two points. Version history runs from v1.0 (September 2011) through v3.0 (December 2019) and v3.1 (September 2021) to v3.2 (June 2025), which PCI SSC describes as updated on stakeholder feedback.

Role	Who it is	What the standard expects
P2PE Solution Provider	A third party such as a processor, acquirer or payment gateway that designs and manages a solution for its merchants	Overall responsibility for all P2PE requirements, including those performed by third parties on its behalf; Domain 3 cannot be outsourced
Merchant-managed solution (MMS)	A merchant acting as its own solution provider for its own encryption environments	All domains plus Appendix A separation requirements; hybrid decryption not allowed; PCI SSC does not list MMS
P2PE Component Provider	An entity providing a service assessed to a defined set of P2PE requirements, for example key injection or decryption management	Validated to the relevant domains, may be listed, and must report status to the solution providers it serves (1E, 4E, 5I)
P2PE Application vendor	Supplier of software with access to cleartext account data that runs on the PTS POI device	Domain 2 assessment, listed as a Validated P2PE Application or as solution-specific
Merchant using a listed solution	Retailer, restaurant or hotel accepting card-present payments	Not assessed under P2PE; follows the PIM and validates PCI DSS with its acquirer, with reduced scope
P2PE Assessor	Assessor qualified by PCI SSC for P2PE	Tests the product against the standard; partial assessments are not permitted

The standard is explicit that it does not supersede PCI DSS, the PCI PIN Security Requirements or any other PCI standard, and does not oblige anyone to deploy P2PE. Mandates come from the payment brands. Where merchants report compliance through the SAQ P2PE questionnaire, eligibility is set by the questionnaire and the acquirer, so confirm it with the acquirer before you plan around it. See the PCI DSS Scoping and Network Segmentation Guide.

Structure and key requirements

Each domain has high-level requirements, numbered sub-requirements and testing procedures. Domain 5 is organised by seven control objectives with numbered requirements beneath them.

Domain	Requirements	What it governs
1 Encryption Device Management	1A to 1E	Use of PCI-approved PTS POI devices with SRED (1A), secure logical access (1B), whitelists and non-payment software (1C), application management (1D), component provider reporting (1E)
2 Application Security	2A to 2C	Protecting account data in P2PE Applications, secure development and application management processes
3 P2PE Solution Management	3A to 3D	Solution architecture and data flows (3A), third-party management (3B), the P2PE Instruction Manual (3C), management of P2PE Applications (3D)
4 Decryption Environment	4A to 4E	Approved decryption devices (4A), securing the environment (4B), monitoring and incident response (4C), hybrid decryption (4D), component reporting (4E)
5 Cryptographic Key Operations and Device Management	Control objectives 1 to 7, 5A, 5H, 5I	Key generation, conveyance, loading, usage, administration and equipment management, plus hybrid key management
Appendix A Merchant-managed Solutions	MM-A to MM-C	Separation of the merchant decryption environment from other networks, traffic restrictions to other CDEs and personnel separation

Devices and decryption models

Encryption devices: Account data must be accepted and encrypted in PCI-approved PTS POI devices that include SRED (secure reading and exchange of data) in their approval. 1A-1.4 requires that cleartext account data is not disclosed to any component or device outside the PTS POI device.
Decryption devices: HSMs used for account data decryption must be approved to FIPS 140-2 or 140-3 (overall Level 3 or 4) or the PCI PTS HSM Standard (4A-1.1).
Hardware or hybrid decryption: Decryption normally happens inside an HSM. Hybrid decryption lets decryption occur in non-SCD host systems that meet the extra requirements in 4D and 5H, but all key management must still use an approved HSM. Hybrid is not available to merchant-managed solutions.
Signing devices: Keys that sign P2PE Applications, non-payment software and whitelists must be held in an SCD or a hardware management device such as a smart card or token approved to FIPS 140-2 or 140-3 Level 3 or Common Criteria EAL4+.
No return of cleartext: 4B-1.7 requires that cleartext account data is never sent back to the encryption environment, and 4B-1.8 limits truncated PANs returned to the allowable number of digits.

Key management highlights

Unique device keys: Requirement 20-1 requires each PTS POI device to implement unique secret and private keys for any function related to account data protection.
Key blocks: Requirement 18-3 requires encrypted symmetric keys to be managed in key blocks that cryptographically bind key usage to the key. All three implementation phases are now past, the last extending key blocks to merchant hosts, POS devices and ATMs from 1 January 2025.
Remote key distribution: Asymmetric techniques may be used for initial key loading, such as establishing a terminal master key, with Certification and Registration Authority operations covered by their own requirements.
Key separation: Keys are used only for their intended purpose (19-1) and never shared or substituted between production and test systems (19-4).

For the underlying key management discipline, see the Cryptographic Key Management Guide and the HSM Deployment and Operations Guide.

Identity and NHI requirements

P2PE is usually discussed as a cryptography standard, but many of its controls are about who and what can touch the devices, the keys and the HSMs. Terminal management systems, key injection platforms and HSM-calling applications are non-human identities with direct reach into the payment flow.

Requirement	Identity control	Practical meaning
1B-1.1	Merchant logical access to terminals restricted	Merchant staff cannot change security settings, re-enable disabled interfaces, use vendor default passwords or access devices remotely
1B-1.2	Provider personnel with terminal access listed and authorised	A formal list reviewed annually, management authorisation, least privilege and need to know
1B-2.1	Strong authentication for remote access	Multi-factor or cryptographic authentication for all remote access to merchant terminals, and also to a terminal management system (TMS) used to reach them
1B-2.2	Remote access only from authorised systems	Devices accept remote sessions only from the provider's authorised systems such as the TMS
1B-2.5	Individual credentials and traceability	Unique credentials per person (and per merchant unless a central TMS is used), all access traced to an individual and logged
4B-1.2	Secure HSM administration	Administrative roles only for named personnel, covering console and non-console administration, smart cards, physical keys and HSM commands
4B-1.3	HSM API access	Only authorised users and processes can make function calls to the HSM; authenticate API use and protect those credentials, or restrict the HSM to a trusted host over a dedicated link
4B-1.4	Device authentication	Terminals are authenticated by the decryption environment
Domain 5 (for example 12-1, 12-9)	Dual control and split knowledge	Key loading and key injection need at least two authorised custodians; no one person can know or reconstruct a full cleartext key
MM-C	Personnel separation in MMS	Restrict personnel access between the encryption environment and the merchant decryption environment

The application accounts that call the HSM under 4B-1.3 deserve the same lifecycle discipline as any privileged service account: an owner, vaulted credentials, rotation and logging. See the PCI DSS Requirements for Service Accounts and NHIs Guide (8.6).

Implementation steps

For merchants adopting a listed solution

Confirm the listing: Check the solution on the PCI SSC list of validated P2PE solutions, and confirm that your exact terminal hardware, firmware and application versions appear on it. The PIM tells you how to read those versions from the device.
Agree reporting with the acquirer: Confirm which validation document applies and what evidence the acquirer expects.
Retire legacy paths: Remove non-P2PE card entry routes, such as unencrypted card readers or manual key entry into the till, or the scope benefit is lost for those channels.
Follow the PIM: Implement device receipt, installation, inspection and tamper reporting exactly as written. Set the PCI DSS 9.5.1.2.1 inspection frequency with a targeted risk analysis.
Pilot one site: Run the solution in one store first, verify end-to-end that no cleartext PAN reaches your systems (for example with data discovery on the POS servers), then roll out by region.
Plan rollback: Keep a documented fallback that preserves encryption, such as spare listed devices, rather than reverting to unencrypted entry.

For solution and component providers

Define the product: Decide whether you are a full solution, a component or an application, because partial assessments are not permitted and N/A cannot be used for parts of a defined product.
Document architecture and data flows (3A-1): Including every place account data could be exposed.
Contract third parties (3B-1): Formal agreements with every third party that performs P2PE functions, and monitoring of component provider status reports (3A-2).
Build the PIM (3C-1): Use the mandatory PIM Template, review it at least annually and on change, and communicate updates to affected merchants.
Establish key operations: Key ceremonies with dual control, key blocks and unique device keys. See the Cryptographic Key Ceremony Template.
Secure the decryption environment: Maintain PCI DSS compliance (4B-1.6), quarterly HSM inspections (4B-1.5) and monitoring with incident response (4C).

Evidence and assessment

Testing procedures use examine, interview and observe methods. Assessors may sample system components, but sampling never reduces scope and the requirements themselves cannot be sampled.

No HSM sampling: Every HSM, or hybrid host system, used for account data decryption must be reviewed for secure configuration.
Device coverage: At least one unique hardware and firmware combination from each PTS approval associated with the product must be validated and functionally tested.
Keys: Samples of keys and key components must include all key types and functions.
Sampling rationale: Assessors document the rationale, revalidate it each assessment and choose different samples each time.
Technical FAQs are normative: The P2PE Technical FAQs are a mandatory part of the standard and must be considered in assessments.
Programme rules: Listing, annual renewal, change processes and notification duties if a listed solution is found at fault in a compromise sit in the P2PE Program Guide. PCI SSC may require revalidation after significant standard changes or identified vulnerabilities.
Decryption environment PCI DSS evidence: Where a current ROC exists, the P2PE Assessor should not re-evaluate the PCI DSS environment.

Mapping to other frameworks

P2PE area	PCI standard relationship	NIST SP 800-53 Rev 5	NIST CSF 2.0
PTS POI devices with SRED	Approved under PCI PTS POI	SC-13 Cryptographic Protection	PR.DS-02
Decryption HSMs	PCI PTS HSM or FIPS 140-2/140-3 Level 3 or 4	SC-12, SC-13	PR.DS-01
Decryption environment	Must be PCI DSS compliant	CA-7 Continuous Monitoring	ID.RA-05
Key operations (Domain 5)	Aligned with PCI PIN Security Requirements (v3.1 alignment noted in the change history)	SC-12 Cryptographic Key Establishment and Management	PR.DS-01, PR.DS-02
Remote and administrative access (1B, 4B)	Complements PCI DSS Requirement 8	IA-2, AC-6	PR.AA (identity management, authentication and access control)
Third parties and component providers (3B)	Complements PCI DSS 12.8	SR-3 Supply Chain Controls and Processes	GV.SC
Device inspection and HSM inspection	Complements PCI DSS 9.5.1	PE-3 Physical Access Control	PR.AA

In ISO/IEC 27001:2022 Annex A terms, the closest controls are A.8.24 use of cryptography, A.5.19 to A.5.21 supplier relationships and A.8.5 secure authentication.

Common pitfalls

Unlisted device versions: Firmware updated outside the listed versions, or a device model swapped at one store, means that site is no longer using the validated solution.
Parallel unencrypted channels: A keyed-entry fallback on the POS or a standalone legacy reader keeps cleartext PAN in the merchant environment and pulls those systems back into scope.
PIM ignored after rollout: Inspection and tamper reporting lapse once devices are installed. Skimmer overlays and swapped terminals are the threat P2PE cannot stop alone. See the Point of Sale Security Guide.
Weak TMS access: The terminal management system is reached with shared accounts or without MFA, defeating 1B-2.1 and 1B-2.5 and giving an attacker remote reach to every device.
Unauthenticated HSM APIs: Any process on the host network can call decryption functions, contrary to 4B-1.3.
Assuming zero PCI DSS: Merchants still have PCI DSS obligations, including policy, device protection and any other card channels such as e-commerce.

Practitioner checklist

Confirm the solution, device hardware, firmware and applications appear on the PCI SSC P2PE listing.
Agree the validation document and evidence with your acquirer before deployment.
Remove every card entry path that bypasses the P2PE terminals.
Implement the PIM in full and set POI inspection frequency through a PCI DSS targeted risk analysis.
Providers: enforce MFA or cryptographic authentication for all remote access to terminals and the TMS, with individual, logged credentials.
Providers: authenticate every application and process that calls the HSM and vault its credentials.
Providers: run key loading and injection under dual control and split knowledge, with key blocks and unique device keys.
Providers: inspect decryption HSMs at least quarterly and keep the decryption environment PCI DSS compliant.
Review the PIM at least annually and push changes to every affected merchant.

PCI Point-to-Point Encryption Guide: Domains, Key Management and Merchant Scope Reduction