List of CA Public Keys (CAPK): Official Sources and Checksums

A CA public key (CAPK) is a payment network’s root RSA public key. An EMV terminal keeps a small table of them and uses the right one to check the issuer certificate on a chip card during offline data authentication and offline enciphered PIN. Each key is identified by the network’s RID plus a one-byte index, and the only authoritative copy is the one the network itself distributes: Visa and Mastercard publish theirs openly. Discover releases its keys through registered channels (as the U.S. Payments Forum describes for US acquirers), and for most other networks we found no open publication at all.

This page lists the CA public keys we could find published openly by the networks that own them, with each key’s identifiers, status, expiry and checksum, and links to the owner’s document for the key value. It then explains how to verify a key you have received, how keys are retired, and the configuration mistakes that cause chip transactions to fail.

Scope: this is an engineering explainer, not a key distribution service. Nothing here is an authoritative production key set. Load keys only from your acquirer, processor, terminal vendor or the network, and re-check status with them. The exact data formats and processing rules are defined in EMVCo specifications, which this page does not reproduce.

Where each network’s CA public keys come from

The RID (registered application provider identifier) is the first five bytes of a payment application’s AID, so it tells the terminal which network’s key table to use. The table below gives the RID for common networks and what we found, on 10 October 2026, about how each one makes its CA public keys available. “Not found openly” means we found no public document from the network itself, not that no keys exist.

For the full set of AIDs behind these RIDs, see the AID reference list.

CA public keys published by their owners

These are the only keys we list: each row comes from the network’s own document, and we recomputed every published checksum from the published key value, and all of them matched. We give the checksum, not the modulus. Take the modulus from the owner’s document (linked in the Sources) or from your acquirer, then check it against the checksum here and in the owner’s current edition. Status and expiry are as the owner states them on the date shown.

Notes on reading this table:

• Visa. The same document lists the 1408-bit (expired 31 December 2024), 1152-bit (31 December 2017) and 1024-bit (31 December 2009) production keys as expired and says they must not be loaded. Visa reviews the active keys’ expiry dates every year and announces changes in Visa Business News.
• Mastercard. The 2018 document is the newest open edition we found. Its index 05 key has passed its stated expiry date. Index 06 was given an “anticipated lifetime” to at least the end of 2028, which may since have changed.
• BankAxept. These three rows are historical: they come from version 1.33 (May 2023) of the Bits AS document, read from a February 2024 archive copy. Version 1.33 also lists test key 81, which expired on 31 December 2022; we leave it out of the table. We have not reviewed any later version, so the rows are not current key-management data. Take BankAxept keys and dates only from Bits.
• Index values are hex. Visa’s transit key index 10 is the byte 0x10 (decimal 16), not ten.

What a CA public key does

EMV offline data authentication is a short certificate chain. The network runs a certification authority. It signs each issuer’s RSA public key into an issuer public key certificate, which is personalised onto the card. The issuer, in turn, signs either the card’s static data (SDA) or the card’s own public key (for DDA and CDA, where the card also signs fresh data during the transaction). Bits AS describes the same arrangement for BankAxept. Its CA issues issuer certificates, card personalisers use them to issue card (ICC) certificates, and those support dynamic authentication and offline PIN encipherment.

Terminal key table                     Card records
-------------------                    ------------------------------
(RID, index) -> CA public key   <--    CA public key index (tag 8F)
        |                              Issuer public key certificate
        | verify / recover             ICC public key certificate
        v                              (or signed static data for SDA)
Issuer public key  ----------------->  verify ICC certificate
        |
        v
ICC public key  -------------------->  verify the card's dynamic signature
                                       (DDA/CDA) or the static signature (SDA)

Basin, Sasse and Toro-Pozo’s analysis of EMV describes the same steps. The card’s records include the index of the CA and the two certificates. The terminal uses the index to fetch the CA public key from its own database, verifies the bank’s certificate with it, and then verifies the card’s certificate. If the terminal has no key for that RID and index, the chain cannot start. Mastercard warns that terminals without its keys may run into payment acceptance problems. Visa says the terminal must hold the matching CA key to complete offline data authentication or offline enciphered PIN. For how SDA differs from DDA and CDA, see SDA vs DDA/CDA.

