A managed identity removes passwords from your code, which is a genuine improvement, and it changes what an application flaw is worth. Anything that can run code inside the function can ask the platform for a token as that identity. The question stops being whether a secret leaked and becomes what the identity is allowed to do, which is a question about role assignments rather than code.
How the identity becomes the target
Inside an Azure Function, a token is available from a local endpoint using an environment variable as a header. That is the intended design and it is also the payoff for an attacker. A code injection flaw, an exposed development endpoint or a deserialisation bug turns into a token request, and from there the attacker acts as your application against whatever it can reach. NIST’s zero trust architecture guidance in SP 800-207 makes identity the control point rather than the network, and this is what that looks like in practice: the network position stops mattering and the role assignment decides everything.
The permissions we find attached
Function identities collect permissions the way service accounts always have. Contributor at subscription scope appears regularly, usually because a deployment failed with narrower rights and somebody widened them to get a release out. Storage Blob Data Contributor across an entire account is common where the function needed one container. Key Vault access policies granting list and get on all secrets turn a single function into a way of reading every credential the business stores. None of these are exploited on their own. They set the ceiling for what any application flaw becomes.
“Export the role assignments for every function app and web app in your subscription and read the list with the developers. In my experience about a third of the entries surprise somebody, and at least one will be an identity that can read the whole storage account when the code touches a single container. It takes an afternoon and it removes your worst day.”
William Fieldhouse, Director, Aardwolf Security Ltd
The management endpoints that come with the service
Check the deployment surface as well as the application. Function apps ship with a management site for deployment and diagnostics that provides file access and a console, and where basic authentication for it remains enabled with credentials in a pipeline variable, that is a direct route to running code. Function keys passed in query strings end up in logs and browser history. Application settings often hold connection strings that could be Key Vault references instead. Turn off the deployment credentials you do not use, restrict inbound access to the management site, and put the function behind a private endpoint if only internal systems call it.
Scoping a review that covers both halves
Test the code path and the identity together, because separately each looks acceptable. Azure security testing covers the role assignments, the network restrictions and what a token from the function can reach across the subscription. An API security review covers the endpoints the function exposes, including authentication, input handling and whether the keys are treated as secrets. Findings that matter usually join the two: an input validation weakness that on its own would be low risk becomes serious once you know the identity behind it holds broad rights.
Frequently asked questions about managed identities
These questions come up whenever a team moves secrets out of configuration files.
Are managed identities safer than storing a secret?
Yes, on balance. There is no credential to leak, rotate or find in a repository. The trade is that anything running in the resource inherits the identity, so scope becomes the control that matters.
System-assigned or user-assigned?
System-assigned suits a single resource with its own permissions, since the identity dies with the resource. User-assigned suits a group of resources sharing a role, at the cost of a wider blast radius if one of them is compromised.
