The Payment Card Industry Data Security Standard (PCI DSS) requires businesses to protect cardholder data when it’s stored and when it moves across a network. That means requiring strong cryptography, as well as a set of supporting rules covering everything from certificate strength to the generation, storage, and retirement of cryptographic keys.
Meeting these PCI encryption requirements affects more than your compliance checklist. It can help shrink your attack surface and shape how exposed your business is if a breach ever happens. The average cost of a data breach reached $4.44 million globally in 2025, underscoring the importance of protecting sensitive records. Below, we cover what PCI DSS actually requires for encryption, which algorithms and protocols meet that bar today, and how encryption interacts with related strategies such as tokenization and network segmentation.
Key takeaways
PCI DSS requires strong cryptography for cardholder data both at rest and in transit, with Advanced Encryption Standard (AES) with a 256-bit key and Transport Layer Security (TLS) 1.2 or higher as the accepted baselines.
Since encryption and tokenization solve different problems, you can reduce your PCI compliance scope by combining point-to-point encryption (P2PE) with tokenization.
Weak key management is one of the most common reasons businesses fail a PCI DSS assessment, despite sound underlying cryptographic algorithms.
What are PCI encryption requirements?
PCI DSS encryption rules are defined in Requirement 3 in the compliance checklist, which covers stored cardholder data, and Requirement 4, which covers data moving across networks. PCI auditors check both of these areas when evaluating how card information is handled.
According to Requirement 3, if you store the primary account number (PAN), you must render it unreadable wherever it appears, whether in a database, log file, or backup. While strong cryptography is the main protection method, truncation and hashing are also options, especially for masking PANs on receipts or customer-facing screens. Requirement 4 states that all card data that crosses open, public networks must be encrypted end to end. There aren’t exceptions for internal convenience or legacy environments predating the standard.
Sensitive authentication data (SAD) takes a different approach that includes the full magnetic stripe or chip data, the card verification value (CVV), and the PIN block. PCI DSS doesn’t let you store any of this after authorization completes, regardless of its encryption status.
Which cryptographic standards and protocols does PCI DSS approve for encryption?
PCI DSS requires “strong cryptography,” defined by the PCI Security Standards Council as any method providing at least 112 bits of effective key strength. In practice, that definition points to a short list of accepted choices:
Data at rest: AES-256 is the common standard. It clears the strength threshold and has wide support among cloud providers and payment infrastructure. Triple DES (3DES) still technically qualifies in some configurations, but the PCI Security Standards Council has flagged it for deprecation, and most new systems skip it entirely.
Asymmetric encryption: Used for exchanging symmetric keys or signing certificates, this generally means Rivest–Shamir–Adleman (RSA) at 2048 bits or higher, or elliptic curve cryptography (ECC) at 224 bits or higher.
Data in transit: TLS 1.2 is the floor, with TLS 1.3 increasingly considered the practical default. SSL, in every version, and early TLS versions (1.0 and 1.1) are explicitly disallowed.
Cipher suites: Qualifying suites must have no known vulnerabilities, which rules out RC4 (Rivest Cipher 4) and any export-grade ciphers left over from older configurations.
Certificate strength: Public-facing certificates need 2048-bit RSA or stronger, current expiration dates, and issuance from a trusted certificate authority.
Protocol negotiation: Servers must reject connection attempts that fall back to disallowed protocol versions rather than silently permitting them.
How does encryption reduce your PCI compliance scope?
Compliance scope in PCI DSS terms means every system that stores, processes, or transmits cardholder data, plus anything connected to those assets that could affect their security. This is known collectively as the cardholder data environment (CDE).
If a system handles encrypted cardholder data without access to the means to decrypt it, the PCI Security Standards Council treats it as out of scope, or at least in a reduced-scope category. This is where P2PE comes in. A PCI-listed P2PE solution encrypts card data at the point of interaction, inside validated hardware. Decryption is confined to the P2PE solution provider’s secure environment rather than the business’s own infrastructure.
A validated P2PE solution typically qualifies for a P2PE Self-Assessment Questionnaire (SAQ), one of the shorter PCI SAQs, since P2PE substantially narrows the assessment scope. Segmentation narrows it further. When card-data systems are isolated on their own network segment, separate from general business systems, it allows systems that never see cardholder data to be kept out of the assessment entirely.
Encryption or tokenization: Which strategy best meets your PCI encryption needs?
Encryption transforms the PAN into unreadable ciphertext, but the original number still exists somewhere. Anyone with the right key can reverse the process. Tokenization removes the PAN from the business’s environment entirely and replaces it with a token that has no mathematical relationship to the original number and no value if it’s stolen.
When there’s a need to reference a customer’s payment method after the initial transaction, such as with subscriptions, saved payment methods, or one-click checkout, tokenization makes a difference. If an encrypted PAN is stored internally, you still hold a full card number and everything that comes with it, including key management duties, expanded audit scope, and exposure if the associated key is compromised. But if you store a token instead, one that is generated and held by a payments provider such as Stripe, then the sensitive value never touches your systems in the first place. Many setups combine the two, with tokenization used for anything stored long-term and encryption used for anything that moves across a network.
Why is key management an overlooked part of PCI encryption?
Encryption depends on how well its keys are protected, and those practices are often overlooked. Be mindful of the following:
Split knowledge and dual control: A complete cryptographic key doesn’t need to be accessible to a single person. Splitting key components across multiple people and requiring more than one person to reconstruct a key keeps any one individual from single-handedly compromising the environment.
Secure key storage: Keys need to be stored separately from the data they protect, typically in a hardware security module (HSM) or an equivalent key management system; they must be kept out of the same database or file system as the encrypted values.
Defined cryptoperiods: Every key needs a documented lifespan after which it’s retired and replaced, based on factors such as how much data it protects and how often it’s used.
Documented key-custodian responsibilities: Written procedures need to identify who’s responsible for key management tasks; those custodians have to acknowledge that responsibility formally.
Under PCI DSS 4.0, businesses must review their cryptographic architecture at least once every 12 months to confirm that the algorithms, protocols, and key lengths used still meet current standards and haven’t become outdated.
What happens if your business fails to meet PCI encryption requirements?
Failure to meet PCI DSS encryption requirements changes what happens before and after a breach. Before any incident, noncompliance shows up in the annual review process. Acquiring banks and card networks could flag a business as noncompliant, affecting its ability to keep processing card payments and prompting closer monitoring or additional review requirements in the future.
The consequences compound if a breach occurs and an investigation finds those controls weren’t met at the time. A forensic investigation is generally required after a confirmed breach involving cardholder data. It will specifically examine whether the PAN was properly encrypted in storage and in transit. If it wasn’t, liability won’t be shared with the payments provider or the acquiring bank, but will instead shift more heavily toward the business.
It can be difficult to rebuild confidence with an acquiring bank or a payments provider after a finding such as this. Since cryptographic failures also tend to surface other weak spots in internal data handling, a bank likely won’t be satisfied by the correction of a single control in isolation when it’s found holes in others.
How Stripe Payments can help
Stripe Payments provides a unified, global payments solution that helps any business—from scaling startups to global enterprises—accept payments online, in person, and around the world.
Stripe Payments can help you:
Optimize your checkout experience: Create a frictionless customer experience and save engineering time with prebuilt payment UIs, access to 125+ payment methods, and Link, a wallet built by Stripe.
Expand to new markets faster: Reach customers worldwide and reduce the complexity and cost of multicurrency management with cross-border payment options, available in 195 countries across 135+ currencies.
Unify payments in person and online: Build a unified commerce experience across online and in-person channels to personalize interactions, reward loyalty, and grow revenue.
Improve payments performance: Increase revenue with a range of customizable, easy-to-configure payment tools, including no-code fraud protection and advanced capabilities to improve authorization rates.
Move faster with a flexible, reliable platform for growth: Build on a platform designed to scale with you, with 99.999% historical uptime and industry-leading reliability.
Learn more about how Stripe Payments can power your online and in-person payments, or get started today.
The content in this article is for general information and education purposes only and should not be construed as legal or tax advice. Stripe does not warrant or guarantee the accurateness, completeness, adequacy, or currency of the information in the article. You should seek the advice of a competent attorney or accountant licensed to practice in your jurisdiction for advice on your particular situation.