CNCF Sandbox vs Incubating vs Graduated: What the Maturity Levels Actually Mean for Your Toolchain

Every week brings another “we built a Kubernetes-native X” announcement. Some of those projects will be running your production clusters in three years; most will be archived repositories with a “no longer maintained” banner. The CNCF maturity level — Sandbox, Incubating, Graduated — is the most widely used shortcut for telling the two apart, and it is also one of the most misread.

The labels are not marketing tiers. Each one corresponds to a documented set of criteria that the Technical Oversight Committee (TOC) checks in a due-diligence process, and each one is a floor, not a guarantee. This article goes through what the TOC actually requires at each level as of 2026, what the levels do not tell you, the 2025–2026 events that show the ladder moving in both directions, and a practical framework for turning a badge into an adoption decision.

The Short Answer

Sandbox means the TOC judged the idea worth hosting; it says almost nothing about stability, security posture or whether anyone will maintain it next year. Incubating means the project has documented governance, at least three independent production adopters interviewed by the TOC, a security self-assessment and a passing OpenSSF badge — it is the level at which the CNCF starts actively evaluating adoption. Graduated adds maintainers from at least two organisations, an org-balance mechanism in governance and a completed third-party security audit — it is the level at which the foundation is willing to say the project has demonstrated production readiness at scale.

If you need one rule: Sandbox is where you experiment, Incubating is where you can build with a contingency plan, Graduated is where you standardise.

What the TOC Actually Requires

The criteria live in the TOC repository, and since 2024 the detailed lists sit inside the incubation and graduation application templates rather than a single criteria document. These are the items that matter for an adopter, quoted from the current templates.

Three things in that table are worth reading twice.

First, Sandbox has almost no technical bar. The published reasons applications get closed without review are administrative: not Apache 2.0, no MAINTAINERS file with employer affiliations, being a reference architecture rather than a reusable project, or being a subproject without the parent’s consent to split. Organisation diversity is explicitly “not a requirement, but considered during review”. The TOC reviews applications in a non-public session roughly every two months, working through seven to ten at a time in first-in-first-out order. There is no security review, no adopter interview and no architecture review at this stage — TAG-led General Technical Reviews are optional and “do not result in a label or a required action for applicants”.

Second, the OpenSSF badge requirement is “passing” at both Incubating and Graduated, not silver or gold. If a project advertises a gold badge, that is the project going beyond the bar, not the CNCF demanding it.

Third, the third-party security audit only arrives at Graduation. An Incubating project has assessed itself. That is not nothing — the self-assessment template is thorough and TAG Security reviews it — but it is not an external audit of the code you are about to run with cluster-admin privileges.

What the Levels Do Not Mean

Sandbox is not an endorsement

The lifecycle document describes Sandbox projects as ones where “failure is a possibility” and that “are expected to undergo significant changes, including breaking changes to their functionality”. It adds that they “might still be used in production by a few organizations on a case to case basis” — which is the TOC’s careful way of saying that it is possible, and that the risk is entirely yours.

The practical consequence: a Sandbox badge on a README tells you the licence is clean and the maintainers are identifiable. It does not tell you the API will exist in the same shape next quarter.

Incubating is not “almost graduated”

Projects can sit at Incubating for a very long time. Thanos entered the CNCF in July 2019 and moved to Incubating on 19 August 2020; six years later it is still Incubating and still perfectly healthy. Contrast KEDA — Sandbox March 2020, Incubating August 2021, Graduated August 2023 — or Kyverno, which took from November 2020 to March 2026 to make the full journey. Time at a level is a function of governance work and audit scheduling as much as technical maturity, so “still Incubating” is not a warning sign on its own.

Graduated is not “right for you”

Graduation says the project has cleared the foundation’s bar for governance, security and adoption breadth. It does not say the project fits your scale, your team or your problem. Cilium, Argo, Kyverno and KEDA are all Graduated; you should still not run all four if you have one cluster and three engineers. The badge removes the “will this be abandoned” question from your evaluation; it does not answer any of the others.

And some things you assume are CNCF projects are not

