Category: Cryptography Fundamentals

Strong Cryptography

Also known as: Strong Encryption

Simply put

Strong cryptography refers to the use of well-tested, robust encryption techniques to protect sensitive data so that it is difficult for an attacker to read or use even if they obtain it. It is based on cryptography, which uses mathematical formulas to scramble data. When implemented correctly, it helps make stolen payment card data useless to criminals.

Formal definition

Strong cryptography is the use of cryptographic algorithms and key strengths that are recognized by the industry as robust for protecting the confidentiality and integrity of sensitive data, for example established symmetric algorithms such as AES or Triple DES. Its security depends not only on algorithm selection but also on implementation factors including key length, secure key management, and appropriate mode of operation; the algorithm label alone does not establish adequate protection. Practitioners should note that suitability evolves over time as algorithms and key sizes weaken, so crypto agility, the capability to update algorithms and keys, is a relevant consideration. Not all cryptographic transformations serve the same purpose: reversible encryption protects confidentiality of recoverable data, while non-reversible functions such as hashing are appropriate for values like passwords that should not be recovered; readers should confirm specific algorithm and key requirements against the current published standard rather than assuming a fixed set.

Why it matters

Strong cryptography is a foundational control for protecting payment card data. When implemented correctly, it is intended to make stolen data useless to criminals, because even if an attacker obtains the ciphertext, they cannot readily recover the underlying sensitive values without the keys. This matters most where cardholder data is stored or transmitted, since encryption of stored account data and encryption of data over open, public networks are core expectations in payment security programs. The protective value comes from the combination of a robust algorithm and sound implementation, not from the presence of encryption alone.

The strength of a cryptographic control degrades over time as algorithms and key sizes weaken and as computing capability advances. An implementation considered adequate at one point may later be regarded as weak, which is why crypto agility, the ability to update algorithms and keys, is a relevant design consideration. Treating strong cryptography as a fixed, one-time decision rather than an ongoing practice can leave data protected by techniques that are no longer robust.

It is also important to recognize that strong cryptography reduces the confidentiality risk of data at rest and in transit but does not by itself address every risk. It does not compensate for weak key management, insecure modes of operation, or exposure of data before encryption or after decryption. Practitioners should confirm specific algorithm and key requirements against the current published standard rather than assuming a fixed set, since suitability evolves.

Who it's relevant to

Security Engineers and Developers

Engineers who build or maintain systems that store or transmit sensitive data must select recognized algorithms and appropriate key lengths, choose correct modes of operation, and implement secure key management. They should distinguish reversible encryption, used to protect recoverable data, from non-reversible hashing, which is appropriate for values such as passwords that should not be stored using reversible encryption, and should design for crypto agility so algorithms and keys can be updated as they weaken.

Compliance Officers and Assessors

Those validating payment security controls need to confirm that cryptographic implementations meet the specific algorithm and key requirements of the current published standard rather than accepting an algorithm label as sufficient. Because requirement wording and cryptographic expectations can change between versions, they should verify against the applicable current standard and assess key management and implementation, not just the stated use of encryption.

Merchant and Payment Risk Teams

Teams responsible for protecting stored and transmitted cardholder data rely on strong cryptography to help make stolen data useless to attackers. They should understand that this control reduces the confidentiality risk of protected data but depends on sound key management and ongoing maintenance, and should plan for updating algorithms and keys over time as their strength changes.

Inside Strong Cryptography

Industry-Tested and Accepted Algorithms

Strong cryptography relies on algorithms that have been vetted and accepted by the broader cryptographic community rather than proprietary or unproven schemes. PCI DSS references strong cryptography as being based on industry-tested and accepted standards; practitioners should confirm the specific algorithms and references named in the current published version of the standard rather than assuming a fixed list.

Adequate Key Lengths

The strength of a cryptographic implementation depends in part on using key sizes considered sufficient to resist known attacks for the algorithm in use. What is considered adequate changes over time as computing capabilities and cryptanalysis advance, so the acceptable minimums should be verified against current guidance rather than a static value.

Proper Key Management

Cryptography is only as strong as the processes protecting the keys. This includes secure generation, distribution, storage, rotation, retirement, and destruction of keys, along with restricting access to key-handling functions. Weak key management can undermine an otherwise strong algorithm.

Relationship to Data Protection Requirements

Strong cryptography is invoked in several PCI DSS contexts, such as rendering the primary account number (PAN) unreadable in storage and protecting cardholder data during transmission over open, public networks. The applicability and exact requirement wording differ between PCI DSS versions and should be confirmed against the current standard.

Distinction From Related Data Transformations

Strong cryptography refers specifically to encryption using accepted algorithms and key management. It is distinct from truncation, masking, and hashing, which transform or reduce data differently, and from tokenization, which substitutes data. Their effect on scope and data protection depends on implementation and validation, not on the label alone.