Two data objects carry the index. The card supplies it as tag 8F, and the terminal’s copy of the selected index is tag 9F22. Both are one byte and only mean something together with the RID. The EMV tag reference has the neighbouring tags.

Anatomy of a CAPK record

Terminal software, vendor tools and network documents all store CA public keys in their own formats, but the content is the same. The fields below are the ones shown in the Visa, Mastercard and BankAxept documents. Modulus values are left out on purpose.

Visa states the checksum construction directly: the hash is “the SHA-1 hash of RID || Index || Modulus || Exponent”. Mastercard describes the same 20-byte SHA-1 over the concatenation of RID, index, modulus and exponent. BankAxept’s document doesn’t spell the construction out, but its four published hashes match it. The expiry date and the algorithm indicators are not part of the hash. A changed expiry therefore doesn’t change the checksum, and a matching checksum doesn’t prove the expiry is right.

How to verify a key before you load it

1. Get the key from an authoritative channel: the network’s own document, or your acquirer or processor. Note the edition and date.
2. Strip formatting. Remove spaces and line breaks, and fold to one case. Do not reorder bytes.
3. Check lengths. The RID is 5 bytes, the index 1 byte, and the modulus byte count matches the stated key length.
4. Concatenate RID, index, modulus and exponent as raw bytes and compute SHA-1. Compare it with the published checksum.
5. Check the status and expiry with the owner’s current edition. The checksum cannot tell you that.

The Node.js module below does steps 2–4. The demo uses a synthetic 176-byte (1408-bit) value, derived from a text seed so the output is repeatable, with exponent 3 under a made-up RID. It is not an RSA key or a payment network key and must never be loaded into a terminal; the checksum calculation works the same way on any byte string. The accompanying tests also check the function against an owner-published value: BankAxept’s TLP:WHITE test key 82, whose published checksum it reproduces.

// CAPK checksum: SHA-1 over RID || Index || Modulus || Exponent (as stated in
// Visa's and Mastercard's public key documents). Node.js ESM, no dependencies.
import { createHash } from 'node:crypto';
import { pathToFileURL } from 'node:url';

// Accepts hex the way it is usually copied from a PDF: spaces, line breaks,
// lower or upper case. Rejects anything else (curly quotes, "0x", odd length).
export function hexToBytes(text, name = 'value') {
  const hex = String(text).replace(/\s+/g, '');
  if (!/^(?:[0-9a-fA-F]{2})+$/.test(hex)) {
    throw new Error(`${name}: not an even-length hex string`);
  }
  return Buffer.from(hex, 'hex');
}

export function capkChecksum({ rid, index, modulus, exponent }) {
  const r = hexToBytes(rid, 'rid');
  const i = hexToBytes(index, 'index');
  const m = hexToBytes(modulus, 'modulus');
  const e = hexToBytes(exponent, 'exponent');
  if (r.length !== 5) throw new Error('rid: must be 5 bytes');
  if (i.length !== 1) throw new Error('index: must be 1 byte');
  if (m.length === 0 || m[0] === 0) throw new Error('modulus: empty or leading zero byte');
  return createHash('sha1').update(Buffer.concat([r, i, m, e])).digest('hex').toUpperCase();
}

export function verifyCapk(record) {
  const expected = hexToBytes(record.checksum, 'checksum').toString('hex').toUpperCase();
  if (expected.length !== 40) throw new Error('checksum: must be 20 bytes');
  return capkChecksum(record) === expected;
}

