Use managed identities instead of stored secrets

Managed identities are free. There is no charge for the identity itself, no charge for the tokens the platform issues, and no charge for assigning the identity to an app. Switching a web app or function from a stored secret to a managed identity does not move the Azure bill at all. The only adjacent cost is a small Key Vault charge where a workload genuinely needs to read its remaining application secrets through a vault, and that is a deliberate choice rather than a side effect of this control.

Frame each failing recommendation as a line on the risk register rather than a compliance checkbox. A function app holding a production database password in plain application settings carries a far higher expected loss than a throwaway demo app, yet both surface as a single red finding. Map the failures to what each app can reach with its stored secret and prioritise by blast radius, not by recommendation count.

The insurance arithmetic is one-sided. The remediation is engineering time: assign an identity, grant it least-privilege access, swap the code over and delete the secret. The downside of leaving a stored secret in place is the documented cost of a leaked credential: a key checked into a repository, a connection string in a log, a service principal secret that never expired, any of which can hand an attacker standing access until somebody notices and rotates it.

Priya is the finance partner supporting the platform team's SOC 2 push. The security report lands with managed-identity findings across a dozen apps and functions in two older subscriptions. The instinct is not to wave through a remediation budget; it is to ask what is actually behind each red finding. Managed identities are free, so the spend question is almost empty: assigning an identity and granting it access changes nothing on the Azure bill. The only adjacent cost is a small Key Vault charge for the few workloads that genuinely need to read remaining secrets through a vault, and that is a deliberate decision rather than a cost of this control.

Priya asks the team to map each failing app to what its stored secret can reach. Two are production apps holding database passwords and storage keys, one is a function with a Service Bus connection string, and the rest are demo and staging apps that authenticate with secrets but touch nothing sensitive. The list is reframed on the risk register: the production apps are high blast-radius items to switch over today at zero Azure cost, the function is a same-day swap, and the demo apps are low-value cleanup. The finance pack reads: 'Every one of these closes at no incremental spend; the work is engineering time, and the value is removing a class of credential-leak liability, not saving on the bill.'

The cost model here is asymmetric in a way that is rare for security work. Moving an app to a managed identity costs nothing in Azure spend, and leaving it on a stored secret creates an unbounded tail risk. Each failing recommendation is an app whose secret could leak, and while the probability of any single secret leaking in a given month is low, the probability across every app and every pipeline over years is not. A leaked credential is also one of the few risks that can turn into an incident with no warning at all.

The documented cost of a credential-driven breach includes mandatory notification within tight regulatory windows, forensics and legal fees that routinely run into six and seven figures, and the operational scramble of rotating every dependent secret at once. Against that, the remediation is engineering time, plus a small Key Vault charge only where a workload genuinely needs a vault for its remaining secrets. The finance role is to attach blast radius to each failing app, what its stored secret can reach, so the work is prioritised by risk, not by the order the report lists it.

Stored secrets are the category of risk that turns one careless copy-paste into a breach. A connection string in a log, a key in a screenshot, a client secret in a config file shared in chat: each is a standing credential that works from anywhere until somebody finds and rotates it. The report shows this as a couple of findings per compute type, but the underlying exposure is every app that still authenticates with a secret a human created.

The leadership question is not 'are we compliant today?' It is 'if a secret leaks tomorrow, what can someone do with it?' The defensible end state is that web apps and function apps authenticate as themselves with platform-issued, automatically rotated credentials that only work from inside the resource, so there is no long-lived secret to leak in the first place.

None of this is a cost decision. Managed identities are free. It is a governance decision about whether your applications carry secrets that a single mistake can leak, or whether the platform holds the credential and rotates it for you.

After a peer company disclosed that an attacker had used a database connection string found in an exposed log to read its customer records, the CEO asked the obvious question at the next review: could that happen to us? The honest answer at the time was that it depended on which app you meant, because most production apps still authenticated with connection strings and keys that lived in their config and pipelines.

The team's response was to stop treating credentials as something each app manages and start treating identity as a platform guarantee. They listed every web app and function with no managed identity, gave each one an identity, granted it least-privilege access on the services it actually used, swapped the code over and deleted the stored secrets. Then they set an Azure Policy that audits any new app or function created without a managed identity. The next time the CEO asked the question, the answer had changed from 'it depends' to 'a leaked secret would not get them in, because the production apps no longer hold one: the platform issues a short-lived credential that only works from inside the app.' That shift, from a credential a human stored to one the platform owns and rotates, is the one-line confidence signal this capability delivers, and it costs nothing in Azure spend to reach.

A large share of cloud breaches that made the news came back to the same root cause: a long-lived credential that should not have existed leaked, and worked. Moving applications to managed identities is the capability that removes that root cause, because there is no longer a secret to leak. An Azure Policy backstop that audits any new app without an identity keeps it from creeping back.

The cost of getting this wrong is large and well documented, while the cost of fixing it is essentially engineering time, because managed identities are free. This is the rare class of control where the risk of inaction is severe and the cost of action is small, which is exactly the trade leadership should be quickest to approve.