Old code isn’t the problem. Expired approvals are.
Kernel lifecycle is really compliance alignment: whether the Level 2 (L2) kernel on your terminals still sits inside an active EMVCo approval, and whether that baseline matches what the card schemes require for the rollout you have in mind. Many acquirers only feel the gap when a certification or deployment stalls.
In EMV, the kernel is the Level 2 payment application (the logic that defines how a transaction runs on the terminal). EMVCo assigns expiry dates to approved products; renewal is how vendors demonstrate continued fit with performance, interoperability, and security expectations.
When someone says “Kernel 100 is expiring; Kernel 101 is coming,” that is not a cosmetic version bump. The current L2 baseline is nearing the end of its approval window. New certifications, renewals, or device programs need to move to the successor kernel before that window closes.
Software aging vs. approval expiration
People mix two different problems. Technical debt from software aging means code gets harder to maintain, integrate, or port; builds slow down; teams patch around quirks. Certification debt from approval expiration is different: the EMVCo approval for that kernel version ends. The binary may still approve transactions in production, but that build is no longer recognized as approved transaction behavior for new submissions and renewals under the current rules.
For architecture and programme leads, the second problem gates deployments even when the first is invisible at the till.
Why approvals are time-bound
EMVCo does not treat kernel approval as permanent. Finite approval periods push the installed base toward reassessment against current benchmarks. Renewal work typically covers throughput and reliability under load, correct handling of card and terminal features in circulation (including product extensions), and security requirements aligned with current threat models and scheme minimums.
If you miss the transition to a supported kernel baseline before the old approval expires, you still have running software; you no longer have a clean compliance path for the next certification step on that track.
Schemes build on the EMVCo baseline
Major card networks tie operational and security mandates to an underlying EMVCo L2 position. Scheme compliance assumes that foundation. It does not replace it.
| Network | What they expect | How L2 fits |
|---|---|---|
| Visa | L3 testing before deploying terminals | Needs an active, non-expired EMVCo L2 approval for the kernel you ship. |
| Mastercard | Tap on Phone and related programmes | Documentation ties EMVCo, Mastercard, and PCI requirements together (for example MPoC/SPoC-style stacks). |
| American Express | Chip acceptance on devices | Valid EMVCo approvals for the kernel on chip-enabled terminals. |
If the L2 baseline you relied on is obsolete for new work, the scheme-specific deployment story you need often stops with it. L3 work (device, application, processor, and network together) cannot be completed or renewed on a kernel that is no longer within the approved set for that programme path.
SoftPOS, SmartPOS, and COTS builds
Transaction success in the field is a poor proxy for approval health. A SoftPOS or Android SmartPOS stack can clear cards with no visible fault while you are already blocked for anything that needs a fresh certification: new merchant cohorts, new hardware, new markets, or mandated application updates.
Commercial off-the-shelf (COTS) phones and tablets turn over quickly. An expired kernel on those stacks is not a small maintenance item; it is a constraint on which builds you can certify next and how much rework each refresh requires.
Keeping an expired kernel in production is sometimes presented as a temporary bridge. Architecturally, it is a decision to continue operating without a current approval for that behaviour on the path your roadmap needs, whatever the code’s day-to-day performance.
What certification debt looks like
“Certification debt” is the gap between where your estate sits today and what the next EMVCo or scheme submission will ask for. That gap tends to grow with time and fleet diversity. Older L2 positions sit further from current EMVCo and network requirements, so each jump covers more ground. More SKUs and configurations mean more combinations to retest when you finally move. Local mandates stack on top of global baselines; a stale kernel often means reconciling several deltas at once. On COTS and SmartPOS, new OS levels and hardware make refreshing on an obsolete L2 foundation more work than a straight recompile.
Deferring kernel migration is often treated as saving money this quarter. The usual trade is narrower options later: fewer clean certification paths, larger retest scope when you move, and frozen deployment lanes until a baseline transition is finished.
| If you defer… | You tend to get… |
|---|---|
| Kernel migration | Fewer straightforward certification options; more complex catch-up work. |
| L2 baseline refresh | Expanded recertification scope and higher cost when you finally move. |
| Scheme mandate alignment | Stuck rollout lanes until the kernel story matches what the network requires for new deployments. |
Lifecycle planning belongs in architecture
An active kernel approval window shapes how fast you can launch hardware, how painful certification cycles are, and how much of your engineering capacity goes to maintaining divergent legacy variants instead of one deliberate upgrade line.
Kernel expiry limits what you can certify next quarter and how quickly you can respond to mandate or product changes. Treating migration as “just another release” misses that it resets the permitted baseline for the estate.
Closing thought
The constraint on growth is often not whether the code runs, but whether the approval you need for the next device, market, or programme is still available on the kernel version you deploy.
If you own terminal or SoftPOS roadmaps, map kernel approval dates to programme milestones. The next certification may depend on that window as much as on any single defect fix.
References
- EMVCo — EMV Level 2 kernel approval and expiry (product listings and programme documentation)
- Visa — Terminal compliance and L3 certification requirements
- Mastercard — Tap on Phone compliance framework
- PCI Security Standards Council — SPoC / MPoC (software PIN on COTS / mobile PIN on COTS)