Kyverno reached CNCF graduated status on March 24, 2026, announced on opening day of KubeCon EU in Amsterdam. That puts it alongside Kubernetes, Prometheus, Envoy, and Helm in the CNCF's highest maturity tier. Around 35 projects hold this status. For teams evaluating policy-as-code tooling for Kubernetes clusters, the graduation shifts the conversation from "is this project mature enough?" to "how does it fit my stack?"
TL;DR
- Kyverno graduated at KubeCon EU Amsterdam (March 24, 2026), joining ~35 projects at CNCF's highest maturity tier.
- Graduation requires an independent security audit, committers from multiple organizations, and demonstrated production adoption at scale.
- LinkedIn runs Kyverno at 20,000+ admission requests per minute across 230+ clusters. Bloomberg, Deutsche Telekom, and Coinbase are confirmed adopters.
- Version 1.17 promotes CEL-based policy types to GA and deprecates the legacy
ClusterPolicyAPI. Removal is targeted for October 2026.
What graduation actually signals
CNCF graduation is not a feature release. It's a maturity gate. The criteria require committers from multiple organizations (not dominated by a single company), a published independent security audit with all critical findings resolved, an OpenSSF Best Practices Badge, explicit governance documentation, and demonstrated production adoption.
Kyverno's maintainers span six organizations including Nirmata, Chainguard, and Cloudflare. The contributor base grew to 3,624 people across 1,063 organizations. The project entered the CNCF sandbox in November 2020, moved to incubating in July 2022, and graduated after nearly four years of incubation.
For teams making adoption decisions, this is the practical takeaway: the project has cleared the bar for long-term maintenance commitment and organizational independence. If one company loses interest, Kyverno doesn't disappear.
Adoption at scale
The numbers back it up. LinkedIn processes 20,000+ admission requests per minute through Kyverno across 230+ clusters with over 500,000 nodes. The ADOPTERS.md file lists 50+ organizations: Bloomberg, Coinbase, Deutsche Telekom, Spotify, Vodafone, the US Department of Defense Platform One, and Red Hat among them.
Release velocity tells a similar story. Version 1.17 shipped in February 2026 with 850+ changes from 70+ contributors. That release is architecturally significant. It promoted CEL-based policy types (ValidatingPolicy, MutatingPolicy, GeneratingPolicy, ImageValidatingPolicy) to v1 GA and deprecated the legacy ClusterPolicy API, with removal targeted for v1.20 in October 2026.
The deprecation matters. If you're running Kyverno in production with the old API, start planning the migration now.
Where Kyverno fits in 2026
Three policy-as-code approaches coexist in Kubernetes today.
Kyverno covers the full lifecycle: validate, mutate, generate, verify images, and test policies in CI pipelines. Policies are Kubernetes YAML. Since v1.17, CEL is the primary expression language.
OPA Gatekeeper uses Rego and extends beyond Kubernetes (Terraform, API authorization), which makes it the natural choice for cross-platform policy. Both projects are now CNCF graduated. Gatekeeper v3.22.0 shipped in March 2026, so active development continues on both sides.
Kubernetes-native ValidatingAdmissionPolicy went GA in Kubernetes 1.30. It runs in-process in the API server, zero webhook overhead. The trade-off: validation only. No mutation, no generation, no image verification, no scanning of existing resources. The CNCF's own analysis calls Kyverno and native policies complementary rather than competitive.
What's ahead
The graduation press release signals a direction: upcoming releases will extend policy enforcement to AI workloads and Model Context Protocol gateways. That's roadmap, not shipped code. But the framing tracks with what Kubermatic noted at KubeCon: policy engines aren't optional in a CRA world, with the EU Cyber Resilience Act's mandatory vulnerability reporting deadline arriving in September 2026.
I wrote about Kyverno's generate rules for namespace bootstrapping last year using the ClusterPolicy API. Those patterns still apply, but the policy definitions will need updating to CEL-based types before v1.20. If you're using Kyverno for multi-tenant governance, the same migration applies.
Key takeaways
- CNCF graduation signals maturity, governance independence, and long-term stability. Kyverno now carries the same commitment level as Kubernetes and Prometheus.
- The v1.17 shift to CEL-based policy types is the biggest architectural change in the project's history. Plan the migration from
ClusterPolicybefore October 2026. - For teams choosing policy-as-code tooling: Kyverno fits when you need mutation, generation, image verification, or CI pipeline testing in a Kubernetes-native package. OPA Gatekeeper fits cross-platform needs. Native
ValidatingAdmissionPolicyfits simple, high-throughput validation. - The AI workload and MCP gateway direction is roadmap only. Wait for concrete implementations before building plans around it.