The common belief is that cryptographic protections in payment systems are either fully secure or completely vulnerable. If a payment terminal accepts your card, the security checks have passed.
Why This View Misses the Point
This binary thinking overlooks a key design choice in modern payment systems: selective authentication. Not every data element in a contactless transaction is cryptographically bound to the card's digital signature. Some fields are sent in plaintext and validated later, if at all, depending on where enforcement occurs in the chain.
Researchers at the University of Massachusetts Amherst highlighted this issue. They demonstrated at USENIX Security 2026 that expired Visa contactless cards can be revived for unauthorized payments through man-in-the-middle tampering. This attack is possible because Visa's kernel doesn't cryptographically bind the expiration date that the point-of-sale terminal reads.
Here's how it works: The card presents an expiration date to the checkout terminal, but that date isn't covered by the card's digital signature. An attacker can alter what the terminal sees, while the card's security checks still appear valid. The terminal processes the transaction and sends it for online authorization. Whether the payment goes through depends on how the issuing bank handles the request.
American Express, Discover, and Mastercard configurations resisted this attack in testing. Visa's approach didn't, due to "a compromise to ensure backward compatibility with old POS terminals, and also to meet their performance criteria."
The core issue is that performance requirements led to a security trade-off, creating an exploitable gap.
The Evidence Lives in Your Control Environment
If you're evaluating financial transaction systems for SOC 2 or ISO/IEC 27001, this research should influence how you assess vendor-specific implementations.
SOC 2 Trust Services Criteria CC6.6 requires detection and monitoring procedures to identify anomalies. But if your payment processor's kernel design doesn't cryptographically bind critical transaction data, your monitoring can't detect tampering that leaves the digital signature intact. You're detecting symptoms downstream, not the manipulation itself.
ISO/IEC 27001:2022 Annex A Control 5.22 (authentication of information) and Control 8.24 (use of cryptography) assume you've verified that cryptographic mechanisms protect data integrity where it matters. The Visa kernel example shows that assumption needs testing. Which transaction fields are cryptographically protected? Which ones rely on later validation by a different party? Where does enforcement actually happen?
The researchers notified Visa in May 2025. As of the conference presentation, neither Visa nor the affected banks confirmed mitigation. This timeline highlights the challenges of coordinated disclosure in complex payment ecosystems: fixes take time, and you can't assume the vulnerability window is closed just because a vendor was notified.
What to Do Instead
First, map your cryptographic binding assumptions. If you process payment card data, document which transaction elements your payment processor cryptographically protects at each stage. Don't assume the EMV protocol implementation is uniform across card networks. The researchers found meaningful differences between Visa, Mastercard, American Express, and Discover.
Second, shift your risk assessment approach. ISO/IEC 27001 Clause 6.1.2 requires information security risk assessment. For payment systems, add a specific evaluation: "Where does transaction validation occur, and what happens if an earlier check is bypassed?" The Visa kernel case shows that kicking authentication to the issuing bank creates variable outcomes. Some banks in the study rejected the tampered transactions; others didn't.
Third, test your compensating controls. SOC 2 Type II evidence should demonstrate that your transaction monitoring detects anomalies that upstream cryptographic controls might miss. If you're relying on post-authorization fraud detection, document the detection window and your response procedures. Control design matters less than control effectiveness when the protocol itself has gaps.
Fourth, engage your payment processor on protocol-specific risks. Your vendor risk assessment (ISO/IEC 27001 Annex A Control 5.19) should include questions about selective authentication, cryptographic binding of transaction data, and how expiration date validation is enforced. Generic questionnaires won't surface these implementation details.
When the Conventional Wisdom IS Right
Cryptographic protections in payment systems work when applied correctly. The researchers found that Mastercard, American Express, and Discover configurations resisted the expired card attack. Those implementations apparently bind critical transaction data to the card's digital signature in ways that prevent tampering.
The binary view of payment security holds true at the protocol design level. EMV's Offline Data Authentication and issuer-verified cryptograms are sound mechanisms. The problem emerges in vendor-specific kernel implementations where design choices prioritize backward compatibility and transaction speed over complete cryptographic binding.
For most organizations, the risk of expired card revival attacks is theoretical. You're unlikely to see this in production unless you operate high-value point-of-sale environments where attackers can position NFC proxy devices. The researchers' work is more a case study in how performance trade-offs create exploitable gaps than an immediate operational threat.
But the lesson scales: Assuming a standard protocol provides uniform security across all implementations misses the vendor-specific design choices that determine actual risk exposure. That gap shows up in audit findings when your documented controls don't match the technical reality of how your systems validate data.
The conventional wisdom that cryptographic protections are binary isn't wrong. It's incomplete. Security depends on what gets protected, when it gets checked, and who enforces the validation. In payment systems built for speed and backward compatibility, those details matter more than the protocol specification.
