Whose Job Is It to Notice Your Card Expired?

There is a date printed on the front of your card, and almost everyone treats it as a switch that turns the card off on the day it names. Merchants believe this. Cardholders believe it. Plenty of building access systems, age checks and account recovery flows quietly believe it too.

Three researchers at the University of Massachusetts Amherst tested the belief and found it is not a property of the card at all. It is a policy check, run by whichever machine happens to be looking at the moment, and it sits outside the cryptography that everyone assumes is protecting it. Their paper, "Zombie Cards Back Online: Reviving Expired Credit Cards for Contactless Payments," was presented at the 35th USENIX Security Symposium in Baltimore in August 2026.¹

Clever attacks always exist, so that is not the part worth your time. What earns the attention is that the same field is protected by three card networks and not by the fourth, that the difference has been sitting in a public specification for years, and that the body which writes that specification is owned by the four networks.

What did the researchers actually test?

The authors are Raja Hasnain Anwar, Gerard DeCunha and Muhammad Taqi Raza, all at UMass Amherst. Anwar is a doctoral candidate in the university's Khwarizmi Lab, and Raza is an assistant professor in the Riccio College of Engineering.²

Their setup is a relay. Two ordinary Android phones sit between a physical card and a real point of sale terminal, one near each end, passing the conversation back and forth over a wireless link. The relay does not break any encryption and does not extract any key. The threat model in the paper is explicit that the attacker holds no cryptographic secrets and cannot produce a valid transaction cryptogram. The attacker's entire reach is limited to fields that are not cryptographically protected at the moment they cross the contactless interface.¹

The attacker also needs the card. Not necessarily in hand: the paper describes physical proximity, which covers a card that was discarded, lost or stolen, as well as a device brought within range of a card sitting somewhere. Possession is the common case, and it is the one worth acting on. This is not an attack on the card in your pocket while you stand in line.

On method, the researchers were unusually disciplined, and it matters for how much weight the results carry. They used their own cards and their own accounts. For the purchases made outside the lab, they told the merchants in advance what they were doing, made at most two transactions at each one, and bought actual goods. They disputed nothing and paid every charge in full. They released no tooling and no source code.¹

The results are not uniform, and the paper is careful about that. Across trials spanning multiple kernels, terminals, merchants and five major US banks, one issuer approved the revived card at one dollar, one hundred dollars and five hundred dollars on a terminal the researchers had themselves registered as a merchant, and also approved two small purchases at a campus retail merchant and a campus grocery merchant. Another issuer declined consistently and told the cardholder to use the replacement card. The banks are anonymized in the paper and I am not going to guess at them.¹

Why is the expiration date not protected?

In a contactless transaction, the expiry date shows up in two separate places in what the card sends. One copy is read by the terminal standing in front of you, which uses it for its own local decision about whether to keep going. The other copy travels onward to your bank inside the data used for authorization. Visa's kernel, meaning the network specific processing logic the terminal runs for a Visa card, does not require those two copies to agree, and does not include the terminal's copy in the data covered by the card's signature.¹

So the terminal's copy is a plain, unsigned value that decides a validity question. Alter it in transit and the signature still verifies, because the signature was never over that value. The bank's copy is untouched, so nothing looks wrong downstream either.

Two further findings make it worse, and neither is about the date.

The first is that the card's cryptographic material outlives the card. Card certificates carry their own validity periods, and the specification only requires that a certificate last at least as long as the card, not that it stop when the card stops. Issuers routinely let certificates run past the printed date to cover the overlap while a replacement is in the mail. So an expired card can still produce perfectly valid cryptographic evidence of being a genuine card. It is genuine. It is simply retired, and nothing in the math knows that.¹

The second is the part I cannot get past. A terminal keeps a small status register recording the outcome of every security and validation check it performed, including whether it decided the application was expired. Visa's kernel specifies that the register forwarded to the issuer is set to all zeros. The bank does not receive the terminal's findings. It receives a blank form.¹

That shape is familiar to anyone who reviews controls. The check was performed. The result was recorded. The record was never transmitted to the party who was supposed to rely on it. Somebody signed the workpaper and then mailed an empty envelope.

Why did three other networks block the same change?

The researchers tried the same modification against the other major networks' kernels and it failed against all three, for three different reasons. Mastercard's kernel requires the terminal to compare the two copies of the expiry against each other and treats a mismatch as a card data error, declining rather than proceeding. American Express includes that record data in what the issuer's signature covers, so an edit produces a hash mismatch and the transaction ends. Discover uses an authentication scheme that binds the card's returned data into a hash checked late in the transaction, so an edit makes the computed value diverge from the signed one.¹

Same protocol family, same data element, three independent implementations that catch it and one that does not.