// SYNTHETIC demo: a fixed 1408-bit (176-byte) value derived from a text seed, so the output is
// the same on every run. It is not an RSA key and not a payment network key; the checksum
// construction does not care whether the modulus is a real key.
function demo() {
  let modulus = '';
  for (let i = 0; modulus.length < 352; i++) {
    modulus += createHash('sha256').update(`ambimat synthetic capk demo ${i}`).digest('hex');
  }
  const record = {
    rid: 'F0 00 00 00 01',          // synthetic, not a registered RID
    index: 'E1',
    modulus: 'C' + modulus.slice(1, 352),  // top bit set, as a real 1408-bit modulus would have
    exponent: '03',
  };
  record.checksum = capkChecksum(record);
  console.log('SYNTHETIC test key - do not load into any terminal');
  console.log('modulus bytes :', hexToBytes(record.modulus).length);
  console.log('exponent      :', record.exponent.toUpperCase());
  console.log('checksum      :', record.checksum);
  console.log('verifies      :', verifyCapk(record));
  const tampered = { ...record, modulus: record.modulus.replace(/.$/, (c) => (c === '0' ? '1' : '0')) };
  console.log('1 nibble off  :', verifyCapk(tampered));
}

if (process.argv[1] && import.meta.url === pathToFileURL(process.argv[1]).href) demo();

Example output:

SYNTHETIC test key - do not load into any terminal
modulus bytes : 176
exponent      : 03
checksum      : 9C393992B57CF0997CE10901089CC5DDE37674F0
verifies      : true
1 nibble off  : false

Lifecycle: expiry, review and retirement

CA public keys are not permanent. Visa’s documents show the pattern clearly:

• The 1024-bit Visa production key expired at the end of 2009, the 1152-bit key at the end of 2017 and the 1408-bit key at the end of 2024.
• The 1984-bit key’s expiry has been pushed out as it was reassessed. It was 31 December 2029 in September 2019 (extended from 2028) and 31 December 2031 in September 2021 (extended from 2030). The January 2026 key document gives 31 December 2035, reviewed annually.
• Visa explains that its CA keys “are scheduled to expire while they are still considered secure”, and that it sets the dates from EMVCo recommendations and its own security reviews.
• Issuer certificates are tied to the CA key. In 2021, Visa’s CA would not sign a certificate under the 1408-bit key with an expiry later than 31 December 2024. In 2019 it stopped signing issuer keys shorter than 1408 bits that expired after 2019.

Version 1.33 of the BankAxept document gave every key a planned expiry of 31 December, allowed terminal service providers a six-month grace period to install new keys, update expiry dates and remove expired keys, and required terminals to store six BankAxept CA keys. Mastercard’s 2018 document ties issuer certificates under its 1984-bit key to that key’s expiry date.

The key lengths keep growing because RSA strength depends on modulus size. NIST SP 800-57 rates a 1024-bit RSA modulus at no more than 80 bits of security, 2048 bits at 112 and 3072 bits at 128. NIST SP 800-131A Rev. 2 does not allow RSA moduli shorter than 2048 bits for generating new signatures in US federal systems, though it still accepts 1024 to 2047 bits for verifying existing ones as “legacy use”. NIST guidance doesn’t bind payment networks. It does explain the trend: the networks have moved from 1024 to 1984-bit keys and manage the remaining risk with fixed expiry dates and regular review.

What this means in practice:

• Your terminal estate needs a way to add and remove CA keys without a software release.
• Any static list, including the table on this page, goes out of date.
• Expiry dates hard-coded into a terminal need updating whenever the network revises them. Visa explicitly asks acquirers to keep the expiry dates correct where terminals store them.

Test keys and live keys must never be mixed

Networks publish separate test keys for test cards and certification tools. Visa’s test keys use indexes 94 and 89. BankAxept’s version 1.33 reserved indexes 81 to 98 for test keys, and index 99 for the UL Brand Test Tool.

All three owners say test keys must not be in production terminals:

• Visa tells acquirers that test keys must not be loaded in production terminals, and its acquirer guide lists removing them as a terminal checklist item.
• BankAxept (version 1.33) says test keys shall not be used in production terminals.
• Mastercard gives the reason. Terminals containing test keys may expose the merchant to fraud from fraudulent chip cards that exploit those keys’ presence. It also asks that live terminals hold only the operational set of live keys.

The reverse gap also causes trouble. A test terminal without the test keys cannot authenticate test cards offline, because their issuer certificates were signed under the test CA.

How terminals receive and update keys

