Category: Cryptography Fundamentals

Advanced Encryption Standard

Also known as: AES, Rijndael

Simply put

The Advanced Encryption Standard (AES) is a US Government-approved method for scrambling electronic data so that it can only be read by someone who has the correct key. It is a widely trusted way to protect information by converting it into an unreadable format. AES uses the same key to both scramble and unscramble the data.

Formal definition

AES is a FIPS-approved symmetric block cipher specified in FIPS 197, originally known by its submission name Rijndael. As a symmetric algorithm, it uses the same key for encryption and decryption to protect electronic data. It is categorized as a computer security standard in the field of cryptography and is approved by the US Government for protecting electronic data.

Why it matters

AES is one of the most widely relied-upon symmetric encryption algorithms for protecting electronic data at rest and in transit, and it appears throughout payment security architectures wherever strong encryption is called for. Because it is a FIPS-approved standard specified in FIPS 197 and approved by the US Government for protecting electronic data, it is a common baseline choice when organizations need a cryptographic algorithm whose security properties are well studied and broadly accepted.

In a payment context, encryption using algorithms such as AES is one of several ways cardholder data can be rendered unreadable while stored, and it may also underpin encryption in transit. However, encryption is only one control among many, and its effect on PCI DSS scope and its adequacy depend on implementation details—including key management, mode of operation, and key strength—not merely on naming AES as the algorithm. It is important to distinguish encryption from tokenization, truncation, masking, and hashing, which reduce or transform data differently. It is also important to remember that sensitive authentication data (such as full track data, card verification values, and PINs or PIN blocks) must not be stored after authorization even when encrypted, so applying AES does not create an exception to that prohibition.

Readers should treat AES as a building block whose correct and validated use matters as much as the choice of algorithm itself. The specific requirements governing cryptography for cardholder data are set out in PCI DSS, and requirement wording and numbering differ between versions; confirm details against the current published standard rather than assuming that using AES alone satisfies any given requirement.

Who it's relevant to

Security engineers

Engineers implementing encryption for cardholder data at rest or in transit may select AES as a FIPS-approved symmetric block cipher. They are responsible for correct implementation choices—including mode of operation, key length, and integration with key-management processes—since these determine whether the deployment actually provides the intended protection.

Compliance officers

Compliance teams assessing how cardholder data is rendered unreadable need to understand that using AES is not by itself a validation of any specific control. They should map the cryptographic approach to the applicable PCI DSS requirements for the version in force, confirm wording against the current published standard, and verify that key-management and storage controls are also addressed.

Merchant risk and payment processing teams

Teams overseeing how systems store and transmit payment data should recognize that encryption with AES may help protect cardholder data but does not permit storage of sensitive authentication data after authorization. They should also distinguish encryption from tokenization, truncation, and masking when evaluating how a given approach affects scope.

Inside AES

Symmetric block cipher

AES is a symmetric-key algorithm, meaning the same key is used to encrypt and decrypt data. It operates on fixed-size blocks of data (128 bits), distinguishing it from asymmetric (public-key) cryptography, which uses separate keys.

Supported key lengths

AES is defined for key sizes of 128, 192, and 256 bits. Longer keys increase the theoretical work factor for brute-force attacks. The choice of key length should be aligned with organizational cryptographic policy and applicable standards.

Modes of operation

AES as a block cipher must be used within a mode of operation (for example, CBC or an authenticated mode such as GCM) to encrypt data larger than a single block. The security properties depend heavily on the mode chosen and correct use of initialization vectors or nonces; the label 'AES' alone does not describe how data is protected.

Key management dependency

The protection AES provides depends on the confidentiality and integrity of the cryptographic keys. Key generation, distribution, storage, rotation, and destruction are handled by surrounding key management processes, not by the algorithm itself.

Role in protecting cardholder data

AES is one cryptographic mechanism that may be used to render stored cardholder data, such as the PAN, unreadable under PCI DSS. Encryption is distinct from tokenization, truncation, masking, and hashing, and its effect on scope depends on implementation and validation, not on the use of AES alone.

Common questions

Answers to the questions practitioners most commonly ask about AES.

Does using AES encryption mean stored cardholder data is automatically out of PCI DSS scope?

