0
.png)
This blog is about a shift that's already in motion, the one most payment teams are tracking, but few have actually planned for.
The C-8 kernel has arrived.
The approval testing went live in October 2024. The first certified terminal on an Android-based platform has already been confirmed. The transition window is open.
The question is no longer if your terminals need to support C-8. It's whether you've thought through what supporting looks like, because that's where the next few years actually live.
For years, every major network shipped its own contactless kernel:
Each required its own development, testing, and certification cycle. Terminal vendors were managing six separate kernels on a single device, and every network update meant a recertification run. The cost kept climbing with every new market and network added.
EMVCo's answer was C-8, a unified, royalty-free contactless kernel specification that allows all stakeholders to run a single implementation across international and domestic networks rather than maintaining separate implementations.
Fewer kernels to build. Fewer cycles to certify. Easier deployment at scale.
The benefits are real. But the transition itself is not clean.
Here's what the next few years actually look like on the ground.
Terminals in the field will need to continue supporting Visa, Mastercard, Discover, and others, while also supporting C-8 where applicable. Both. Simultaneously. On the same device.
That means:
Co-existence is well-defined in the specification. It is considerably more complex in a production terminal.
The specification is clean in the lab. It gets complicated when it meets the terminal's existing firmware limits, L3 application dependencies, and the transaction behavior each network expects. You're not just building and certifying C-8; you're certifying C-8 on every kernel your terminal already supports, and proving that none of them break during the process.
The integration work across different operating systems, terminal types, and network configurations is significant. And the cost of discovering an architectural issue in the middle of the transition is high, not just in remediation, but in lab time lost.
The teams navigating this transition well are not moving the fastest. They're the ones who started the preparation earliest.
In practice, that means a few specific things:
Understand how C-8 sits alongside your existing kernels in your specific terminal environment, not in a reference implementation, but in your actual stack.
Every scenario in which C-8 isn't available requires a tested, documented recovery path. This is where most teams hit unexpected issues, and where the cost of finding them late is highest.
EMVCo permits C-8 kernel approval either as a standalone approval or as part of a full contactless acceptance device validation. Identifying the right path for your terminal type early avoids unnecessary lab cycles. Lab slots are not easy to come by, and so, showing up without clarity on the approval path is an avoidable loss.
The first C-8 approvals have been confirmed. Network mandates haven't landed yet.
That gap is the only period when teams can work through architecture, fallback to compatible kernel paths, and integration issues on their own timeline rather than someone else's. Once mandates are in place, lab queues will back up, and the teams who waited will feel it.
This multi-kernel period is temporary. How teams navigate it will determine who comes out the other side with a clean, certified, production-ready implementation, and who is still debugging fallback to compatible kernel failures when the pressure is highest.