Karpenter is a good example of the trap. It is hosted under kubernetes-sigs as a subproject of SIG Autoscaling, which means it is governed by the Kubernetes project, not by the CNCF TOC as a standalone project with its own maturity level. It has no Sandbox, Incubating or Graduated badge to check, and any blog post that assigns it one is guessing. When you evaluate it, you are evaluating a Kubernetes SIG subproject, which is a different (and generally stricter) governance regime. The Cluster Autoscaler vs Karpenter comparison covers the technical side.

The Ladder Moves in Both Directions

2026 has been an unusually busy year for graduations: Dragonfly (January), Kyverno (16 March, announced 24 March), OpenTelemetry (May), Cloud Native Buildpacks (August), Kubeflow (August) and Karmada (8 September). Karmada is the clean illustration of the full path — Sandbox September 2021, Incubating December 2023, Graduated September 2026, with the announcement explicitly noting that the project “completed a third-party security audit, established a formal steering committee to ensure transparent governance” to get there.

The archive side is less publicised and more instructive. In 2025 the TOC archived two batches of Sandbox projects: Nocalhost, SuperEdge and KubeDL in March, then Merbridge, Sealer, Teller, DevStream and OpenELB in May. All eight were Sandbox projects, several of them with a single corporate sponsor, and each went through the documented process — a project-health issue, a two-week final comment period, then a two-week TOC vote requiring a 2/3 majority.

Archiving is also not necessarily the end. OpenEBS was archived after a TOC vote in early 2024 and re-admitted to Sandbox in October 2024 with a rebuilt maintainer team, because “any project can be reactivated into CNCF by following the normal Project Lifecycle & Process”. What an archived project loses is real, though: it “may not be used any more” to advertise its former status, and it disappears from the landscape, DevStats and CLOMonitor.

For an adopter the lesson is simple. Sandbox is the level where the foundation has the least information about the project and the least reason to fight for it. If the project has one employer behind its maintainers, the foundation’s exit process is the one you should be planning for.

Signals You Can Read Yourself

The TOC’s own inputs for health and archiving decisions are public, so you can run the same checks before the TOC does. The archiving policy lists the signals it weighs: the project health dashboard, whether the project still meets current acceptance criteria, community requests, “security responsiveness”, meeting activity, mailing-list engagement and adoption statistics.

Project Health issues. Concerns are filed in cncf/toc with the [HEALTH] prefix. The template describes its purpose as ascertaining “the current activity and health of the project so the TOC may identify the appropriate support and guidance for the project to return to an optimal state of health or determination of archival”. Search the TOC issues for the project name before you adopt; a health issue is a leading indicator by months.

Level-change applications. Incubation and graduation applications are also public issues in cncf/toc. Reading one tells you exactly what the TOC asked, which adopters were interviewed and what was flagged in the security review. This is better due diligence than most vendor RFP responses.

DevStats and LFX Insights. DevStats (devstats.cncf.io) gives contributor and company counts over time; LFX Insights adds organisational affiliation. The metric to watch is not stars but the number of companies contributing in the last year and whether that number is rising.

CLOMonitor. clomonitor.io scores every CNCF project against the same checklist the TOC uses — licence, governance files, security policy, OpenSSF badge, DCO, release signing. A low score at Incubating is worth a question; a low score at Sandbox is normal.

TAG structure. In 2025 the TOC rebooted its Technical Advisory Groups into five: Developer Experience, Infrastructure, Operational Resilience, Security and Compliance, and Workloads Foundation. TAGs no longer perform formal reviews as part of the Sandbox process; that work moved to the TOC’s Project Reviews subproject. If you are reading an old TAG review of a project, check the date — the group that wrote it may no longer exist.

A Practical Evaluation Framework

The maturity level is one input. Here is the checklist that turns it into a decision, with the commands and URLs to answer each question in under an hour.

1. Where does it sit in your stack?

A CNI plugin, a policy engine or a service mesh is foundational: replacing it is a migration project. A dashboard, a CLI plugin or a diagram generator is peripheral: replacing it is an afternoon. The same badge means different things at different layers. Headlamp is a Sandbox project (accepted 17 May 2023) and a perfectly reasonable choice as a cluster UI, because a UI is peripheral — see Headlamp vs FreeLens vs Lens. A Sandbox CNI is a different conversation.

