1. Cryptographic Inventory & CBOM (PCI DSS Req 4.2.1.1 & 12.3.3)

Under active QSA enforcement of PCI DSS v4.0.1 (specifically Requirements 4.2.1.1 and 12.3.3, strictly mandatory since March 31, 2025): QSAs actively issue formal findings of QSA non-conformance if an automated, machine-readable Cryptographic Bill of Materials (CBOM) is missing across Cardholder Data Environment (CDE) switches. Do you maintain an automated, machine-readable inventory?

Automated CBOM Generation

We continuously generate CycloneDX 1.6 CBOM artifacts via passive network/endpoint probes.

Manual Spreadsheets & Static Inventories (QSA Audit Risk)

We maintain periodic spreadsheets; subject to QSA non-conformance findings during annual ROCs.

No Formal Cryptographic Inventory

We do not have centralized visibility across microservice cipher suites or TLS endpoints.

2. Asymmetric Public-Key Algorithms in Transaction Routing

What cryptographic algorithms protect authorization messages between your API gateways, merchant endpoints, and clearing switches?

Dual-Mode Hybrid Key Exchange (X25519 + ML-KEM-768)

Post-quantum hybrid key encapsulation deployed in production or staging.

Modern Classical Only (TLS 1.3 ECDHE-X25519)

Robust classical elliptic-curve ciphers, but vulnerable to retrospective quantum decryption.

Legacy RSA-2048 / TLS 1.2 Handshakes

Legacy RSA key exchanges active across transaction ingestion switches.

3. Cardholder Data Retention Window & HNDL Risk Exposure

How long are encrypted Primary Account Numbers (PANs), cardholder metadata, or tokenization mapping tables retained in your databases and backup archives?

Long-Term Retention (7–10+ Years)

Critical HNDL risk: ciphertext captured today will retain financial utility when quantum computers emerge.

Moderate Retention (1–3 Years)

Standard chargeback and dispute resolution window.

Zero Long-Term Storage / Ephemeral Tokenization

Strict purge policies; tokens rotated immediately with quantum-resistant envelope tags.

4. Payment HSMs, TR-31 Key Blocks & Storage Capacity (PCI PTS HSM v5.0)

Under PCI PTS HSM v5.0, PCI PIN Security Phase 3 (TR-31 key block wrapping mandate), and the September 2026 NIST FIPS 140-2 sunset, have you evaluated your HSM fleet (Thales payShield, Atalla AT1000, IBM Crypto Express CEX cards) for ML-KEM-768 key block database bloat (1,184-byte keys causing 7.4× storage expansion)?

TR-31 Compliant & Post-Quantum Schema Validated

HSMs and database columns accommodate 1,184-byte ML-KEM key blocks without column truncation or buffer overflow.

TR-31 Classical Blocks Only (Database Columns Fixed at 160 Bytes)

TR-31 wrapping is implemented for 3DES/AES, but database schemas cannot store expanded 1,184-byte PQC blocks.

Legacy Key Management / Unassessed TR-31 Posture

HSM firmware capabilities, TR-31 binding, and key storage limits remain unbenchmarked.

5. ISO 8583 / Core Switch Latency Budgeting

Have you benchmarked the impact of expanded post-quantum handshakes (>1,500 byte TCP MTU) on sub-10ms switch processing SLAs?

Persistent Connection Pools & RFC 8879 Compression Active

Handshakes are pre-negotiated or compressed to prevent packet fragmentation.

Unbenchmarked Handshakes Under Live Peak Load

High risk of packet fragmentation and authorization timeouts during peak TPS windows.

6. Legacy Heavy Iron & Switch Crypto-Agility (IBM zSystems & HP NonStop)

Are cryptographic calls decoupled via an abstraction layer across your core transaction infrastructure (e.g. IBM zSystems mainframes, HP NonStop Tandem servers running BASE24, or cloud microservices)?

Centralized Policy-Driven Cryptographic Abstraction (CAL)

Algorithms hot-swappable via configuration across mainframes, Tandem BASE24 switches, and distributed APIs.

Hardcoded Cryptography in Monolithic Switch Codebases

COBOL, C++, or Assembler modules embed static crypto calls requiring multi-month re-certification to change.

7. Third-Party Vendor & Card Scheme Dependencies

Have you audited whether your upstream payment processors, card brand connections, and SaaS tokenization vendors support PQC algorithms?

Formal Vendor Cryptographic SLAs in Place

Vendors have committed to FIPS 203 roadmap timelines and dual-mode hybrid support.

Unassessed Vendor Cryptographic Risk

No formal audits of external processor encryption lifecycles or quantum readiness.

8. C-Suite, QSA & CNSA 2.0 Post-Quantum Migration Strategy

Does your organization have a board-approved post-quantum migration budget and roadmap aligned with the January 1, 2027 CNSA 2.0 Procurement Gate, active PCI DSS Req 12.3.3 cipher review standards, and QSA expectations?

Active Multi-Year PQC Migration Program

Formal engineering milestones with executive sponsorship, CNSA 2.0 alignment, and QSA review.

No Formal Post-Quantum Program

Migration planning has not commenced.

Assessment Result

0 / 100

Incomplete Assessment

Please answer all questions above to calculate your organization's Quantum Vulnerability Index and PCI DSS v4.0 CBOM compliance profile.

PCI DSS v4.0 CBOM & Quantum Readiness Scorecard

1. Cryptographic Inventory & CBOM (PCI DSS Req 4.2.1.1 & 12.3.3)

2. Asymmetric Public-Key Algorithms in Transaction Routing

3. Cardholder Data Retention Window & HNDL Risk Exposure

4. Payment HSMs, TR-31 Key Blocks & Storage Capacity (PCI PTS HSM v5.0)

5. ISO 8583 / Core Switch Latency Budgeting

6. Legacy Heavy Iron & Switch Crypto-Agility (IBM zSystems & HP NonStop)

7. Third-Party Vendor & Card Scheme Dependencies

8. C-Suite, QSA & CNSA 2.0 Post-Quantum Migration Strategy

Email My Assessment Report & Remediation Checklist

Research & Briefings

Navigation

About NexaFrontier