PCI PIN Security

Access to secret and private cryptographic keys and key material must be restricted to a small number of designated key custodians on a need-to-know basis with enforced dual control.

• Designated custodian lists with signed acknowledgments
• Access control configuration for HSM management
• Dual-control evidence for key operations
• Access review records

• Too many designated custodians beyond need-to-know
• Single-person access to clear-text components
• Access lists not reviewed periodically

PINs entered for cardholder authentication must be processed only in PCI PTS approved devices (POI, HSM) that meet current security requirements and remain in approved status.

• PCI PTS approval listings for each device model in use
• Device inventory mapping serial numbers, firmware, and approval status
• Process for monitoring device approval expirations
• Decommissioning records for devices removed from approval

• Devices in service past PTS approval expiry
• Inventory not aligned with approved firmware versions
• No monitoring of PTS listings on the PCI SSC website

Where POI devices are used in account data acceptance, devices must implement Secure Reading and Exchange of Data (SRED) functionality to protect account data within the secure boundary.

• Vendor documentation confirming SRED functionality
• Configuration verification at provisioning showing SRED enabled
• Sample device inspection records
• Process for verifying SRED across the device fleet

• SRED disabled or not configured at provisioning
• No periodic verification that SRED remains enabled
• Documentation does not specify SRED status per device model

Equipment used to process PINs and cryptographic keys, including HSMs and POI devices, must be inventoried, secured, monitored, and disposed of in a manner that prevents disclosure of sensitive data.

• Equipment inventory with serial numbers and locations
• Monitoring records for equipment status
• Secure disposal procedures and certificates
• Records of zeroization before disposal

• Equipment inventory incomplete or not reconciled
• Disposal without zeroization evidence
• No process for handling defective equipment containing keys

Symmetric key distribution using asymmetric techniques (remote key loading) must follow defined operational and technical requirements including device authentication, certificate management, and audit logging.

• Remote key loading architecture documentation
• Certificate authority procedures
• Device authentication records
• Audit logs for each remote loading session

• Certificate revocation not validated
• Device authentication not mutual
• Loading sessions without audit logging

Key-injection facilities must operate under approved physical, logical, and procedural controls, including certified TRSMs, controlled access rooms, and documented operational procedures.

• KIF certification by approved assessor
• Physical security documentation
• Operator role definitions enforcing dual control
• Injection logs for each device

• KIF operating outside certified physical envelope
• Operator roles not enforcing separation
• Injection logs lack operator identification

End-to-end controls must ensure secret and private keys and their components are protected throughout their lifecycle, with mechanisms to detect any unauthorized disclosure, modification, or substitution.

• Cryptographic boundary documentation
• Key check value (KCV) verification records
• Detection mechanisms for key modification
• Lifecycle traceability records

• Key check values not verified at each transfer
• Cryptographic boundary undefined or poorly documented
• No alerting on unexpected key changes

Mechanisms must be in place to prevent or detect unauthorized usage of cryptographic keys, including monitoring of key usage patterns, anomaly detection, and audit log review.

• Key usage monitoring configuration
• Anomaly detection thresholds and alerts
• Audit log review records
• Investigation records for detected anomalies

• No baseline of normal key usage for anomaly comparison
• Audit log review performed without documented cadence
• Alerts triggered but not investigated

Key administration procedures must cover the entire key lifecycle from generation through destruction, with appropriate controls at each stage to prevent compromise.

• Documented key lifecycle policy
• Procedures for each lifecycle stage
• Stage transition approval records
• Lifecycle audit trail

• Lifecycle stages not clearly defined
• Transition between stages performed without authorization
• Audit trail does not span the complete lifecycle

Smart cards, paper components, and other materials used to generate or transport cryptographic keys must be treated with the same security controls as the keys themselves, including dual control and secure storage.

• Material handling procedures aligned to key sensitivity
• Secure storage records (safe inventory, custodian logs)
• Dual-control procedures for material access
• Material destruction records

• Smart cards stored in unsecured locations
• Material destruction not witnessed
• Inventory of materials not reconciled with key inventory

Cryptographic keys must be replaced when there is suspected or known compromise, when custodians leave their roles, or when the cryptoperiod expires. Replacement must use approved methods.

• Defined cryptoperiods for each key type
• Key replacement procedures
• Records of replacements due to custodian changes
• Compromise response and replacement procedures

• Cryptoperiods exceeded without replacement
• Custodian departures not triggering key replacement
• Compromise response procedures untested

Cryptographic keys that are no longer required or have been replaced must be securely destroyed in a manner that ensures the keys and any associated material cannot be recovered.

• Documented key destruction procedures
• Destruction certificates with witness signatures
• HSM zeroization logs
• Inventory updates reflecting destroyed keys

• Destruction without witnesses
• Destruction certificates incomplete
• Inventory not updated post-destruction

