Nested App Authentication: Microsoft’s New Feature Is a Double-Edged Sword for Azure Security

Microsoft has introduced a new mechanism known as Nested App Authentication (NAA), which is steadily becoming a key component of the company’s cloud ecosystem. The concept is straightforward: if a user has already signed into one application, that application can act as a broker, issuing tokens that grant access to other services. This approach strengthens security while streamlining the user experience, enabling seamless transitions between administrative portals or Azure services without repeated logins.

The technology became generally available in October 2024, and it is now supported not only in Microsoft products but also in third-party applications. Among researchers, an alternative name has also taken hold—BroCI (brokered client IDs)—a term coined in analogy to FOCI (“family of client IDs”). This is partly due to the fact that the abbreviation NAA is already used in other Microsoft products, leading some publications to prefer BroCI instead.

Expert interest in this model arose quickly. In early 2025, during a hackathon, the SpecterOps team conducted the first detailed analysis of NAA. Soon after, brokered request mechanisms began to appear in widely used Azure tools such as roadtx, Maestro, and EntraTokenAid. Other researchers—including Dirk-jan Mollema and Fabian Bader—released services to analyze applications and their permissions, and the community rapidly developed practical use cases.

Why is this important? In many cases, tokens cached on the user’s device are insufficient. With NAA, an already issued token can be “handed over” to a new application to unlock additional resources. For instance, it could be used to activate a role in Privileged Identity Management, even if the user hasn’t opened the relevant portal in some time, or to retrieve a secret from Azure Key Vault. Crucially, the transfer also carries over multi-factor authentication (MFA) status. This means that if an administrator confirms MFA once in the Azure Portal, a brokered request can extend that validation across other services, eliminating the need to re-enter authentication codes.

Researchers have demonstrated a variety of ways to leverage NAA—from manually crafting requests with curl, to automating the process through PowerShell or specialized utilities. For example, Maestro can list Intune devices with just two commands, provided only a refresh token from the Azure Portal. Meanwhile, roadtx facilitates the extraction of Key Vault secrets, while still respecting MFA requirements.

In this way, NAA unlocks new possibilities not only for developers but also for security professionals. On the one hand, it offers a powerful tool for building more flexible application architectures and simplifying authentication. On the other, it represents a potential attack vector if an adversary gains access to an administrator’s refresh token. It is precisely for this reason that the research community is so actively studying and documenting the technology—to fully understand both its strengths and its vulnerabilities.

And while Microsoft promotes Nested App Authentication as a means of “enhancing security and architectural flexibility,” experience demonstrates that, in skilled hands, it can serve either as a valuable asset for administrators or as a potent launchpad for attackers.