0
.png)
Most payment teams are tracking the C-8 shift, but few have actually planned for it.
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 whether your terminals need to support C-8. It's whether you've thought through what supporting it 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 running recertification again. The cost kept increasing with every new market and network added.
Multiple EMV kernel certifications across six networks were not just expensive but also complex. Each kernel had its own update structure, test specification version, and lab requirements.
A terminal vendor supporting all six networks in a multi-market deployment was running six parallel certification programs. The cost was not just in lab fees; it was also in engineering time, test tool licenses, and the overhead of maintaining six kernel implementations simultaneously.
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:
Coexistence is well-defined in the specification. It is considerably more complex in a production terminal.
The reality of multi-kernel POS terminals is that you are not replacing one kernel with another. You are adding a new kernel to a device that was already managing several and proving that the addition does not break any of the existing flows. The specification is clean in the lab. It gets complicated when it encounters the terminal's existing firmware limits, L3 application dependencies, and the transaction behavior that each network expects.
EMV kernel transition payment terminals face a specific challenge that is easy to underestimate from the outside. The integration work is not just about implementing C-8 correctly in isolation. It is about proving that C-8 works correctly alongside every other kernel already on the device, across every network configuration the terminal supports. That proof requires a test plan that covers the full scope of the multi-kernel EMV terminal migration, not just the new kernel in a clean environment.
You are not just building and certifying C-8. You are 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. An EMV L2 kernel upgrade of this kind affects the entire contactless stack on the device. An architectural review that happens after development has started is not an architectural review. It is a post-mortem in progress.
Every scenario in which C-8 is unavailable requires a tested, documented fallback path. It is where most of them hit unexpected issues, and the cost of finding them late is high.
EMVCo allows the C-8 kernel either as a standalone thing or as part of a full contactless acceptance. Lab slots are not easy to get. Going to labs without clarity on the approval path will fail.
The EMV L2 kernel upgrade path for C-8 also varies depending on whether a terminal vendor is starting from a clean implementation or migrating from an existing multi-kernel stack. Teams that have mapped that path before they reach the lab are the ones that use their lab time efficiently. Teams that discover the right path during a lab session are paying lab rates to learn something they could have confirmed in advance.
The first C-8 approvals have been confirmed. Network mandates have not landed yet.
That gap is the only period when teams can work through architecture, fall back to compatible kernel paths, and address integration issues on their own timeline rather than someone else's. Once mandates are in place, lab queues will back up, and the teams that waited will feel it.
Multi-kernel EMV terminal migration is not a project that can be cut short under deadlines. Fallback path testing requires a test matrix that expands with each network and terminal configuration.
Leaving that work until mandates are in place means doing it when lab slots are scarce and the margin for error has shrunk.
These multi-kernel periods are temporary. How teams navigate it will determine who comes out the other side with a clean, certified, production-ready implementation.