All cryptographic keys must be generated within PCI-approved cryptographic devices using approved random number generation, ensuring keys are unique, unpredictable, and of sufficient strength.

• Key generation ceremony scripts
• RNG source documentation (FIPS 140-2/3 validated)
• Ceremony witness records
• Key strength verification documentation

• Keys generated outside approved cryptographic devices
• Ceremony witnesses not independent of custodians
• RNG source unverified

Cryptographic keys must be conveyed or transmitted between locations and devices using approved methods, including encrypted transport, dual control, split knowledge, and authenticated channels.

• Key transport procedures with dual control
• Records of split-knowledge component handling
• Secure courier or encrypted channel documentation
• Acknowledgment of receipt by destination custodians

• Clear-text key components transported by single custodian
• Split components shipped together breaching split knowledge
• Receipt acknowledgments missing or unsigned

Keys must be loaded into POI devices and HSMs in a secure manner that prevents disclosure or substitution, with appropriate dual control, witness verification, and detailed logging.

• Key loading procedures with dual control
• Key loading logs identifying operators and devices
• Witness signatures on each loading event
• Procedures for verifying successful key loading

• Loading performed by single operator without witness
• Logs missing operator IDs or timestamps
• No verification step that the loaded key matches the intended key

Cryptographic keys must be used only for the specific purpose for which they were generated and distributed. Cross-use of keys between different cryptographic functions must be prohibited.

• Key inventory specifying purpose for each key
• Technical controls preventing cross-use (key attributes, HSM configuration)
• Audit logs showing key usage by purpose
• Procedures defining allowed key purposes

• Same key used for PIN encryption and MAC generation
• Key purpose attributes not enforced by HSM configuration
• Audit logs do not capture key usage purpose

Key administration including activation, deactivation, replacement, and destruction must be performed under documented procedures with appropriate authorization, dual control, and audit logging.

• Key administration procedures
• Authorization records for key changes
• Dual-control records for administrative operations
• Audit logs of all administrative actions

• Administrative actions performed without dual control
• Authorization records missing for key changes
• Audit logs not retained for required duration

Comprehensive logging must be implemented for all key management activities, with logs protected from tampering and retained for sufficient time to support audit and investigation.

• Logging configuration for HSMs and key management systems
• Log retention policy
• Tamper protection measures for logs
• Log review procedures

• HSM logs not forwarded to SIEM
• Log retention shorter than audit cycle
• No defined process for log review

Network security and segmentation. Control from PCI PIN Security framework, domain: PCI PIN Security: Cybersecurity Controls.

• network diagram
• encryption inventory
• key management procedure
• secure config standards

• scope creep
• weak key rotation
• default credentials
• unmanaged endpoints

Endpoint protection and detection. Control from PCI PIN Security framework, domain: PCI PIN Security: Cybersecurity Controls.

• network diagram
• encryption inventory
• key management procedure
• secure config standards

• scope creep
• weak key rotation
• default credentials
• unmanaged endpoints

Application security controls. Control from PCI PIN Security framework, domain: PCI PIN Security: Cybersecurity Controls.

• network diagram
• encryption inventory
• key management procedure
• secure config standards

• scope creep
• weak key rotation
• default credentials
• unmanaged endpoints

Encryption and key management. Control from PCI PIN Security framework, domain: PCI PIN Security: Cybersecurity Controls.

• network diagram
• encryption inventory
• key management procedure
• secure config standards

• scope creep
• weak key rotation
• default credentials
• unmanaged endpoints

Secure configuration standards. Control from PCI PIN Security framework, domain: PCI PIN Security: Cybersecurity Controls.

• network diagram
• encryption inventory
• key management procedure
• secure config standards

• scope creep
• weak key rotation
• default credentials
• unmanaged endpoints

Incident detection and classification. Control from PCI PIN Security framework, domain: PCI PIN Security: Incident Management & Reporting.

• incident response plan
• forensic readiness procedure
• card brand notification template
• post-incident review

• no card brand contact
• untested IR
• weak forensic preservation
• late notifications

Incident response and containment. Control from PCI PIN Security framework, domain: PCI PIN Security: Incident Management & Reporting.

• incident response plan
• forensic readiness procedure
• card brand notification template
• post-incident review

• no card brand contact
• untested IR
• weak forensic preservation
• late notifications

Regulatory reporting requirements. Control from PCI PIN Security framework, domain: PCI PIN Security: Incident Management & Reporting.

• incident response plan
• forensic readiness procedure
• card brand notification template
• post-incident review

• no card brand contact
• untested IR
• weak forensic preservation
• late notifications

Customer notification procedures. Control from PCI PIN Security framework, domain: PCI PIN Security: Incident Management & Reporting.

• incident response plan
• forensic readiness procedure
• card brand notification template
• post-incident review

• no card brand contact
• untested IR
• weak forensic preservation
• late notifications

