September 18, 2025
Posted by Refael Angel
In a recent LinkedIn article, Felix Gaehtgens highlights the credential bootstrap problem and makes a compelling case for Managed Service Identities (MSI). There’s no question that MSI can be a valuable tool, especially for cloud-native workloads within a single ecosystem, where they help reduce reliance on static credentials and simplify authentication.
At the same time, enterprise IT rarely fits such neat boundaries. Large organizations operate across multiple clouds, legacy systems, and custom applications. Many organizations find that relying too heavily on MSI leads to recurring issues. These limitations suggest that MSI is best used alongside other approaches, rather than being treated as the complete answer to credential security.
1. Limited Compatibility with Diverse Systems
MSI primarily functions within ecosystems that support the platform’s identity system, such as Azure resources or AWS IAM roles. This means it only addresses a small fraction of databases and organizational systems in heterogeneous environments. Large organizations often rely on a mix of legacy on-premises systems, multi-vendor cloud setups, and custom applications that don’t integrate seamlessly with MSI. Attempting to force-fit MSI into such a broad landscape leaves significant gaps, forcing teams to maintain parallel credential systems and undermining any purported simplification.
2. Fragmented Access Management Creates More Chaos
Rather than centralizing visibility into who has access to what, MSI scatters permission definitions across various DBs, services, and systems. In a traditional setup, you might have a single vault or directory for oversight, but with MSI, each workload’s identity and roles are defined per resource or platform. This dispersion makes it exponentially harder to audit permissions comprehensively, increasing the risk of over-privileged accounts going unnoticed. In short, what starts as a “mess-free” approach evolves into a sprawling web of configurations, that makes holistic governance and security oversight far more difficult.
3. Complications with Human User Access
MSI is optimized for machine-to-machine interactions, but human users, such as developers, admins, or analysts, often require access to the same DBs or systems. Managing these separately necessitates duplicate permission structures: one for managed identities and another for user accounts. This bifurcation not only complicates administration but also raises the odds of inconsistencies, like granting humans broader access than intended to compensate for MSI limitations. The result? Even greater management challenges, with a high potential for errors that could lead to unauthorized access.
4. Decentralized Audit Logs Hinder Oversight
Effective security relies on centralized logging to track who accessed what and when. With MSI, audit trails are often siloed within individual cloud platforms or resources, lacking a unified view. For example, while Azure logs authentication events, aggregating them across a multi-system environment requires custom tooling, which isn’t inherent to MSI. This fragmentation makes compliance audits cumbersome and delays incident response, as piecing together scattered records can obscure patterns of misuse.
5. Vendor Lock-In and Cloud Dependency
MSI typically demands a cloud environment, often a specific one like Azure or AWS, to operate effectively. This locks organizations into a particular vendor, limiting flexibility for hybrid or multi-cloud strategies. If your infrastructure includes on-premises servers or non-compatible clouds, MSI becomes irrelevant, forcing a costly migration or hybrid patchwork. Moreover, known issues, such as managed identities not being recreated automatically during subscription transfers between directories, highlight operational brittleness in dynamic environments.
6. Challenges in Implementing Advanced Access Controls
MSI struggles with granular, context-aware permissions. Features like time-based access, IP range filtering, or conditional policies based on device health are not straightforward to implement natively. While some platforms allow role-based access control (RBAC), extending it to advanced parameters often requires additional layers, like Azure Conditional Access, which adds complexity and defeats the “simple” promise of MSI.
7. Risk of Privilege Escalation and Abuse
If a workload using an MSI is compromised, attackers inherit its permissions, potentially leading to lateral movement across resources. Azure Managed Identities, for instance, can enable privilege escalation via managed identity tokens or overly permissive policies. This is exacerbated by the ease of over-provisioning identities, turning a security feature into a vulnerability vector.
8. Lifecycle and Flexibility Constraints
System-assigned MSIs are tightly bound to a resource’s lifecycle and are deleted when the resource is, offering no persistence for scenarios that require enduring identities. User-assigned variants provide more flexibility but still aren’t shareable across unrelated resources, limiting scalability in dynamic setups.
9. Performance and Quota Limitations
MSI endpoints face rate limits on token requests, which can throttle high-throughput applications and result in errors like HTTP 429. In serverless or high-scale environments, this introduces bottlenecks, forcing workarounds that reintroduce complexity.
10. Dependency on Platform Reliability
MSI relies on the identity provider’s uptime; outages in services like Azure AD can block access entirely, creating single points of failure that traditional credentials might avoid through redundancy.
Evolving Towards Dynamic and Secretless Security Models
In conclusion, while MSI addresses some pain points in credential bootstrapping for cloud-native workloads, it falls short as a holistic solution for credential management. To truly overcome these limitations, organizations need a more comprehensive approach that enables a structured transition through the generations of secrets management, as illustrated below.
Secret management platforms like Akeyless serve as key enablers in this evolution. They guide teams from first-generation static secrets, where credentials are hardcoded or stored in basic vaults, to second-generation rotated secrets, which automate periodic credential changes to minimize exposure. From there, Akeyless facilitates a shift to third-generation dynamic secrets, implementing Zero Standing Privileges (ZSP) by generating temporary identities on-demand, ensuring access is granted only when needed and revoked immediately after. Ultimately, this paves the way to a fourth-generation secretless model, that uses advanced authentication methods like OAuth, OIDC, SPIFFE, and ZSP to achieve “SSO for Machines.”
It’s important to clarify that “secretless” doesn’t imply the complete absence of secrets; rather, it means the end-client or application is unaware of them and doesn’t handle them directly. These secrets are managed transparently by a central system, much like how serverless computing doesn’t eliminate servers but makes their management invisible to the user. This allows teams to focus on core business logic without getting stuck in infrastructure concerns.
By centralizing control, enforcing policies, and integrating with hybrid environments, platforms like Akeyless provide the scalability, visibility, and security that MSI lacks. That is why enterprises should consider MSI as one tool in a broader arsenal, complemented by centralized secrets managers, zero-trust architectures, and hybrid identity federation. Robust, future-proof security demands addressing the full spectrum of an enterprise’s complexity, not just the low-hanging fruit. Discover how Akeyless can help you go beyond MSI. Visit our website to learn more or request a demo.