Common questions

Answers to the questions practitioners most commonly ask about Strong Cryptography.

Does using any encryption algorithm count as strong cryptography for PCI DSS purposes?

No. Strong cryptography is not defined by the mere presence of encryption but by the use of algorithms, key strengths, and key management practices that are considered industry-tested and accepted at the time of use. Weak, deprecated, or proprietary algorithms, or otherwise acceptable algorithms used with insufficient key lengths or poor key management, do not qualify. You should confirm what is currently accepted against the definitions and references in the current published PCI DSS and its glossary rather than assuming any encryption satisfies the requirement.

If I apply strong cryptography, can I then store sensitive authentication data safely?

No. Encrypting sensitive authentication data does not make it permissible to store after authorization. Full track data, card verification codes or values (such as CAV2, CVC2, CVV2, or CID), and PINs or PIN blocks must not be retained after authorization even when encrypted. Strong cryptography is one control for protecting cardholder data that may be stored under defined controls, such as the PAN, but it does not create an exception to the prohibition on storing sensitive authentication data.

How does strong cryptography apply to the primary account number when it is stored versus when it is transmitted?

The intent is that the PAN be rendered unreadable wherever it is stored and be protected with strong cryptography when transmitted over open, public networks. Storage and transmission are distinct protection objectives, and the same term applies to both, though the specific mechanisms differ. For stored PAN, approaches may include strong cryptography with associated key management, while other methods such as truncation, tokenization, or hashing may also render PAN unreadable depending on implementation and validation. Confirm the exact expectations and wording against the current published standard.

What role does key management play in whether cryptography is considered strong?

Key management is integral, not optional. Cryptography that uses an accepted algorithm and adequate key length can still fail to meet the intent of strong cryptography if keys are generated, distributed, stored, rotated, or retired improperly, or if key-encrypting and data-encrypting keys are not appropriately separated and protected. The strength of the overall control depends on the algorithm, the key strength, and the surrounding key management practices together.

How should we handle algorithms or protocols that are being deprecated?

Because what is considered industry-tested and accepted changes over time, algorithms, key lengths, and protocols that are acceptable today may be deprecated later. Organizations are expected to monitor recognized industry guidance and the current PCI DSS references, plan for migration away from weakening or deprecated cryptography, and avoid relying on mechanisms no longer considered strong. Treat the definition as time-dependent rather than fixed, and verify against the current published standard.

Does strong cryptography by itself take a system out of PCI DSS scope?

Not automatically. Applying strong cryptography protects data but does not, on its own, remove a system or environment from scope. The effect on scope depends on the specific implementation, how keys are managed and who can access them, and how the approach is validated. Systems that store, process, or transmit cardholder data, or that can affect the security of the cardholder data environment, generally remain in scope regardless of the cryptography label applied, so scope reduction claims should be assessed against the actual implementation and current guidance.

Common misconceptions

Any encryption qualifies as strong cryptography.

Not all encryption meets the definition of strong cryptography. Proprietary, outdated, or weak-key implementations may not qualify. Strong cryptography depends on industry-tested and accepted algorithms combined with adequate key lengths and proper key management, verified against current guidance.

Using a strong algorithm alone makes data secure.

A strong algorithm can be undermined by poor key management. Weak key generation, storage, or access controls can compromise the protection regardless of the algorithm's theoretical strength, so key management is an integral part of achieving strong cryptography.

Strong cryptography lets you store any data, including sensitive authentication data, as long as it is encrypted.

Sensitive authentication data, such as full track data, card verification values (CAV2/CVC2/CVV2/CID), and PINs or PIN blocks, must not be stored after authorization even when encrypted. Strong cryptography applies to permitted data protection, such as rendering the PAN unreadable, and does not authorize retention of sensitive authentication data.

Best practices

Use only industry-tested and accepted algorithms and confirm acceptable choices and minimum key lengths against the current published PCI DSS and referenced cryptographic guidance rather than a fixed list.

Implement full key lifecycle management, covering secure generation, distribution, storage, rotation, retirement, and destruction, and restrict access to key-handling functions.

Do not rely on encryption to justify storing sensitive authentication data; ensure full track data, card verification values, and PINs/PIN blocks are not retained after authorization.

Distinguish encryption from truncation, masking, hashing, and tokenization when designing controls, and validate each mechanism's actual effect on data protection and scope rather than relying on its label.

Periodically review algorithms and key lengths against evolving guidance, since what is considered adequate changes as computing capabilities and cryptanalysis advance.

Apply strong cryptography where required, such as protecting cardholder data during transmission over open, public networks and rendering the PAN unreadable in storage, confirming the specific requirement wording in the current standard version.