A check that three of four networks enforce and the fourth does not is a house preference that happens to be written down. Standards are what you can rely on without asking whose logo is on the card, and by that test expiration is not standardized in contactless payments. The researchers put it more precisely: expiration is enforced as distributed policy with no mandatory end to end integrity binding.¹

Who writes the specification that Visa followed?

EMVCo. And EMVCo is collectively owned by six organizations: American Express, Discover, JCB, Mastercard, UnionPay and Visa. Each member seats two representatives on the Board of Managers.⁴

EMVCo describes itself as solely responsible for creating and maintaining the EMV specifications, which it publishes royalty free. It is equally clear about what it does not do. It states that it does not mandate the use of the specifications, does not establish obligations, requirements or recommendations for implementation, and does not mandate or enforce compliance. Those responsibilities, it says, sit with the payment networks independently.⁴

Read that structure as an org chart. Six networks jointly own the body that writes the security specification. The body writes the specification and disclaims any authority to require or enforce it. Enforcement returns to the six networks, each for itself. There is no independent party anywhere in the loop.

The specification is also more than one document. Contactless processing is split into separate kernel books, and EMVCo defines a contactless kernel as the set of functions the acceptance device uses to process a contactless transaction.⁵ The books are numbered by network. Visa's is the third. So the network is not merely subject to the specification; its own processing rules are a named chapter of it.

There is also a mandatory test. Visa's own guidance to acquirers and merchants describes an extensive EMVCo defined Level 2 approval process that every EMV kernel must complete through laboratory type approval testing before it can be used in terminals, with approval renewed at defined intervals to retain compliance.⁶

So a lab does test the kernel. What the lab tests is conformance to the specification. A kernel that leaves the expiry date outside the signed data is conforming, because the specification does not require it to be inside. The test was run and the test was passed, and the test was not looking at the field that decides validity.

That is the oldest control failure there is, and it has nothing to do with cryptography. It is a scoping failure. Somebody drew a boundary around what gets protected, the boundary excluded a field that decides validity, and every downstream process, including the compliance lab, inherited the boundary without questioning it.

What have Visa and the banks said?

The researchers disclosed to Visa and to the affected banks in May 2025. Their report included a step by step reproduction guide, full protocol traces and a video demonstration. They reached out again in December 2025, and made further contact with all notified parties during the paper's review cycle.¹

The paper states that as of the time of acceptance, the Visa report had passed initial triage and was undergoing reproduction by Visa's red team, and that neither Visa nor the notified banks had provided any update on the status or nature of mitigations. The researchers' own project page says the same as of publication: no confirmed mitigation.¹³

No public statement from Visa addressing the finding appears in its published materials. That absence is worth stating plainly and worth not over reading. A company reproducing a reported issue with its own red team is doing the normal thing, and reproduction takes time. Fifteen months without a public position on a demonstrated card present bypass is a fact about disclosure practice, and readers can weigh it for themselves.

Who actually eats the loss?

This is where the story gets less frightening and more annoying, which is usually where these stories end up.

The revived card carries an account number that is still open, because issuers commonly keep the same number across a reissue and change only the date. A successful transaction is therefore an unauthorized charge on a live account. It is not, in the ordinary sense, a lost card scenario.

For a credit card, Regulation Z caps a cardholder's liability for unauthorized use at the lesser of fifty dollars or the amount obtained before the issuer is notified, and even that applies only where the issuer met specific disclosure conditions. Unauthorized use is defined as use by a person with no actual, implied or apparent authority, from which the cardholder receives no benefit.⁸ The Federal Trade Commission's own summary is blunter: if your account number is used but your card was not lost or stolen, you are not responsible for charges you did not authorize.¹¹

The mechanism for getting it reversed is the billing error procedure, and its timing is the part people miss. A charge for an extension of credit not made to you counts as a billing error. Your written notice has to reach the creditor no later than sixty days after it transmitted the first statement showing the charge. The creditor must acknowledge in writing within thirty days and must resolve within two complete billing cycles, and in no event later than ninety days. While it is being investigated, you need not pay the disputed amount and the creditor may not try to collect it.⁹

Debit is worse, and the difference is real money. Regulation E ties exposure to how fast you speak up: fifty dollars if you notify within two business days of learning about the loss, five hundred dollars if you are slower than that, and no cap at all for transfers occurring more than sixty days after the statement showing the first one was sent.¹⁰ The FTC lays out the same tiers and adds the same carve out as for credit: where the number is used without the card being lost or stolen, you are covered provided you report within sixty days of the statement.¹¹