2. Who actually maintains it?

# Committers in the last year, with email domains
git shortlog -sne --since="1 year ago" | head -20

# How concentrated is it? Count distinct email domains among the top 10
git shortlog -sne --since="1 year ago" | head -10 \
  | grep -oE '@[a-z0-9.-]+' | sort | uniq -c | sort -rn

If one domain accounts for more than about 80% of commits, the project’s roadmap is that company’s roadmap, regardless of what the governance document says. This is exactly the “org-balance” question the TOC asks at Graduation; ask it earlier.

3. What does the security posture look like?

# OpenSSF Scorecard: branch protection, signed releases, dependency update tooling, fuzzing
scorecard --repo=github.com/<org>/<project>

Then check for SECURITY.md, whether reported CVEs have advisories with fix versions, and whether release artefacts are signed. For an Incubating project, read the Security Self-Assessment linked from its application issue; for a Graduated one, find the third-party audit report — it is usually published in the project repository or by the auditor.

4. What is the release and compatibility story?

Look at the last twelve months of releases: cadence, whether minor releases carry breaking changes, and whether there is a written deprecation policy. “Fewer breaking changes and more stable, versioned APIs” is literally the TOC’s description of the Incubating transition, so a Sandbox project with a stable API is ahead of its level and an Incubating project without one is behind it.

5. Who else depends on it?

A project that is a dependency of other CNCF projects — or that a managed Kubernetes service ships by default — has a survival guarantee no badge can provide. Cilium is Graduated, but the more important fact for its longevity is that several cloud providers build their networking on it.

6. What is the exit?

Write down, before adopting, what it would take to replace the project. For a policy engine: how many policies, how portable are they (Kyverno’s YAML versus Rego, for example — see enforcing standard and custom policies with Kyverno). For a UI: nothing. For a storage layer: everything. The lower the level, the more this answer matters.

Mapping Level to Adoption Strategy

Start here:
│
├── Is the component foundational (network, storage, policy, identity, mesh)?
│   ├── YES → Graduated by default.
│   │         Incubating only with a documented exit plan and ≥2 maintainer orgs.
│   │         Sandbox: no.
│   └── NO ↓
│
├── Is it core to delivery (CI/CD, GitOps, autoscaling, observability pipeline)?
│   ├── YES → Incubating or Graduated.
│   │         Sandbox only if you are willing to fork or contribute fixes.
│   └── NO ↓
│
├── Is it peripheral (UI, CLI plugin, docs/diagram tooling, developer convenience)?
│   ├── YES → Any level; evaluate on fit and maintainer count, not badge.
│   └── NO ↓
│
└── Not a CNCF project at all (Kubernetes SIG subproject, vendor OSS, no foundation)?
    → Run the same six checks; the absence of a badge is information, not a verdict.

A few corollaries that follow from the criteria rather than from opinion:

• Sandbox projects deserve a re-evaluation date. Put it in the calendar at twelve months. If the project has not applied for Incubation, or has a [HEALTH] issue open, that is when you decide whether to contribute or leave.
• Incubating is the sweet spot for most platform teams. The governance and security documentation exists, adopters have been interviewed, and the project is still moving fast enough to fix the thing you need. Most of what you will evaluate this year sits here.
• Graduated projects earn platform-wide mandates. They are the ones where investment in training, internal documentation and deep expertise has a long-term return, because the foundation has structurally reduced the abandonment risk.
• When a project moves level, re-run the checklist, not the decision. Graduation does not change your architecture. Archiving does — it starts the clock on your exit plan, and the two-week comment period on the archive issue is where you find out whether anyone intends to fork.

Frequently Asked Questions

Conclusion

The CNCF maturity ladder is the best free due diligence in the industry, but only if you read it as what it is: a record of which documented criteria a project has satisfied, checked by a committee that publishes its reasoning. Sandbox tells you the licence is clean. Incubating tells you adopters have been interviewed and governance exists. Graduated tells you an outside party has audited the code and no single company can walk away with it.

None of the three tells you whether the project fits your stack, and none of them replaces the six checks above. Run them, write down the exit, and re-run them when the level changes — in either direction.