The PCI Security Standards Council's draft Hardware Security Module Modular Security Requirements v5.0 marks a major update in HSM security standards. If your team uses HSMs for PIN processing, card verification, or cryptographic key management, it's essential to understand the changes and assess your current compliance.
The RFC period runs from October 30 to December 15. You have 45 days to review draft requirements that will influence HSM security for the next compliance cycle. This checklist guides you on what to evaluate, what to flag for your team, and how to provide feedback that can impact the final standard.
Prerequisites
Before starting your review:
Confirm your RFC access. Ensure you're an eligible PCI SSC stakeholder with portal credentials. Check your email for access instructions and accept a Non-Disclosure Agreement to download the draft.
Inventory your current HSM deployments. Document which devices handle PIN processing, chip transaction processing, payment card personalization, secure key loading, or remote administration. Note whether each operates in PCI mode, non-PCI mode, or both.
Pull your v4.0 compliance documentation. Gather your current applicability matrix, control implementation statements, and any documented exceptions or compensating controls.
Identify your technical reviewers. Engage someone who understands your cryptographic architecture, physical security posture, and key management workflows.
Good looks like: A one-page summary showing which HSM functions you use, which v4.0 requirements apply to each device, and who owns technical review for cryptographic controls versus physical security.
Review Checklist
1. Map the restructured requirements to your current controls
The v5.0 draft includes a complete restructuring of requirements and the applicability matrix. Your first task is to understand which new requirement numbers correspond to your existing implementations.
Create a crosswalk document: v4.0 requirement on the left, corresponding v5.0 requirement on the right, and a gap column noting whether the new language introduces substantive changes or just reorganizes existing obligations.
Good looks like: A spreadsheet where every requirement you currently attest to has a mapped v5.0 equivalent, with "no change," "clarified," or "new obligation" flagged in the gap column.
2. Assess your cryptographic key strength posture
Version 5.0 specifies that cryptographic keys used for device security must provide a minimum of 128 bits of effective strength. Review your current key generation, storage, and management practices.
Check whether your HSMs use keys below this threshold for device authentication, firmware integrity verification, or secure boot processes. If you're using 112-bit effective strength keys (common in older Triple-DES implementations), document the upgrade path.
Good looks like: A list of every cryptographic function where your HSMs use keys for device security, the current effective strength in bits, and a yes/no flag for whether you meet the 128-bit threshold.
3. Review dual-mode operation requirements
The draft specifies additional requirements for both PCI and non-PCI mode. If your HSMs switch operational modes based on transaction type or network context, this is important.
Identify which controls currently apply only in PCI mode. Evaluate whether extending those controls to non-PCI mode creates operational conflicts, performance impacts, or requires architecture changes.
Good looks like: A technical memo explaining when and why your HSMs operate in each mode, which controls differ between modes today, and what it would cost (in performance, complexity, or capital) to harmonize them.
4. Evaluate physical security dependencies after ISO 13491 removal
Version 5.0 removes the requirement for deployment in an environment meeting at least the security of a controlled environment under ISO 13491. This is a significant shift.
Document your current physical security controls: data center access restrictions, tamper-evident enclosures, environmental monitoring, and intrusion detection. Determine whether you've been relying on ISO 13491 compliance as a compensating control for HSM-level physical protections.
If you have HSMs in colocation facilities or third-party data centers, review your contracts. Are you paying for ISO 13491-compliant environments that may no longer be required?
Good looks like: A risk assessment showing which physical attack vectors your HSMs face, which controls mitigate each vector, and whether removing the ISO 13491 requirement changes your threat model or control sufficiency.
5. Analyze the new key transfer section
The draft adds a new section for key transfer. Review how your organization currently moves cryptographic keys between HSMs, from key generation facilities to production devices, and during HSM replacement or disaster recovery.
Document your key transport mechanisms: are you using key-encrypting keys, split knowledge procedures, hardware security tokens, or courier-delivered key components? Map each mechanism to the new requirements.
Good looks like: A process flow diagram for every key transfer scenario you support, annotated with which new v5.0 key transfer requirements apply at each step.
6. Assess remote administration controls
Version 5.0 adds a new section for remote administration. If you manage HSMs through network-based consoles, remote firmware updates, or centralized key management systems, this section defines new baseline controls.
Inventory your remote administration capabilities: authentication methods, session encryption, privileged access management integration, logging and monitoring, and change control procedures. Identify gaps between your current implementation and the draft requirements.
Good looks like: A table listing every remote administration function (firmware update, configuration change, key injection, log retrieval), the access control and audit mechanisms protecting each function, and whether they meet the new requirements.
7. Calculate compliance timeline and resource needs
Assume v5.0 publishes in Q1 2025. PCI standards typically allow 12-18 months for migration. Build a preliminary project plan showing what you'd need to change, in what sequence, and with what resources.
Include hardware refresh cycles (some older HSMs can't be upgraded to meet new cryptographic strength requirements), software patches, process documentation updates, and staff training.
Good looks like: A Gantt chart with task dependencies, a rough-order-of-magnitude budget, and a risk register identifying what could delay compliance.
Common Mistakes
Treating this as a compliance-only exercise. The restructured requirements and new sections reflect real-world attack patterns and operational lessons from payment security incidents. If you only think about passing audits, you'll miss opportunities to strengthen your actual security posture.
Waiting for the final standard before acting. RFC feedback influences the final requirements, but major architectural decisions (like 128-bit key strength) are unlikely to change. Start planning now.
Ignoring the applicability matrix changes. A restructured matrix means different requirements apply to different HSM functions. Don't assume your v4.0 scope carries forward unchanged.
Submitting vague feedback. "This requirement is too prescriptive" doesn't help the Council. If you have concerns, propose specific alternative language with technical justification.
Next Steps
Submit your feedback through the PCI SSC portal before December 15. The Council can only accept comments received within the RFC period through the official channel.
Structure your submission around specific requirement numbers, cite technical standards or implementation challenges, and propose concrete alternatives where you see problems. Generic objections get ignored; detailed technical feedback shapes the final standard.
After the RFC closes, monitor the Council's publication schedule for v5.0 release and effective dates. Use the time between now and enforcement to close gaps you've identified, even if the final requirements shift slightly from the draft.
Your HSMs protect the cryptographic operations that make digital payments trustworthy. This RFC is your chance to ensure the standard reflects the threats you actually face and the controls that actually work.