Visa describes the distribution chain plainly: each network maintains its own root key pairs, distributes the public keys to acquirers, and the acquirers load them into their terminals. Mastercard adds that keys are usually installed using procedures set by the terminal vendor, for example through a terminal management menu option.

In practice, CA public keys travel with the rest of the terminal’s EMV configuration. The U.S. Payments Forum’s description of Discover’s production-validation prerequisites, listing the parameters to load across a terminal estate, puts the production CA public keys next to the AIDs, application version numbers, terminal action codes and floor limits. Visa’s acquirer guide likewise groups public key management with terminal configuration and terminal management systems (TMS).

Network certification also involves keys. For Discover, obtaining the CA public keys is a stated prerequisite for end-to-end terminal certification. BankAxept’s version 1.33 says terminals must only use BankAxept keys distributed by Bits.

Common CAPK configuration errors

• Index without RID. Index 09 under Visa’s RID and an index 09 under another network are unrelated keys. Always key your table by the pair.
• Decimal versus hex index. Indexes are bytes written in hex, so 10 is 0x10.
• Test keys left in production terminals, or live keys missing from test terminals.
• Expired or withdrawn keys still loaded. Visa asks that all Visa keys other than the active ones be removed. BankAxept’s version 1.33 allowed six months after expiry.
• The transit-only key loaded everywhere. Visa’s 1536-bit key (index 10) is for transit fare gates only and must not be loaded into other terminal types.
• Hard-coded expiry dates that are never updated after a network extends a key’s life.
• Copy-and-paste damage. Owner documents wrap moduli across lines and space out bytes. Visa prints one test key’s hash in lower case. BankAxept’s v1.33 document has a typographic closing quote in one key’s JSON. Strip whitespace, reject anything that is not hex, and verify the checksum.
• Byte order and padding. The modulus is hashed as the big-endian byte string the network publishes. Reversing it, converting through a number type that drops or adds a leading zero byte, or storing the exponent as 00000003 instead of 03 all change the hash.
• Keys from unofficial lists. Tables copied between websites, forum posts and repositories have no stated owner or edition, so you cannot tell whether a key is test or live, current or withdrawn. Use them only as a pointer to the owner’s document.

Frequently asked questions

Why isn’t there a full CAPK list here?

A full list can’t be built from open, owner-published sources. Discover releases its keys through registered channels rather than a public download, we found no open publication for several other networks, and a list copied from elsewhere can’t be traced back to its owner. Keys are also retired, and Visa reviews its expiry dates every year. We list only what the owners publish openly, with the checksum and the edition date, and point you to the official channel for the rest.

Where do I download the Visa CA public keys?

From www.visa.com/pubkeys, the address Visa’s acquirer implementation guide gives. It downloads Visa’s “Visa Smart Debit/Credit Certificate Authority Public Keys” document, which in its January 2026 edition contains the active production keys (index 09, and index 10 for transit) and the test keys (94 and 89), each with its SHA-1 hash.

Where do I get the Mastercard CA public keys?

Mastercard has published its M/Chip keys in an open PDF dated 4 December 2018 (indexes 05 and 06 under RID A000000004). The index 05 key has since passed its stated expiry date, and we found no newer open edition, so confirm the current set with your acquirer before deployment.

Where do I get the Discover, Diners Club or American Express CA public keys?

Not from a public download. According to the U.S. Payments Forum, Discover provides them after a CA Security Officer Registration Form, or by encrypted email from the acquirer’s Discover implementation manager. We found no open American Express publication, so ask your acquirer or American Express through terminal certification. The RIDs are A000000152 (Discover/Diners) and A000000025 (American Express).

What is the CA public key index (tag 8F)?

A one-byte value on the card that tells the terminal which of the network’s CA keys signed the issuer certificate. Together with the RID from the selected AID, it identifies exactly one entry in the terminal’s key table.

How is the CAPK checksum calculated?

SHA-1 over the bytes of RID, index, modulus and exponent concatenated in that order, giving 20 bytes. Visa and Mastercard both state this construction in their key documents, and every published hash we checked matches it.

I found Visa key index 92 (or another index) in an old list. Should I load it?

