No EMVCo approval, no payment product — it is that simple for chips, cards and increasingly for software-based mobile payment solutions. The craft is making one hardware evaluation serve EMVCo, Common Criteria and your customers' schemes at once.
At a glance
Owner
Jointly owned by the international payment networks
Type
Security evaluation by EMVCo-recognised laboratories
Hardware track
Attack-potential-based evaluation of payment chips and secure platforms
Software track
Software-based mobile payment: wallets and SoftPOS-class solutions
Validity
Renewals track the evolving attack state of the art
Neighbours
PCI PTS/P2PE for acceptance devices; card schemes’ own approvals ride on EMVCo results
What it is
EMVCo security evaluation certifies that payment products resist attackers rated in the smartcard tradition: recognised labs attack the target — chip, platform or software solution — and score feasibility against attack-potential tables that EMVCo recalibrates as techniques evolve. Approvals are time-limited by design; a product that passed three years ago must still resist today’s published state of the art to keep its approval alive. That perpetual-motion quality is the scheme’s defining discipline — and the reason payment silicon teams never really finish certifying.
The hardware track (payment ICs and platforms) shares labs, methodology DNA and attack ratings with Common Criteria’s smartcard world — most payment chips carry both an EMVCo approval and a CC/EUCC certificate, built from substantially overlapping evidence. The software track, SBMP, extends the logic to software-based mobile payments where no secure element is guaranteed: white-box cryptography, runtime protections and back-end monitoring evaluated as a system, with shorter renewal cycles reflecting the softer target.
Around EMVCo sits the wider payment approval economy: PCI SSC programmes (PTS for terminals, P2PE, and related) govern the acceptance side, and the card schemes layer their own functional and security approvals on top of EMVCo results. For a product roadmap, EMVCo is rarely the only gate — but it is almost always the first one the others reference.
When it's the right tool
Payment ICs need EMVCo approval and usually CC/EUCC too. One evidence base, two submissions — or two full projects, if you plan it badly.
Software payment solutions without dedicated hardware live on SBMP evaluations plus scheme approvals — with renewal cycles your release cadence must absorb.
Attack ratings move; approvals expire. Products designed with security margin renew cheaply; products that scraped through renew expensively or die early.
EMVCo, PCI and scheme approvals answer different questions on different clocks. Map all the gates before committing the roadmap to any one of them.
Where it matters
EMVCo approvals built on the same evidence as EUCC certificates — the composition strategy that halves the cost of payment chips’ assurance.
EUDI wallets carrying payment credentials pull EMVCo-evaluated components into eIDAS-certified architectures — two trust chains, one device.
Wearables and connected devices with payment functions stack EMVCo approval onto RED and CRA conformity — shared platform evidence keeps it sane.
Time-limited approvals tracking live attack ratings — the scheme-design pattern others copy when they say “continuous assurance”.
Expert notes
Payment chips face both worlds: EMVCo approval for the payment networks, CC/EUCC certification for governments, wallets and composition customers. The labs overlap, the attack ratings rhyme, and perhaps 70% of the evidence can be common — if the documentation architecture is designed for dual consumption from the start. Run them as separate projects and you pay twice and risk divergent security claims that a sharp customer will notice.
Our position: one security architecture document, one attack analysis, two submission wrappers. We structure the evidence tree so EMVCo and EUCC each read what they need from the same trunk.
Software-based payment approvals are won on protection engineering but kept on operations: monitoring obligations, attack-response commitments and renewal evaluations on cycles far shorter than hardware’s. Teams budget the first evaluation and forget the treadmill — then discover their release process and their approval process fight each other quarterly. The viable SBMP products are the ones whose CI/CD, monitoring and evaluation evidence share one pipeline.
Our position: before entering SBMP, model three years of renewals against your release cadence. If the model doesn’t close, fix the architecture (or the cadence) first — the scheme will not bend.
EMVCo–CC evidence bridges, SBMP feasibility, renewal strategy, lab selection — thirty minutes to a plan.
We’ll send you access by email.
