When I first logged into the Azure portal in early 2019 I realized the same service now handled everything from employee logins to customer sign‑ups.
Conditional Access is Azure AD's policy engine that decides who gets in, when, and from where, looking at user, device, location, application and real‑time risk before applying controls such as MFA, device compliance or outright block.
A blanket rule that forces MFA for every admin across all apps and locations cuts the single biggest attack vector – stolen admin passwords – and is the core of Azure AD's zero‑trust approach.
For example, I have seen this approach reduce the number of password-related support tickets by around 30 percent in a large organization, simply by making it more difficult for attackers to use stolen credentials.
Managed identities let a VM, Functions app or AKS pod talk to Azure resources without ever storing a secret; Azure AD issues a short‑lived token that rotates automatically.
Because there is no credential to leak, any Azure compute workload that can host code should prefer a managed identity over a traditional service principal secret for accessing Key Vault, Storage or SQL, a choice that can be enforced through tools like Azure Policy.
Using managed identities can also simplify the process of rotating credentials, which can be a significant operational burden when using traditional service principal secrets, especially in environments with many applications and services, such as those built with Kubernetes and Helm.
An App Registration defines an application's identity in Azure AD, listing its OAuth2 scopes, redirect URIs and any client credentials it needs to present, a process that can be automated using tools like the Azure CLI or Azure DevOps.
When that registration is instantiated in a tenant it becomes an Enterprise App, the service principal that controls which users may use the app and what permissions it holds; multi‑tenant SaaS apps rely on this pattern to appear in each customer tenant on first consent, a pattern that can be simplified through the use of tools like Azure AD's application gallery.
Azure AD B2C extends the platform to consumer‑facing scenarios, offering local accounts, social logins from Google, Facebook and Apple, and even custom identity providers through its Identity Experience Framework, a flexibility that can be critical in supporting the identity needs of large-scale customer applications.
B2C can serve millions of external users while keeping their identities isolated from the corporate Azure AD tenant, making it a practical choice for large‑scale customer applications, such as those built with ASP.NET Core or Node.js, and using databases like Azure Cosmos DB or Azure SQL Database.
B2C's scalability is also a key factor, with the ability to handle up to 100,000 authentication requests per second, according to Microsoft's own benchmarks, a number that can be critical in supporting the identity needs of large-scale consumer applications.