Post-incident review and improvement. Control from PCI PIN Security framework, domain: PCI PIN Security: Incident Management & Reporting.

• incident response plan
• forensic readiness procedure
• card brand notification template
• post-incident review

• no card brand contact
• untested IR
• weak forensic preservation
• late notifications

Security policy framework. Control from PCI PIN Security framework, domain: PCI PIN Security: Information Security Governance.

• security charter
• board reporting pack
• risk register
• policy library

• no executive sponsor
• stale policies
• undefined accountability
• missing risk appetite

Roles and responsibilities definition. Control from PCI PIN Security framework, domain: PCI PIN Security: Information Security Governance.

• security charter
• board reporting pack
• risk register
• policy library

• no executive sponsor
• stale policies
• undefined accountability
• missing risk appetite

Business continuity planning and testing. Control from PCI PIN Security framework, domain: PCI PIN Security: Operational Resilience.

• BCP plan
• DR test results
• vendor dependency map
• critical service list

• untested DR
• single vendor dependency
• no exit plan
• missing comms tree

Disaster recovery procedures. Control from PCI PIN Security framework, domain: PCI PIN Security: Operational Resilience.

• BCP plan
• DR test results
• vendor dependency map
• critical service list

• untested DR
• single vendor dependency
• no exit plan
• missing comms tree

Third-party dependency management. Control from PCI PIN Security framework, domain: PCI PIN Security: Operational Resilience.

• BCP plan
• DR test results
• vendor dependency map
• critical service list

• untested DR
• single vendor dependency
• no exit plan
• missing comms tree

Critical service identification. Control from PCI PIN Security framework, domain: PCI PIN Security: Operational Resilience.

• BCP plan
• DR test results
• vendor dependency map
• critical service list

• untested DR
• single vendor dependency
• no exit plan
• missing comms tree

Communication and escalation procedures. Control from PCI PIN Security framework, domain: PCI PIN Security: Operational Resilience.

• BCP plan
• DR test results
• vendor dependency map
• critical service list

• untested DR
• single vendor dependency
• no exit plan
• missing comms tree

Due diligence and onboarding. Control from PCI PIN Security framework, domain: PCI PIN Security: Third-Party Risk Management.

• TPSP register
• AOC collection log
• contractual responsibility matrix
• monitoring cadence

• missing AOCs
• weak responsibility matrix
• no ongoing monitoring
• expired attestations

Contractual security requirements. Control from PCI PIN Security framework, domain: PCI PIN Security: Third-Party Risk Management.

• TPSP register
• AOC collection log
• contractual responsibility matrix
• monitoring cadence

• missing AOCs
• weak responsibility matrix
• no ongoing monitoring
• expired attestations

Ongoing monitoring and assessment. Control from PCI PIN Security framework, domain: PCI PIN Security: Third-Party Risk Management.

• TPSP register
• AOC collection log
• contractual responsibility matrix
• monitoring cadence

• missing AOCs
• weak responsibility matrix
• no ongoing monitoring
• expired attestations

Concentration risk management. Control from PCI PIN Security framework, domain: PCI PIN Security: Third-Party Risk Management.

• TPSP register
• AOC collection log
• contractual responsibility matrix
• monitoring cadence

• missing AOCs
• weak responsibility matrix
• no ongoing monitoring
• expired attestations

Exit strategy and transition planning. Control from PCI PIN Security framework, domain: PCI PIN Security: Third-Party Risk Management.

• TPSP register
• AOC collection log
• contractual responsibility matrix
• monitoring cadence

• missing AOCs
• weak responsibility matrix
• no ongoing monitoring
• expired attestations

POI devices and HSMs must be physically protected from unauthorized access throughout their lifecycle, including during storage, transit, deployment, and active operation.

• Documented secure storage procedures
• Chain-of-custody records for devices in transit
• Tamper-evident packaging procedures
• Inspection records for deployed devices

• Devices stored in unlocked areas before deployment
• Chain of custody missing intermediate handlers
• Tamper-evident seals applied inconsistently

Documented procedures must exist to protect POI devices and HSMs from substitution and tampering during deployment and operation, including periodic inspection and incident response.

• Periodic device inspection procedures and records
• Photographic baselines of authorized device appearance
• Substitution detection mechanisms (serial number verification)
• Tamper response and incident escalation procedures

• Inspection cadence not defined for unattended terminals
• No baseline images for staff to compare against
• Incident response unclear on isolating suspect devices

Organizations must implement and document risk-mitigation practices appropriate for their PIN and key processing environment, including risk assessments, security policies, and incident response plans.

• Documented risk assessments specific to PIN and key processing
• Approved information security policies
• Incident response plans with PIN compromise scenarios
• Records of plan testing and updates

• Risk assessments not refreshed annually
• Policies generic and not specific to PIN environment
• Incident response plans not tested through tabletop exercises