No. Applying AES does not by itself remove data from PCI DSS scope. Encryption is one control, but scope reduction depends on the overall implementation and validation, including how and where encryption keys are managed. If your environment can decrypt the data or has access to the keys, the encrypted data and the systems handling it generally remain in scope. Tokenization, truncation, masking, and hashing affect scope differently, and none of these outcomes follow from the label alone. Confirm scope treatment against the current published PCI DSS and any applicable guidance rather than assuming encryption equals descoping.

Can I store sensitive authentication data after authorization if I encrypt it with AES?

No. Sensitive authentication data, which includes full track data, CAV2/CVC2/CVV2/CID, and PINs and PIN blocks, must not be stored after authorization even when encrypted. AES does not create an exception to this prohibition. Encryption is relevant to protecting certain cardholder data that may be stored under defined controls, such as the PAN, but it does not authorize retention of sensitive authentication data. Confirm the specific storage requirements against the current published PCI DSS.

How does AES relate to protecting the PAN under PCI DSS?

AES is a symmetric encryption algorithm that can be used as part of rendering the PAN unreadable where it is stored, which is one of the approaches PCI DSS recognizes for protecting stored cardholder data. Whether a given AES implementation satisfies the applicable requirement depends on factors such as key strength, mode of operation, and key management. Requirement wording and numbering differ between PCI DSS versions, so confirm the exact obligations against the current published standard rather than relying on a fixed reference.

Where does key management fit when using AES for cardholder data protection?

Key management is central to whether AES provides meaningful protection under PCI DSS. Controls typically address generation, distribution, storage, rotation, retirement, and access restriction for cryptographic keys, and improper key handling can undermine otherwise strong encryption. Because keys that are accessible to the same environment as the ciphertext may keep that data in scope, key management design also influences scope outcomes. Confirm the specific key management requirements against the current published PCI DSS.

Is AES the same as the mechanisms used in P2PE or in PIN protection?

AES is an encryption algorithm and is not itself a standard. The requirements for protecting PIN data are governed by PCI PIN, and point-to-point encryption solution requirements are governed by PCI P2PE; these are separate standards from PCI DSS. AES may be used within solutions validated under those programs, but using AES does not mean a solution meets PCI P2PE or PCI PIN requirements. Validation against the relevant standard, not the choice of algorithm, determines compliance.

What should I verify when deciding whether an AES implementation is appropriate for my environment?

Consider the key length and mode of operation, how keys are managed across their lifecycle, whether the same environment that holds ciphertext also holds decryption capability, and how the implementation maps to the applicable PCI DSS requirements for rendering stored data unreadable. Also consider that encryption addresses data at rest or in transit but does not by itself address other risks such as access control or logging. Confirm all specifics against the current published PCI DSS and any applicable standard for your use case.

Common misconceptions

Encrypting data with AES lets you safely store sensitive authentication data such as full track data, CAV2/CVC2/CVV2/CID, or PIN blocks.

Sensitive authentication data must not be stored after authorization, even when encrypted. AES may be used to protect certain stored cardholder data under defined controls, but encryption does not create an exception permitting retention of sensitive authentication data.

Using AES automatically takes a system out of PCI DSS scope or guarantees compliance.

The effect of encryption on scope depends on the full implementation, including key management, mode of operation, and whether the entity can decrypt the data, and on how the approach is validated. Simply labeling data as 'AES encrypted' does not by itself remove it from scope or satisfy a requirement.

AES and tokenization are interchangeable ways to protect a PAN.

AES is a reversible encryption algorithm, while tokenization typically substitutes a surrogate value with no algorithmic relationship to the original data. They transform data differently and have different scope and key management implications; the appropriate choice depends on the use case and how it is validated.

Best practices

Select AES key lengths and modes of operation in line with your cryptographic policy and applicable standards, favoring authenticated modes where integrity of the ciphertext matters.

Treat key management as central: define processes for key generation, secure storage, access restriction, rotation, and destruction, since the strength of AES protection depends on the secrecy and integrity of the keys.

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

Verify how your encryption approach affects PCI DSS scope through proper validation rather than assuming the AES label alone reduces scope, and confirm requirements against the current published standard.

Distinguish encryption from tokenization, truncation, masking, and hashing when documenting how each data element is protected, and choose the mechanism that fits the specific use case.

Ensure initialization vectors or nonces are generated and handled correctly for the chosen mode, as misuse can undermine the confidentiality that AES is intended to provide.