Until this went GA, storing a certificate on a Flex Consumption function app meant one of two indignities: base64 the .pfx into an app setting and pretend that’s fine, or wire up a managed identity and a Key Vault reference just to present one cert on one custom domain. The first is a liability. The second is a lot of scaffolding for a small job.
So the new site-scoped certificate model is welcome. Think of it as a small keyring bolted to the individual function app — up to three private keys (.pfx) for presenting identity and three public certs (.cer) for trusting the other end. The keys live with the app, not in a shared cabinet. That’s the whole design, and it’s also the whole limitation. Let’s run it against the incumbent, Key Vault references, on the things that actually matter.
Rotation: Key Vault wins, and it isn’t close
A site-scoped certificate is a snapshot. You uploaded a blob; that blob expires on the date printed on it, and nothing renews it for you. Key Vault, pointed at an integrated CA or fed by your own automation, rotates the material underneath and the app picks up the new version. If you have ever been paged at 2am because a cert lapsed on a Sunday, you already know which one you want holding your production domains. Point: Key Vault.
Cold-start reliability: site-scoped wins
Here’s the elegant bit. A Key Vault reference is a network hop and an auth handshake that has to succeed before your app is fully useful. On a SKU built around scaling from zero, that dependency has teeth — private endpoint not reachable, managed identity not yet provisioned, and the cert silently doesn’t bind. Site-scoped certs are already there, on the app, no identity or network path required. Fewer moving parts, fewer 6am mysteries. Point: site-scoped.
Sharing across apps: Key Vault wins
The keyring is bolted to one app. Fifteen function apps that all terminate *.internal.contoso.com means fifteen separate uploads and fifteen separate expiry dates to track. Key Vault is one cert, referenced by everyone, rotated once. Site-scoped storage has no concept of a shared cert — that’s not a bug, it’s the name of the model. Point: Key Vault.
Blast radius and RBAC: Key Vault wins
Uploading a .pfx to the app means the private key sits in the app’s own configuration surface. Anyone with contributor-level rights on that app can pull it. Key Vault splits the duties: Key Vault Certificates Officer manages the material, the app’s managed identity only gets get, and access logs land in your diagnostic pipeline. On a compliance audit, that separation is the difference between a checkbox and a finding. Point: Key Vault.
Shipping it before Friday: site-scoped wins
One custom domain, one cert, one small internal API? Upload the .pfx for the domain, upload the backend’s .cer to trust it, done — no identity, no vault, no policy exception. The two cert types line up neatly with the two ends of a TLS conversation: a private .pfx to terminate TLS on your custom domain inbound, a public .cer to trust a backend you call outbound. Chain them and, architecturally, you have encryption on both hops. Whether that adds up to true end-to-end TLS is something to prove in your own environment — the announcement gives you the building blocks, not a validated blueprint. On cost and quota: the only ceiling named is the 3+3 limit itself, and these uploads aren’t App Service Certificate purchases (that’s a separate paid product). Confirm billing against your own subscription before you assume it’s free. Point: site-scoped.
Where 3+3 bites
The limit is per app, hard, and unglamorous. Serve four custom domains from one function app and you’re out of private slots. Chain client certs to several partner backends and the three public slots vanish too. There is no “just add a fourth” — the answer is Key Vault, and you should reach for it before you architect yourself into the wall, not after. Availability follows the Flex SKU’s own region footprint, so confirm your region actually carries Flex Consumption before you plan around this.
For automation, treat these as state on a live app. Bicep authors the Microsoft.Web/certificates resource; deploy it with az deployment group create --what-if, or terraform plan for the HCL crowd, so you see the diff before a private key lands in production. Never pipe a .pfx straight to an app without previewing the change first.
The verdict
Key Vault takes rotation, sharing, and RBAC — the three that decide a fleet at scale. So Key Vault is still the default for anything you’ll run for years or replicate across apps. Pick the site-scoped keyring in exactly one case: a single self-contained app, one or two certs, where the vault’s network dependency at cold start is a bigger risk than an expiry date you’ve put in your calendar. That’s a real case. It’s just a smaller one than the feature announcement implies.