The KEP's bootstrap sentence carries as much weight as its API types. The KEP says no bearer tokens are involved in issuance as long as both the kubelet and the signer authenticate to kube-apiserver using their own separately bootstrapped client certificates [7]. Count the parties in that condition: two, each of which needs its own certificate-based credential [14]. The reasoning is in the document. An mTLS credential is split so that only the certificate ever reaches the counterparty, and a bearer token anywhere in the chain collapses the scheme back to bearer-token security [6]. So the guarantee is a property of how you deploy the signer, not of the object you create. Run the signer as a pod that authenticates with a projected service account token and the token is in the issuance path [15].
The narrowness of the new type is the other thing worth a second pass. A PodCertificateRequest carries essentially one assertion: pod X is requesting a certificate from signer Y [2]. That is what makes the server-side check possible, and the KEP moves enforcement of node restriction on these requests into kube-apiserver [9]. My read is that this is the constraint driving the design rather than a convenience: the KEP is explicit that operating a third-party signer today demands intimate familiarity with the Kubernetes security model, and a signer written without it can negate the node restriction boundary [8]. A generic certificate request gives the apiserver no pod to compare against the node presenting it. A pod-scoped one does.
On the delivery side, the projected volume source instructs the kubelet to provision the private key and certificate chain on the pod's behalf [3], with the stated aim of reaching every pod in a cluster without unreasonable burden on application developers or cluster administrators [4]. The KEP's own summary notes that making certificates available to workloads has so far been left as an exercise for the reader [1]. KEP-4317 is built to be that exercise. It is also written as scaffolding for other people's code, with explicit intent that third-party projects use it to issue certificates to workloads [5], which reads less like displacing existing issuers and more like inviting them to become signers.
What the material does not settle is scope creep into the mesh. The KEP text contains an item headed "Specify a solution for pod-to-pod mTLS in core Kubernetes", noting that pod-to-pod mTLS, also known as service mesh, is a rapidly evolving area; the sentence is cut off in the excerpt supplied to us [12]. Treat the mesh question as open on this evidence.
For the security property to transfer to your cluster, two things have to be true that the API cannot check for you: your kubelet has a bootstrapped client certificate, and your signer has one too, separately [14]. The excerpt also carries the standard signoff checklist, including the requirement that all GA endpoints be hit by conformance tests and a minimum two-week window for GA e2e tests to prove flake free [13], and it does not say which release enables the mechanism or at what maturity [16]. The realistic next step here is planning a trial, not a migration.