No. Visa’s January 2026 document lists only indexes 09 and 10 as active production keys and 94 and 89 as test keys. Visa’s 2019 and 2021 acquirer bulletins said that only the keys Visa named as current should be in devices and that all other Visa public keys must be removed, and the January 2026 document allows only active, verified production keys in production terminals. If your acquirer asks for a different index, get it from them in writing.

Are CA public keys secret?

No. They are public keys, and Visa and BankAxept publish theirs openly. What matters is integrity: a wrong, expired or test key in a terminal breaks offline authentication or creates a fraud opening. Verify the checksum and the source, not the secrecy.

Do online-only terminals need CA public keys?

Visa notes that offline data authentication does not apply to ATMs and other online-only devices. Terminals that perform offline data authentication or offline enciphered PIN need them, and Mastercard also requires them in terminals that accept contactless transactions.

Related reading on Ambimat

• EMV static data authentication (SDA) vs DDA and CDA
• List of application identifiers (AID)
• Complete list of EMV and NFC tags
• How to parse BER-TLV in JavaScript
• Step by step: how an EMV contact card payment works
• EMV application selection
• Smart card APDU commands
• Symmetric-key algorithms – the other family of ciphers used in card systems.

Sources

• Visa, Visa Smart Debit/Credit Certificate Authority Public Keys (Visa Public, January 2026 edition), Table 1 (key status and expiry), sections 2–3 (production and test key values and SHA-1 hashes): www.visa.com/pubkeys
• Visa, Visa Smart Debit / Credit Certificate Authority Annual Key Assessment, Visa Business News article AI11346, 23 September 2021: usa.visa.com
• Visa, Visa Smart Debit / Credit Certificate Authority Annual Key Assessment, Visa Business News article AI09336, 26 September 2019: usa.visa.com
• Visa, VSDC Contact & Contactless U.S. Acquirer Implementation Guide v3.0 (June 2020), section 3.4 terminal checklist (CA public keys), section 9 (Visa Public Keys document reference), scope note on public key management and TMS: usa.visa.com
• Mastercard, M/Chip Payment System Public Keys, 4 December 2018, pp. 1–2: www.mastercard.com.sg
• Bits AS, BankAxept EMV Certificate Authority Public Keys v1.33 (9 May 2023, TLP:WHITE), sections 2–5; read from the Internet Archive capture of 28 February 2024: www.bits.no (archived copy)
• U.S. Payments Forum, EMV Testing and Certification White Paper: Current Global Payment Network Requirements for the U.S. Acquiring Community v5.0 (September 2023), sections 2.3.2 and 3.4.1 (Discover CA public keys): www.uspaymentsforum.org
• U.S. Payments Forum, EMV Testing and Certification White Paper (December 2017), section 4.2.2 (terminal parameters including production CA public keys): www.uspaymentsforum.org
• D. Basin, R. Sasse, J. Toro-Pozo, The EMV Standard: Break, Fix, Verify, IEEE Symposium on Security and Privacy 2021 (arXiv:2006.08249), section III (offline data authentication and CA index lookup): arxiv.org
• EMVLab, EMV tag search: tag 8F and tag 9F22 (Certification Authority Public Key Index): emvlab.org
• NIST, SP 800-57 Part 1 Rev. 5, Recommendation for Key Management (May 2020), section 5.6.1.1, Table 2: nvlpubs.nist.gov
• NIST, SP 800-131A Rev. 2, Transitioning the Use of Cryptographic Algorithms and Key Lengths (March 2019), section 3, Table 2: nvlpubs.nist.gov
• ETSI, TS 101 220 V19.0.0, Smart Cards; ETSI numbering system for telecommunication application providers, section 4 (AID = 5-byte RID registered under ISO/IEC 7816-5, plus PIX): www.etsi.org
• RIDs for American Express, Discover, JCB, UnionPay, Interac and eftpos: as sourced row by row in Ambimat’s AID reference list (Verifone, U.S. Payments Forum, Elavon, Fiserv and AusPayNet documents)

Written by the Ambimat engineering team. Key data checked against the owners’ documents on 10 October 2026; code tested on Node.js 25.8.2.