Explain how Firefly issues short-lived certificates to workloads in a service mesh?

In a service mesh, sidecar proxies need mutual TLS (mTLS) certificates issued and rotated fast enough to keep up with pods scaling up and down constantly — a round-trip to a central platform for every single request would introduce latency and become a bottleneck at any real scale, which is exactly the gap Firefly is built to close.

Firefly is provisioned with a delegated signing authority from the central platform (either a subordinate CA relationship or a policy-scoped issuance right) and a cached copy of the relevant issuance policy, so it can validate and sign requests locally without a live round-trip to TPP or Certificate Manager SaaS for every certificate. When a pod or sidecar starts, it requests an identity through the mesh's standard certificate flow (commonly SPIFFE/SPIRE-compatible in modern meshes), Firefly signs a certificate valid for a short window — often minutes to a few hours — and the workload rotates it automatically well before it expires.

Firefly still reports what it issued back to the central control plane asynchronously, so the organization retains a complete audit trail and inventory even though the actual signing happened locally and fast. The trade-off is deliberate: near-instant, high-volume issuance in exchange for the signing decision being made by a locally cached policy rather than a live check against the absolute latest central policy on every single request.