PCI DSS v4.0 scope reduction via tokenization or network segmentation still requires systems that process cleartext at some point. H33 FHE eliminates scope entirely because data is never in cleartext during processing. There is no perimeter to manage because there is no cleartext to protect.
Every PCI scope reduction strategy shares a common limitation: somewhere in the system, cardholder data exists in cleartext. H33 FHE removes that constraint entirely.
PCI DSS v4.0 defines scope as any system component that stores, processes, or transmits cardholder data, or any system connected to such a component. The entire compliance framework is organized around one premise: cardholder data in cleartext is dangerous and must be controlled. Every requirement in PCI DSS -- from network segmentation (Requirement 1) to encryption at rest (Requirement 3) to access control (Requirement 7) -- exists to manage the risk created by cleartext exposure.
Scope reduction strategies accepted by the PCI Security Standards Council follow the same logic. Tokenization replaces the primary account number (PAN) with a non-sensitive token, reducing the number of systems that handle the real PAN. Network segmentation isolates the cardholder data environment (CDE) from the rest of the network. Point-to-point encryption (P2PE) encrypts data from the point of interaction to the decryption environment. Each technique shrinks the CDE, reducing the number of systems subject to PCI DSS controls.
But none of these techniques eliminate the CDE. The tokenization vault must store the token-to-PAN mapping. The HSM must hold the encryption keys. The P2PE decryption environment must produce cleartext for processing. Network segmentation isolates the CDE but does not eliminate it. In every case, there is a system that has access to cleartext cardholder data, and that system is the target -- for attackers, for insider threats, and for compliance obligations.
Fully Homomorphic Encryption changes the fundamental equation. With H33 FHE, cardholder data is encrypted before it enters any processing system. The encryption is performed under the client's key, and the client never shares that key with the processing infrastructure. All computation -- validation, routing, risk assessment, fraud scoring -- is performed directly on the ciphertext. The result is an encrypted output that only the client can decrypt.
This is not a theoretical capability. H33's BFV engine operates at production scale: batch processing of 32 operations in 1,345 microseconds, with a per-operation latency of 42 microseconds. The H33-128 parameter set provides 128-bit security with a single 56-bit modulus, enabling arithmetic operations on encrypted data at speeds that are operationally viable for real-time payment processing.
The PCI DSS implications are structural. A system that never possesses cleartext cardholder data does not store, process, or transmit cardholder data as defined by PCI DSS v4.0 Requirement 3. It is not part of the CDE. It does not require PCI DSS controls. The scope is not reduced -- it does not exist for that system.
PCI DSS compliance evidence under the traditional model consists of Self-Assessment Questionnaires (SAQs), Reports on Compliance (ROCs), and Attestations of Compliance (AOCs) produced by Qualified Security Assessors (QSAs). These documents represent a human assessor's opinion, based on interviews, configuration reviews, and sample testing, that controls were operating effectively during the assessment period.
H33 produces a different kind of evidence. Every operation generates a post-quantum signed attestation that cryptographically binds the inputs, the operation, and the output. This attestation is independently verifiable: any party with access to the H33 Verifier CLI can replay the attestation and confirm that the operation was performed on encrypted data, that the encryption parameters met the specified security level, and that the output matches the deterministic replay. This is not an opinion. It is a mathematical proof.
For organizations preparing for QSA assessments, this changes the compliance posture entirely. Instead of assembling evidence packages over weeks, the organization provides the attestation chain. The QSA can independently verify every operation, every encryption parameter, every timestamp -- in seconds, not weeks. The attestation does not expire between assessment periods. It is perpetually verifiable.
PCI DSS v4.0 requires strong cryptography but does not yet mandate post-quantum algorithms. However, the PCI Security Standards Council has acknowledged the quantum threat, and the "harvest now, decrypt later" attack is particularly relevant to payment data: card numbers intercepted today and stored encrypted under RSA or AES can be decrypted when quantum computers become available, and stolen card data retains value for years after compromise.
H33's FHE processing is paired with post-quantum attestation. Every attestation is signed with three independent PQ signature families (ML-DSA-65, FALCON-512, SLH-DSA-SHA2-128f), based on three independent mathematical hardness assumptions. The attestation proving that data was processed encrypted is itself quantum-resistant. Organizations that adopt H33 FHE processing today are simultaneously addressing the current PCI DSS requirements and positioning for the inevitable post-quantum mandate.
Traditional scope reduction creates operational dependencies that introduce both cost and risk. Tokenization requires a token vault -- a database that maps tokens to PANs. This vault is the single most valuable target in the entire payment infrastructure: compromise the vault, and every token can be reversed to a live PAN. The vault must be protected with the full weight of PCI DSS controls, monitored continuously, and backed up with tested recovery procedures.
HSMs (Hardware Security Modules) introduce a different dependency. The HSM holds the encryption keys for P2PE and tokenization operations. HSMs are expensive, require specialized management, and create operational bottlenecks. When an HSM fails, the entire processing pipeline stops. When an HSM is compromised -- as has happened in documented breaches -- the keys it held are exposed.
H33 FHE eliminates both dependencies. There is no token vault because there is no tokenization -- data remains encrypted throughout processing. There is no HSM because the encryption key never leaves the client's control. The processing infrastructure does not hold any key material. It cannot decrypt the data even if fully compromised. The security model does not depend on the integrity of any hardware device or the protection of any centralized key store.
The historical objection to FHE in payment processing has been performance. Early FHE implementations were orders of magnitude too slow for real-time processing. This objection is no longer valid. H33's production pipeline on Graviton4 hardware delivers 42 microseconds per authentication operation, including FHE batch processing, post-quantum attestation, and ZKP cached verification. At this latency, FHE processing is faster than the network round-trip to a remote tokenization vault.
The H33-128 BFV engine uses a single 56-bit modulus with degree N=4096, providing 128-bit security at production throughput. The Montgomery radix-4 NTT with Harvey lazy reduction eliminates the computational overhead that made earlier FHE implementations impractical. The performance is not a prototype benchmark -- it is sustained production throughput measured over 120-second intervals on production hardware.
The fundamental difference: scope reduction manages cleartext. H33 eliminates cleartext.
PCI scope reduction strategies -- tokenization, network segmentation, P2PE -- all share a common property: they accept that cleartext cardholder data will exist somewhere in the system and focus on minimizing the number of components that touch it. H33 FHE rejects that premise. Data enters encrypted, is processed encrypted, and exits encrypted. There is no cleartext at any point, in any component, at any time.
A structured comparison across the dimensions that matter for payment data protection and compliance evidence.
| Dimension | PCI Scope Reduction | H33 FHE |
|---|---|---|
| Scope approach | Reduce (shrink CDE perimeter) | Eliminate (no CDE exists) |
| Cleartext exposure | At tokenization, HSM, decryption points | Never -- data processed encrypted |
| Vault / HSM dependency | Yes -- vault and HSM required | No -- key never leaves client |
| Compliance evidence | SAQ / ROC (assessor opinion) | Deterministic replay (mathematical proof) |
| Post-quantum readiness | No -- RSA/AES only | Yes -- 3 PQ families, 3 hardness assumptions |
| Computation on protected data | No -- must decrypt to process | Yes -- FHE arithmetic on ciphertext |
| Attestation per operation | No -- periodic assessment | Yes -- every operation attested |
| Independent verification | No -- trust the QSA | Yes -- any party can verify |
| Breach impact on processing data | Cleartext exposed if CDE breached | Only ciphertext available -- no key on server |
| Processing latency | Milliseconds (network + HSM) | 42 microseconds per operation |
Every claim on this page is backed by published documentation, live systems, or independently verifiable benchmarks.
No. Tokenization reduces PCI scope by replacing cardholder data with non-sensitive tokens, but the tokenization system itself -- the vault, the detokenization endpoint, the HSM that manages the mapping -- remains in scope. Cleartext cardholder data must exist at the point of tokenization and at the point of detokenization. PCI DSS v4.0 Requirement 3.5 still applies to any system that stores, processes, or transmits cardholder data, including the tokenization infrastructure. You have not eliminated scope. You have relocated it.
With Fully Homomorphic Encryption (FHE), yes. H33 FHE enables computation on encrypted cardholder data without decryption at any point during processing. The data enters encrypted, is processed encrypted, and the result is returned encrypted. No system in the processing pipeline ever has access to cleartext cardholder data. This is not scope reduction -- it is scope elimination, because there is no cleartext to protect and therefore no cardholder data environment to define.
PCI DSS v4.0 scope reduction is the practice of minimizing the number of systems, networks, and processes that fall within the cardholder data environment (CDE). Common techniques include network segmentation, tokenization, and point-to-point encryption. The goal is to shrink the perimeter around cleartext cardholder data so that fewer systems require PCI DSS controls. However, scope reduction does not eliminate the CDE -- it reduces its size. Systems that perform tokenization, detokenization, decryption, or key management remain in scope.
Fully Homomorphic Encryption eliminates PCI scope by ensuring that cardholder data is never in cleartext during processing. In an FHE-based architecture, data is encrypted before it enters any processing system. All operations -- validation, routing, risk scoring, fraud detection -- are performed on ciphertext. The processing infrastructure never possesses the decryption key and never has access to plaintext cardholder data. Under PCI DSS v4.0, a system that never stores, processes, or transmits cleartext cardholder data is not part of the CDE and is not in scope.
H33 does not seek PCI DSS certification for its processing infrastructure because its FHE architecture means that infrastructure never handles cleartext cardholder data. H33 provides the cryptographic tooling -- FHE engines, post-quantum attestation, and deterministic replay verification -- that enables organizations to build payment processing systems where cleartext never exists in the processing path. The compliance evidence H33 produces is deterministic and independently verifiable: any auditor or QSA can replay an attestation to confirm that data remained encrypted throughout processing.
Run a live FHE operation. Verify the attestation independently. See what happens when data is never in cleartext.