Risky Business summarized the work as an attack on expired contactless cards, but the underlying USENIX Security 2026 paper provides a narrower, more troubling explanation. The attack does not defeat the card’s cryptographic keys or manufacture a valid payment cryptogram. It changes an expiry value that the point-of-sale terminal uses locally, while leaving the issuer-facing data and the card-generated cryptogram intact.
That split is the actual security failure. A payment system can have strong cryptography and still make the wrong authorization decision if the terminal, network, and issuing bank each assume another party enforced a security rule.
Visa Kernel 3 separates the expiry checks
EMV contactless cards carry expiration information in more than one place. In the Visa Kernel 3 transactions studied by Raja Hasnain Anwar, Gerard DeCunha, and Muhammad Taqi Raza, the POS terminal uses the Application Expiration Date for its local expired-card check. The issuer, meanwhile, receives expiry information via Track 2 Equivalent Data in the online authorization request.
The researchers found that the terminal-facing date was not cryptographically bound to the data whose integrity the terminal verifies. An NFC man-in-the-middle relay can therefore present a future date to the terminal without invalidating the card’s normal cryptographic checks. The terminal believes the physical card remains in date and sends the payment onward for online authorization.
The issuer then faces the decisive question: does it authorize based only on an active account number and a valid application cryptogram, or does it confirm that the specific physical credential — including its expiry and replacement status — remains valid? In the successful tests, the latter check was missing or ineffective.
Visa’s own older public U.S. acquirer implementation guide says contactless readers should check the expiry date in Track 2 Equivalent Data and decline an expired contactless application. The research does not show a terminal simply ignoring that instruction. It shows a relay feeding the terminal a modified input before that check occurs, then exploiting the fact that Visa Kernel 3 does not require a cryptographically protected consistency link between the terminal’s expiry view and the issuer’s authorization view.
That is a more consequential design issue than a defective reader. Replacing the terminal alone does not solve it if the issuer cannot independently tell that a terminal-side lifecycle check was bypassed.
Mastercard, American Express, and Discover resisted the same edit
The UMass team tested cards and configurations across Visa, Mastercard, American Express, and Discover. Their results do not support treating every contactless card as exposed.
Mastercard Kernel 2 rejected the expiry manipulation because it checks the consistency of the two expiry representations. Changing the terminal’s application-expiry field while leaving issuer-facing Track 2 data intact caused a card-data error and a failed transaction. Altering the Track 2 data, in turn, was detected during authorization.
American Express Kernel 4 cryptographically protects the relevant static record data, according to the paper. An in-flight expiry edit produced a signature-validation failure. Discover Kernel 6 similarly binds the relevant data into an authenticated transaction hash, so the modification was detected and the payment was declined.
Visa Kernel 3 behaved differently: replacing the terminal-facing date with a future value allowed the terminal-side restriction to pass without a corresponding integrity failure. The researchers’ preliminary testing found that Visa was the only one of the four payment-kernel families in their study that warranted deeper investigation of this exact expiry-revival scenario.
That distinction matters for IT and security teams evaluating payment risk. The research is evidence of a protocol- and implementation-specific enforcement gap, not proof that NFC payments as a category have lost their security controls.
The bank result is narrower than the newsletter summary
The submitted Risky Business item says five banks did not catch the attack. The USENIX paper does not establish that conclusion.
The researchers evaluated configurations involving five major U.S. banks, but their end-to-end tests of expired-card revival document divergent outcomes from two anonymized Visa issuers. One, identified as Bank A, authorized the altered expired card in controlled tests at $1, $100, and $500, and also in small real-world retail and grocery purchases. Another, Bank B, declined the old expired card and prompted use of the replacement card.
The paper explicitly says its retail tests validate that the attack can work outside the lab; they do not constitute an ecosystem-wide measurement of merchants, terminal vendors, issuers, or payment configurations. It also does not name the banks, so cardholders and enterprise payment administrators cannot map the test labels to an institution or product line.
There is a second finding that should concern issuers regardless of network: one tested card had been automatically replaced before its printed expiry date, yet both the old and new cards could still transact against the same underlying account. That was observed in a Discover configuration and did not involve the Visa expiry-edit technique. It indicates a separate lifecycle-management question — when a bank sends a replacement, whether the original card is actually revoked may vary by issuer policy.
The record therefore supports a more precise conclusion: some issuers appear to authorize based on account continuity where a customer reasonably expects a specific old or expired credential to be retired. The research does not establish how common that behavior is.
Relay resistance existed, but was not used in the testbed
The attack requires more than a discarded card number. The attacker needs the physical expired card or NFC proximity to it, plus a relay positioned between the card and a payment terminal. The UMass implementation used two NFC-capable Android phones and a custom application; one communicated with the old card and the other emulated the card at the POS terminal.
That physical requirement limits scale compared with a remote card-not-present fraud campaign. It does not make the threat theoretical. Old cards are often stored, tossed into household waste, misplaced, or retained after a replacement arrives. A cardholder who believes expired plastic is worthless may be less cautious about it precisely when it should still be destroyed.
The test relay added enough delay to bring average transactions to roughly 415 milliseconds, still inside the applicable 500-millisecond response window. EMV specifications include an optional Relay Resistance Protocol intended to identify added relay latency through timed challenges. The researchers found that none of the physical cards or POS terminals in their testbed implemented it.
Optional defenses are not defenses an attacker has to defeat when they are not deployed. But relay resistance would only address the relay precondition; it would not cure the deeper lifecycle-policy issue in which an issuer authorizes an old credential because the account and cryptogram still appear valid.
Issuers need to revoke cards, not merely issue replacements
The immediate advice for cardholders is straightforward: once a replacement card is active, cut through its chip and magnetic stripe before disposal, or use an issuer-provided return process. Do not place intact expired cards in ordinary trash or recycling.
For banks, acquirers, and payment-terminal vendors, the response should go beyond another disposal reminder. The UMass researchers recommend that issuers authorize against the combination of PAN and expiry date rather than the PAN alone, and consistently decline credentials marked expired or replaced. A replaced card needs a revocation state enforced across low-value contactless transactions as well as every other authorization route.
Visa Kernel 3 also needs a defensible connection between the expiry information checked at the POS terminal and the issuer-visible payment data. Cryptographically binding the terminal’s expiry field, enforcing equality between duplicate expiry representations, and preserving terminal validation outcomes for the issuer would each close part of the gap. At present, the researchers say Kernel 3 sends an all-zero Terminal Verification Results value to the issuer, removing a standard signal that could reveal a local validation failure or bypass.
The practical consequence is clear: expiration dates should no longer be treated as proof that an old physical card is harmless. Until payment networks and issuers can show that expiry and replacement state are enforced end to end, destroying obsolete cards remains a necessary control — and issuers should assume that a replacement mailed to a customer has not, by itself, retired the card it replaced.