Then there is Visa's Zero Liability Policy, which is broader than the regulation and is not the regulation. It promises you will not be held responsible for unauthorized charges, excludes certain commercial card transactions, anonymous prepaid transactions and anything not processed by Visa, and requires issuers to replace funds within five business days of notification. The replacement is provisional, and the policy states it may be withheld, delayed, limited or rescinded based on gross negligence or fraud, a delay in reporting, investigation and verification of the claim, and account standing and history.⁷

That is a promise with discretion attached. The regulation is a floor with none. When the two disagree, you are standing on the floor. Know which one you are standing on before you need it.

So the honest answer on exposure: for most people this is a time cost, not a money cost. Reading a statement you would rather not read, a phone call, a letter that has to be written and a copy kept, and up to ninety days of an open item. That is not nothing, but the loss itself lands on the issuer, and through network rules on the merchant who accepted a transaction that looked entirely normal from where they stood.

What should you do with the card in the drawer?

The researchers' first countermeasure is physical rather than technical, which means the expired card has to be genuinely destroyed rather than dropped in a drawer or a bin. They recommend cutting through both the chip and the magnetic stripe, or returning the card through an approved channel.¹ The FTC's guidance is compatible and more specific about the chip.¹¹

• Destroy the chip, not just the plastic. The chip holds the working cryptographic material, and the FTC notes it can be hard to cut, so smashing it is a reasonable answer.
• Cut through the stripe and the number. The FTC advises cutting through the account number, the magnetic stripe and the security code before disposal.
• Separate the pieces. Both the FTC and the university's release recommend putting fragments in different bags or bins rather than leaving the whole card reassemblable in one place.
• Call the issuer about metal cards. The university's release advises contacting customer service for metal cards rather than improvising with household tools.
• Watch the accounts you think are closed. The release specifically recommends monitoring transactions on accounts you believe are permanently closed, which is precisely the account nobody looks at.

What you should not do is change how you pay. The researchers say directly that you do not need to change how you use contactless payments, provided expired cards are destroyed rather than discarded carelessly.³ The card you tap every day is not the exposure. The one in the junk drawer from three years ago is.

One more finding deserves its own line, because it complicates the tidy version of this advice. The researchers also tested a card that had not yet expired but had been automatically replaced by the issuer ahead of its printed date. Both the old card and its replacement kept completing transactions against the same underlying account, with no modification at all. That is not an expiry problem. That is a revocation problem, and it means "I have the new card now" is not a reason to relax about the old one.¹

Has anyone warned about this class of problem before?

Repeatedly, and for close to twenty years.

In 2007, Saar Drimer and Steven Murdoch presented work at USENIX Security showing that relay attacks on smartcards were practical against a live payment deployment, and proposed a distance bounding defense. They noted at the time that one significant reason vulnerable systems kept being deployed was that designers considered relay attacks too difficult and costly for attackers to bother with.¹² In 2014, Martin Emms and colleagues at Newcastle University showed contactless cards approving very large foreign currency transactions without the cardholder's PIN, sidestepping the domestic contactless limit entirely.¹³ In 2021, David Basin, Ralf Sasse and Jorge Toro-Pozo at ETH Zurich built a formal model of the EMV standard, described the specification as running over two thousand pages, and used the model to find a flaw allowing a victim's Visa contactless card to be used for amounts that require cardholder verification without knowing the PIN.¹⁴

The industry has an answer for the relay half of this. EMV defines a Relay Resistance Protocol, in which the terminal issues a timed challenge and a response arriving too late ends the transaction. It would catch the delay a relay introduces. It is optional. None of the physical cards or terminals in the UMass testbed implemented it, which the researchers describe as consistent with a countermeasure that remains sparsely deployed.¹

Nineteen years is a long time for a defense to stay optional. Optional controls do not get implemented. They get budgeted.

What does this standard actually guarantee?

Nothing failed cryptographically. Every certificate verified, every cryptogram checked out, and the card really was the card. That is the part that should change how you read the word "secure" on a payments product page.

What failed was scope, ownership and reporting. The field that decides whether a card is still valid was left outside the protected boundary. Responsibility for enforcing validity was split across a terminal, a network kernel and an issuer, with no party required to be the last line. And the one message that would have told the issuer the terminal saw a problem is specified to arrive as a row of zeros.

The researchers' proposed fixes follow those same three lines. Bind the terminal's expiry input to data that fails verification if it is altered. Require the two copies of the expiry to be checked against each other at the earliest point where that is possible, and make a mismatch visible to the issuer. Have issuers authorize against the pair of account number and expiration date rather than the number alone, and treat a replaced card as revoked across every authorization path, including the low value ones optimized for acceptance. Stop forwarding a status register of zeros. And when a kernel detects an inconsistency in authenticated data, fail closed rather than falling back to sending the transaction online.¹

Until those are true, the date on the front of your card is not a control. It is a printed claim, checked by a machine with no way to prove it, reported to a bank that never sees the answer.