Most 3DS outages caused by cryptography are not attacks. They are an expired certificate, a key rotated on one side and not the other, or an app released with old key material. The effect is abrupt: authentication for an entire card scheme, or for every user on an older app version, stops working at once.
EMV 3D Secure (EMV 3DS) uses certificates and keys at several points, owned by different parties. Managing them well starts with knowing where they are.
Where certificates and keys are used
|
Touchpoint |
What it protects |
Who manages it |
What failure looks like |
|
Connection between the 3DS Server and the Directory Server (DS) |
Mutually authenticated, encrypted messages |
3DS Server operator, with certificates issued under the card scheme’s DS programme |
Every request to that scheme fails |
|
Connection between the DS and the Access Control Server (ACS) |
The same, on the issuer side |
ACS operator, with certificates issued under the scheme programme |
The scheme cannot reach the ACS; authentication falls to stand-in or fails |
|
Device information from a 3DS SDK |
Device data encrypted with the DS public key so only the DS can read it |
SDK provider and the app that embeds the SDK |
Device data cannot be decrypted; app-based authentication degrades |
|
ACS signed content in app-based challenges |
Proves to the SDK that the challenge comes from a genuine ACS |
ACS operator signs; SDK validates against the DS root certificate it holds |
The SDK rejects the challenge |
|
Session keys between SDK and ACS |
Encrypts challenge messages |
Generated fresh for each transaction |
Rarely a lifecycle issue; failures point to algorithm or implementation mismatch |
EMVCo’s SDK device information specification describes the SDK encrypting device data with the DS public key, with the DS decrypting it and passing it to the ACS. The SDK also generates an ephemeral key pair for each transaction, and the ACS signed content it validates includes the ACS URL and the ephemeral keys used to set up the challenge session.
Why SDK key changes depend on app releases
On the server side, a new certificate can be installed in a maintenance window. In app-based EMV 3DS, the DS public keys and root certificates used by the SDK live inside the app, either built into the SDK or supplied in its configuration. When a scheme rotates those keys, every installed copy of the app needs the new material before the old keys stop working.
App release cycles, store review and slow user adoption mean that change has to start well before the scheme’s cut-over date. A merchant that ships the new keys a week before the deadline will still have customers on old versions afterwards.
Practices that prevent outages
- Keep an inventory of every certificate and key, by scheme and environment, with owner and expiry date.
- Alert well ahead of expiry, with escalation if no one acts.
- Watch for scheme notices about DS certificate and root changes, and turn each into a dated plan.
- Support overlapping old and new certificates during a rotation so either side can move first.
- For apps, ship new SDK key material early, monitor adoption, and decide in advance how to handle users who stay on old versions.
- Rehearse rotations in a test environment and include them in regression scope (scoping 3DS regression testing).
- Protect private keys in hardware security modules where your security policy and PCI 3DS obligations require it.
Certificate expiry is also one of the checks worth running before any period of high volume, as covered in preparing 3D Secure authentication for peak trading.
Frequently asked questions
Who issues the certificates used in EMV 3DS?
Certificates for connections to a Directory Server are issued under that card scheme’s 3DS programme. Each scheme runs its own process, so a 3DS Server or ACS connected to several schemes holds several sets.
What happens if a 3DS Server certificate expires?
The connection to that scheme’s Directory Server fails, so authentication requests for that scheme fail until a valid certificate is installed. Merchants see errors rather than authentication results.
Why does a Directory Server key change need an app update?
The 3DS SDK inside the app holds the DS public keys and root certificates it uses. Users only receive new key material when they install an updated app.
Are certificates and keys covered by PCI 3DS?
Yes. The PCI 3DS Core Security Standard includes requirements on cryptography and key management for 3DS environments, as covered in what a PCI 3DS assessment covers.
How often do 3DS certificates need rotating?
It depends on the validity periods each scheme sets and on your own security policy. Track actual expiry dates rather than relying on a fixed cycle.
Operating 3DS reliably
GPayments provides ActiveServer, ActiveAccess, and ActiveSDK for the acquiring side, issuing side and mobile apps. To discuss operating any of them reliably, speak with a GPayments 3DS specialist.