Card manufacturers, personalisers and token provisioning services handle the cryptographic keys, card data and PIN material from which every payment card is made, so a single weak link lets an attacker clone cards or issue them at scale. The PCI Security Standards Council's Card Production and Provisioning (CPP) standards set the logical and physical security requirements for these vendors, and the payment brands decide who must comply. This guide explains who the CPP standards apply to, how the Logical and Physical requirements are organised, what changes for key custodians, service accounts and provisioning systems, and how to prepare for an assessment by a Card Production Security Assessor. It is for security, compliance and operations leads at card bureaus, personalisation and fulfilment houses and cloud or secure element provisioning providers, and for issuers who oversee them.
Key takeaways
- Two companion standards. CPP Logical covers data preparation, personalisation, PIN generation, provisioning and key management; CPP Physical covers premises, people, production and delivery. Most vendors need both.
- Current version is v3.0.1. PCI SSC published v3.0 on 13 January 2022 and the v3.0.1 errata in June 2022; PCI SSC's June 2022 industry bulletin set the retirement of version 2 for 1 January 2023, and an exploratory request for comments on v3.0.1 ran from 13 February to 16 March 2026.
- The payment brands own compliance. PCI SSC maintains the requirements and qualifies assessors (CPSA-L and CPSA-P), but the brands decide which vendors must validate and when.
- Key management is the heart of the logical standard. Hardware security modules, key custodians, dual control and split components determine whether issuer keys stay secret.
- Provisioning brings cloud identities into scope. Over-the-air and cloud-based provisioning platforms add service accounts, API credentials and remote administration that must meet the same bar as the vault.
What it is and who it applies to
PCI SSC describes card production as including card manufacturing, magnetic-stripe encoding and embossing and card personalisation, and defines provisioning as adding cardholder account information to a device over the air or over the internet. The CPP standards protect the materials and data used in those activities. Compliance is not self-selected: the PCI SSC pages state that the standards apply to activities performed at the request of the payment brands, and direct vendors to the brands (PCI SSC FAQ 1142) to confirm validation obligations.
| Item | CPP Logical | CPP Physical |
|---|---|---|
| Typical entities | Data preparation, pre-personalisation and personalisation, PIN generation, cloud-based or secure element provisioning, OTA personalisation and lifecycle management, key management | Manufacturers, personalisers, pre-personalisers, chip embedders, data preparation and fulfilment providers, card storage, shipping and mailing |
| What is protected | Cardholder and personalisation data, cryptographic keys, PINs and the systems that process them | Card bodies, chips, sheets, PIN mailers, carriers and the buildings, vaults and staff that handle them |
| Assessor | Card Production Security Assessor, Logical (CPSA-L) | Card Production Security Assessor, Physical (CPSA-P) |
| Product listing | None: PCI SSC does not list compliant vendors for these standards | |
| Reporting | Report on Compliance (ROC) and Attestation of Compliance (AOC) templates, plus a separate ROC and AOC for use of a Security Operations Center | |
| Date | Event (as published by PCI SSC) |
|---|---|
| 13 January 2022 | CPP Security Requirements v3.0 announced, adding a Security Operations Center appendix, requirements for transport of card products by rail freight, and criteria for transport to and from sea and air freight facilities |
| June 2022 | v3.0.1 errata, updated ROC and AOC templates and first v3 Technical FAQs, as described in the PCI SSC industry bulletin (PCI SSC states the standards have not been updated since June 2022) |
| 1 October to 31 December 2022 | ROCs and AOCs accepted for both v2.0 and v3.0.1 (per the June 2022 industry bulletin) |
| 1 January 2023 | Version 2 standards and validation documents retired (per the June 2022 industry bulletin) |
| 13 February to 16 March 2026 | Exploratory request for comments on v3.0.1 for eligible stakeholders, under NDA; no publication date for any revision was announced |
Card production sits beside other PCI standards rather than inside PCI DSS. PIN handling and key management at acquirers follow the PCI PIN Security and Key Management Operations Guide, and cardholder data environments at merchants and service providers follow the PCI DSS 4.0 Guide. A bureau that also stores cardholder data for issuers can be subject to several.
Structure and key requirements
The requirement documents are distributed through the PCI SSC Document Library under licence terms. Their domains, as named in PCI SSC's published card production FAQs (v1.1, June 2016, written for an earlier version), are summarised below in our own words; this page does not quote the v3.0.1 requirements. Numbering has changed between versions, so map to the v3.0.1 text you hold rather than to section numbers seen elsewhere.
| Standard | Domain | What assessors look for |
|---|---|---|
| Logical | Roles and responsibilities | Named information security personnel and assigned security duties |
| Logical | Data security | Classification of data, encryption of sensitive data, media handling and secure deletion or destruction |
| Logical | Network security | Segmented networks, firewalls, tightly conditioned remote access, security testing including penetration testing, and monitoring |
| Logical | System security | Hardened, patched systems in the personalisation and data preparation environments |
| Logical | User management and system access controls | Unique accounts, password characteristics, least privilege and access reviews |
| Logical | Key management | Key generation, distribution, storage, usage and destruction; custodians; approved key-management security hardware |
| Logical | PIN and provisioning data distribution (scope area from the PCI SSC CPP pages, not an FAQ domain) | Protection of PINs and personalisation data delivered electronically or over the air |
| Physical | Personnel | Pre-employment screening, external service providers and vendor agents |
| Physical | Premises | External construction, security control room, High Security Areas (HSAs), vault, PIN mailer production room, server and key management rooms, CCTV and recording retention |
| Physical | Production procedures and audit trails | Inventory and audit controls for card bodies and personalisation, dual-control counts, destruction of spoiled material |
| Physical | Packaging and delivery | Sealed packaging, counted and reconciled mailing, controlled transport including the rail, sea and air criteria added in v3.0 |
| Physical | Security Operations Center appendix | Requirements where a SOC manages security systems protecting buildings, assets, access and staff |
Key management in practice
- Approved hardware: PCI SSC's 2016 card production FAQs (earlier version) refer to hardware security modules that are PCI-approved or certified to FIPS 140-2 Level 3 or higher, and the June 2022 bulletin says the v3 Technical FAQs include two FAQs on HSMs whose approvals have lapsed. Track approval status for every HSM model and firmware version you run.
- Custodians and components: keys entered as components are held by separate custodians, with guidance in the 2016 FAQs that no custodian may know more than one component of a key. Keep custodian assignments, backups and transfers documented.
- Dual control: expect dual control to apply to vault access, inventory of unsealed boxes, destruction of material and counts after sealing, as well as to key ceremonies.
Identity and NHI requirements
Card production environments are small, isolated and highly automated, so machine identities often outnumber people.
- Personalisation and data preparation service accounts: applications that pull issuer files, generate PINs and drive personalisation machines run under service accounts with access to the most sensitive data in the facility. Give each a single purpose, store its credentials in a vault or HSM-backed store, and review them with the same rigour as human access. See the PCI DSS Requirements for Service Accounts and NHIs Guide (8.6), whose practices transfer directly.
- HSM and key management identities: HSM administrator cards, smart cards and authentication tokens are identities in their own right. Assign them to named custodians, store them in tamper-evident containers and log every use.
- Issuer file transfer credentials: SFTP keys, certificates and API tokens used to receive issuer data or return results cross the trust boundary. Rotate them on a schedule, restrict by source address and monitor for use outside production windows.
- Provisioning platforms: cloud-based and secure element provisioning add API clients, workload identities and remote administrators. Federate administrators to a central identity provider with phishing-resistant MFA and keep workload credentials short-lived. See the Machine Identity, PKI and Certificate Lifecycle Guide.
- Remote access by suppliers: expect assessors to examine outsourced firewall administration and VPN or remote administration. Broker supplier access through a privileged access system with session recording and time-bound approval. See the Privileged Access Management Guide.
- Physical access identities: badges and biometric enrolments that open HSAs are also credentials. Reconcile badge holders with HR and with the logical access list.
Implementation steps
- Confirm obligations with the brands. Obtain written confirmation of which brands require validation, for which sites and services, and the expected assessment timing.
- Obtain the v3.0.1 documents and FAQs. Download the Logical and Physical requirements, ROC and AOC templates and Technical FAQs from the PCI SSC Document Library and agree your interpretation of any FAQ with your assessor.
- Define scope. Map each site, room, network segment, system, HSM, service account and supplier that touches card material, personalisation data, PINs or keys. Treat provisioning platforms and SOC services as in scope if they perform covered functions.
- Run a gap assessment. Assess against each domain, prioritising key management, HSA controls and remote access, since failures there undermine everything else.
- Remediate in order of risk. Fix key custody and HSM issues first, then network segmentation and remote access, then audit trail completeness and physical upgrades that need building work and lead time.
- Rehearse evidence. Hold a mock assessment: walk an assessor-style path through a key ceremony, a personalisation batch reconciliation and a destruction run, and confirm logs and video exist for each.
- Engage CPSA-L and CPSA-P assessors. Choose qualified assessors from the PCI SSC directory; a single firm may hold both qualifications.
- Maintain continuously. Track the outcome of the 2026 request for comments and any new version, and update procedures when PCI SSC publishes changes.
Small bureau versus multinational vendor
| Concern | Single-site bureau | Multi-site or provisioning vendor |
|---|---|---|
| Key management | One HSM estate and custodian team; key ceremonies on site | Keys shared across sites; must control key transport and copies at other sites |
| Identity | Local directory isolated from corporate IT | Federation across sites and cloud provisioning; more service accounts and API clients |
| Physical | One vault and HSA set to design and monitor | Consistent HSA design across countries; SOC appendix if monitoring is centralised |
| Assessment | One logical and one physical review | Coordinated reviews per site and per service; brand timing may differ |
Evidence and assessment
- Key management records: key inventory, ceremony scripts and signed logs, custodian assignments and transfers, HSM approval status.
- Access evidence: account lists for systems and HSAs, access reviews, remote access approvals and session records.
- Production audit trails: batch reconciliation records, dual-control counts, spoilage and destruction logs.
- Physical evidence: CCTV coverage maps and retention proof, alarm tests, visitor logs, control room procedures.
- Testing evidence: vulnerability scans, penetration test reports and remediation tracking for the logical environment.
Metrics that show the programme is working:
- Batch reconciliation exceptions per million cards, and time to close each exception.
- Share of service accounts with a named owner, vaulted credentials and review in the last quarter (target: 100 per cent).
- Days since last successful key ceremony rehearsal and custodian backup test.
- Remote access sessions without recorded approval (target: zero).
- Open findings from the last CPSA assessment past their agreed date.
Mapping to other frameworks
| CPP domain | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | ISO/IEC 27001:2022 Annex A |
|---|---|---|---|
| Key management | SC-12 Cryptographic Key Establishment and Management; SC-13 Cryptographic Protection | PR.DS-01 | A.8.24 Use of cryptography |
| User management and access | AC-5 Separation of Duties; IA-2(1) Multi-factor Authentication to Privileged Accounts | PR.AA-05 | A.5.3 Segregation of duties |
| Remote access | AC-17 Remote Access | PR.AA-05 | A.8.20 Networks security |
| Premises and HSAs | PE-2 Physical Access Authorizations; PE-3 Physical Access Control; PE-6 Monitoring Physical Access | PR.AA-06 | A.7.1 Physical security perimeters; A.7.2 Physical entry |
| Personnel | PS-3 Personnel Screening | GV.SC-05 (for supplier staff) | A.6.1 Screening |
| Destruction and media | MP-6 Media Sanitization | PR.DS-01 | A.7.14 Secure disposal or re-use of equipment |
Common pitfalls
- Assuming PCI DSS covers it: a PCI DSS AOC does not demonstrate CPP compliance; the brands expect the CPP reports.
- Shared service accounts on personalisation lines: one account used by every machine and operator destroys accountability for batches and fails access control expectations.
- Lapsed HSM approvals unnoticed: firmware updates or end-of-life models change approval status; the v3 Technical FAQs on lapsed approvals exist because this happens.
- Custodian drift: staff turnover leaves one person holding more than one component, or no documented backup custodian.
- Provisioning treated as ordinary cloud IT: OTA and cloud provisioning platforms built by a product team without the key management and remote access discipline of the bureau.
- Video retention gaps: recordings overwritten before reconciliation exceptions are investigated.
Practitioner checklist
- Obtain written confirmation from each payment brand of validation scope and timing.
- Hold the current v3.0.1 Logical and Physical documents, ROC and AOC templates and Technical FAQs.
- Maintain a scope inventory of sites, rooms, systems, HSMs, service accounts and suppliers.
- Check approval status of every HSM model and firmware version.
- Document key custodians, components and backups, and test ceremonies.
- Vault and review every service account and file transfer credential.
- Broker supplier and remote administration through recorded, time-bound privileged access.
- Reconcile badge holders and HSA access with HR and logical access lists.
- Track the 2026 request for comments and plan for a revised version.
Standards and references
- PCI SSC: Card Production and Provisioning, Logical
- PCI SSC: Card Production and Provisioning, Physical
- PCI SSC: Card Production and Provisioning Industry Bulletin (June 2022)
- PCI SSC: Press release on Card Production and Provisioning Security Requirements v3.0
- PCI SSC: Request for comments on CPP Physical and Logical Security Standards v3.0.1
- PCI SSC: Card Production Security Requirements FAQs (v1.1, June 2016, earlier version)
- NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: PCI PIN Security and Key Management Operations Guide · PCI DSS 4.0 Guide · PCI Point-to-Point Encryption Guide · Payment Card Data Elements. This guide summarises the PCI Card Production and Provisioning standards and is not legal or compliance advice.